Makaron News
Three days of updates from dknute regarding Makaron, Dreamcast emulator for windows, so get ready for a rather large WIP report of Makaron:
|
TAKE ON THE WORLD!
|
 |
|
Okay, so most of SEGA Mega Drive (Genesis for you US folks) aren’t that playable. Too many graphics bug for one - the emulator makes heavy use of PVR OIT capability. Sound will usually get ugly when heavy action starts even though it’s fine in menus. And there are other nasty problems as well, like falling through floors in alternate Prince of Persia.
But some games do work well enough (too bad Lotus 2 RECS is not one of them :)
By the way, I can’t shake that crazy idea of connecting a hard drive to Dreamcast off my mind. I’m pretty sure it can be done. Basically all that’s needed is some hardware to translate SEGA Packet Interface commands into HDD reads, and that’s exactly what Makaron’s GD module is doing. Right now there is logical link on register level but I’m confident I can extend it to handle singal layer as well. I do have some experience with ATA/ATAPI hardware. |
|
I feel like I could…
|
|
|
ScummVM works now (except the newest 0.10 version which is known to have sound problems on the Dreamcast port). Thanks to it crashing frequently on T8 I managed to nail down a bug in the MT version of Makaron.
Running emulator inside emulator is fun! Also, FreeSCI 0.3.5 port is actually performing better on Makaron than the native PC version… |
|
Warp 4, engage
|
|
|
There’s a limiter system implemented in Makaron which keeps SH4 speed below 360 MIPS. Why? Because the real one is running on 200MHz clock and theoretical maximum crunching power it can hope to reach on that clock is 360 millions instructions per second. There is no way a real Dreamcast ever gets this fast though, not when the RAM is so much slower then L1 cache. And let’s not forget real code never gets fully vectorized into the pipelines. In other words: there is simply no reason for the emulator to get any faster and the ‘leftover’ (if any) host CPU power could be used up elsewhere as needed. On top of that there is another limiter of sorts, it’s task is to keep the emulator responsive. You can’t just sit all the time in the SH4 loop, you need to do other things as well - one of them being servicing operating system messages :) Several days ago, while messing with certain aspects of SH4 recompiler, I’ve realized that the second limiter prevents the main one from achieving maximum speed possible on given CPU. Well, I kinda knew that beforehand but I deemed it necessary - while perhaps multi-core systems do not need that kind of limiting at all. Even if you stall one core/CPU, there are others to take care of OS and other tasks, so… I can’t just remove it alltogether for the sake of single core CPUs. I can relax it way more when detecting dual-core systems, but as it is now it breaks certain games. I will need to get around that and I already have few ideas to try out. Let’s hope one of them will work :) Anyway, I’ve changed the limits of SH4 speed to 10 (lower) and 1500 (upper) MIPS, applied several unsafe changes to recompiler core and relaxed second limiter all the way I could - just so it would not break sound emulation. I’ve managed to get over 700MIPS that way. Pretty darn good if you ask me, for 2400MHz E6600 it means I’m emulating one SH4 instruction every 3.5 cycles. And that’s still while doing machine-state and ARM code on the same thread. That number does get down quickly when there is lots of FPU code/scene geometry to handle.
What does all that mean to Makaron users? Even if you won’t be getting all that speed in the next version (not much point in that anyway), I’ll try to redesign the main loops a bit so that even lower end multi-core systems will see some nice improvement. Single core users will get only very little speedup though. BTW, does anyone know how to safely distinguish a true multi-core system from P4 with HT enabled? Or do I have to CPUID them by hand? PS. Yes, there is an INI option in T8 that will let you change the SH4 limit, but it will still enforce 50 (lower) and 360 (upper) bounds if you set anything beyond that. |
