To TakaIsSilly

ramirez60

New Member
Why'd you stop? Do you think the Saturn was powerful enough to emulate an SNES at full speed? Also how did you test your code? Did you have to burn the game everytime? I wouldn't mind working on the project, unless it entails burning a cd every time I compile some code...I'm looking for some open source C code for an emulator I could play around with. Any suggestions? Later.
 

TakaIsSilly

New Member
Why'd you stop?

Got a life, have a big website project to attend, I've not stopped or runned away, the code is there, I just don't feel like spending time rewriting parts of it in SuperH lately (like, in the last 2 years or so ^^;).

Do you think the Saturn was powerful enough to emulate an SNES at full speed?

I still do. But not in raw C like I was doing. Stuff like DMA and graphics are almost correct, but the CPU code was too slow.

Also how did you test your code? Did you have to burn the game everytime


Not actually. I used Daemon Tools and SSF between builds. Every now and then I made a burn to the CD, to check the speed on the real deal.

I wouldn't mind working on the project, unless it entails burning a cd every time I compile some code...I'm looking for some open source C code for an emulator I could play around with. Any suggestions? Later.


My project is not for the faint of heart or new at coding. It has very long, anoying and buggy portions that elude me.

As for open-source emulators... there are quite a few out there. Look for them in sourceforge, make a google search.

But take for sure that in pure C, not even simple Z80 emulation runs at full speed in hte Saturn.
 

ramirez60

New Member
Well I've taken it upon myself to get your code to work on a real saturn. (yeah I'm bored) Well anyway I was going through it, and it doesn't seem as if you initialize the second CPU anywhere. Maybe that could be the source of your CPU bottleneck? Or is the bottleneck on the CPU bus? Oh well, just something to think about. I don't need an answer, I'll just be fooling around with this source some more...
 

ExCyber

Staff member
Well anyway I was going through it, and it doesn't seem as if you initialize the second CPU anywhere. Maybe that could be the source of your CPU bottleneck?

I may be wrong, but I'm pretty sure that the second CPU is held in a reset state (i.e. disabled) by the SMPC unless explicitly told otherwise. Unless the code is specifically structured to take advantage of a second CPU, there's no reason to pull it out of reset.
 

TakaIsSilly

New Member
SGL has a drawing routine that takes over the second CPU over an interrupt. It also supplies an interface that alows to register a function on the "slave" CPU when that interupt happens, and I used that in a experimental Phoenix emu modification. It runs, but the memory bank acess is sketchy, to say the least.
 
Top