Update PicoDrive 1.92


notaz

Certified Guru
Joined
Aug 23, 2005
Messages
4,913
Location
Lithuania
Website
notaz.gp2x.de
No idea if anyone is still using this, but here is an update, almost exactly 4 years since the last one. The main reason for doing this update was because I wanted to run the new Cave Story MD port (really impressive, check it out!), but it had the sound completely broken. There was also a new 32X+CD game release (Surgical Strike) which was not working on any emu, so I've fixed that up as well. After those, I went on and fixed bunch of other things, so the overall accuracy should be better now.

Get it at the repo, as always.

If anyone wants this on GPH consoles too, I can do a build, but I'll need help testing.
 
I still use PicoDrive as my Favourite MD/Genesis Emulator.
Soleil RPG and others work wonderfull :)

The only Problem i do not know is how to use Bios Files for Sega Mega CD RPGs like Lunar Series.

Thanks for the Update..i am Happy with all new Updates for our Pandora ;)
And Thx for last Kernel Update too in the Zaxxon :)
 
  • Like
Reactions: rSl
Nice ! Thanks.

I don't need it on GPH, but I can test things on my F-200.

Oh, was Herzog Zwei fixed ?
 
thanks!
picodrive is my "md emu of choice" too. :)
 
Nice to see a new release of my favourite emulator. Will give the cave story port a try. Thx Notaz
 
Thanks for the update Notaz, Picodrive is probably my most used Pandora application. Just played some Chaos Engine on it a few hours ago actually :)

If anyone wants this on GPH consoles too, I can do a build, but I'll need help testing.
I can do some basic Megadrive testing on GP2X F-200 and Caanoo if you decide to do a build for either.
 
Thanks very much for this :) currently being in a state of playing thorugh the Road Rashs I´ve missed so far, this is most welcome :)
 
Yay! PicoDrive is my favorite emulator, too! Thank you very much @notaz for still updating this. Whenever I see some of the other ports and their generic menus, it makes me appreciate the work you put into PicoDrive in all it's glory!
 
Excellent work Notaz! Hope to see in future the overclocking support for the Megadrive 68000 CPU to prevent the slowdowns in some games. BTW Genesis-Plus-Gx has started to implement this feature (currently still experimental with audio bugs):
 
Excellent work Notaz! Hope to see in future the overclocking support for the Megadrive 68000 CPU to prevent the slowdowns in some games.
It can be done, but it'll break many games because of wrong timing. Is that ok anyway?

Could you help to build for PSP as well?
I am still a PSP user and yet to move on
The PSP port in my tree is outdated and broken, far from even compiling. Somebody else is doing releases from his own fork and hasn't contributed any changes back, but it's probably best to wait for him as I don't have a working dev or test environment.
 
It can be done, but it'll break many games because of wrong timing. Is that ok anyway?

It's ok if the CPU overclock can be disabled in Picodrive menù, i surely wouldn't this activated by default considering not many games really benefit from a higher clock speed.
 
It's ok if the CPU overclock can be disabled in Picodrive menù, i surely wouldn't this activated by default considering not many games really benefit from a higher clock speed.
Here is a test build with the feature (see "advanced options"), done in a way to try to not break sound:
http://notaz.gp2x.de/releases/PicoDrive/PicoDrive_192_27.pnd

Just out of interest, what games do you want it for? A few games I could think of that are severely CPU limited (Road Rash series, Zero Tolerance) pretty much break: RR1 and ZT become smoother but also run way too fast, RR2 and RR3 become smooth but controls pretty much break as the game engine is not expecting such high framerates.
 
Here is a test build with the feature (see "advanced options"), done in a way to try to not break sound:
http://notaz.gp2x.de/releases/PicoDrive/PicoDrive_192_27.pnd

Just out of interest, what games do you want it for? A few games I could think of that are severely CPU limited (Road Rash series, Zero Tolerance) pretty much break: RR1 and ZT become smoother but also run way too fast, RR2 and RR3 become smooth but controls pretty much break as the game engine is not expecting such high framerates.

Hi notaz, thanks for this! I wanted this feature mostly for some Treasure games, shmups and FPS. I made a quick test with Thunderforce 4 and Viewpoint and indeed they seem to have a much stable framerate when there is more stuff on-screen. About FPS i made a short play with Duke Nukem 3D and i noticed a huge boost in framerate, in this game the moderate (about 30-35%) overclock of the MD cpu proved to be really useful, while a higher overclock, when used, will produce some unwanted side-effects like half invisible enemies and other weird graphic bugs. For those who want to try the overclock of the Megadrive cpu and don't know what are the games which suffer slowdowns i strongly suggest to check this list:

http://www.sega-16.com/forum/showth...ocking-amp-68010-Annotated-Compatibility-List

Here a video with some Megadrive games before and after the use of the cpu overclock:

 
Last edited:
I didn't even knew that emulation slow downs are not simply solved due more powerful actual hardware, but need special OC coding of the emulated hardware, interesting. So this is the reason why many emulators also "emulate" the original slow downs. I remember Star Fox etc. or do versions exist that can bring these games in stable 60 FPS?
 
I didn't even knew that emulation slow downs are not simply solved due more powerful actual hardware, but need special OC coding of the emulated hardware, interesting. So this is the reason why many emulators also "emulate" the original slow downs. I remember Star Fox etc. or do versions exist that can bring these games in stable 60 FPS?

When emulating, you generally need to keep to the timings of the original hardware. If an opcode takes 21 cycles to complete, you have to make sure that everything else is delayed so that this happens. This is phenomenally important for things like maintaining custom ship interactions between eachother and the main CPU - especially where two or more chips might be tighly coupled (such as the z80 and ULA of the Spectrum - you absolutely must delay the z80 while the ULA is working, or graphical effects common at the time will fail to render).

Certain hardware is decoupled, especially in later systems. Your CPU may prepare a frame of animation and then hand it off to a graphics processor to be displayed while the CPU goes off to do other tasks - in those cases, a faster emulation will benefit you as the emulated CPU has more time to get things done before it has to process a new frame. This can be handy for better graphics in Playstation or N64 emulators for example (not that I know much about these particular systems!).

But once you've got your emulation down perfect (slowdowns and all) then you can start to gather some knowledge of how a particular game works and modify its code on the fly to handle better frame rates due to faster hardware. It's not simple though - by simply increasing the CPU speed and framerate of a game such as Stuntcar Racer, you can easily end up with something so fast it's unplayable - because it knows that a frame is a certain number of cycles of emulation, so a faster emulation bangs the frames out faster and thus the game logic speeds up. Patching it to divorce the game logic from the frame update rate though will fix it.

So yeah, I suppose there could well be versions of Star Fox that have been modified for smoother updates, or emulators that can patch the game (or the chipset functionality) themselves to provide the same effect.
 
The Mega Drive/Genesis has two CPUs in it, but the z80 is primarily used as a sound processor. It has dual-ported VRAM so the renderiser can read ram at the same time the 68k CPU is writing to it, but it doesn't have anything in the model of a discrete GPU that can do its own processing steps. From the Playstation onwards (not sure about the 32x) there's a GPU that's writing projected texture information to the framebuffer while the CPU is doing other stuff.

In terms of simulating a faster 68k, I'd expect anything that's running sub-60fps will potentially get punted up to 60fps (which you can see in that bike game in that video which becomes much more twitch-like running faster). That might result in the z80 getting conflicting messages about what to do too quickly, but if it's just playing a tune with start and end of level transitions then it'll probably be okay. I'm not sure whether there are any games that use the z80 for anything other than music - it'd probably be something released later in the console's lifespan from Sega themselves or possibly someone like Capcom.
 
Ah, now I remember that these old consols are so releated to perfect timing in between the real hardware components. I guess this was the price for beeing able to produce compared good graphics onto compared slow hardware. Modern Consoles/PC's seems to work pretty different at that part.
 
Back
Top