Spot differences between two pictures:
The first one was taken on system with Catalyst 13.1 WHQL and the second one on 13.2 beta. Day wasted on fixing this particular "bug". And before someone points out "This is what you get for using beta drivers" - there is a reason I need to be on 13.2 or newer.
However, Makaron still has some compatibility issue with certain games, such as Super Robot War Alpha for DC (SRW for short). I have been looking forward to a great update of Makaron that can fix this issue, but unfortunately later versions seem to have even more problems running SRW:
Makaron T11.2 frequently crashes with SRW, but plays BGM and voice perfectly;
Makaron EX3.0 has less crashing running SRW, but BGM of SRW deteriorates, music is not consecutive;
Makaron EX4.0 4.01 4.02 and 4.1 have pretty GUI and rich options, but... when setting SH4 Mode to DynaRec it frequently crashes; when setting SH4 Mode to Interpreter it runs very very slow (about 1/2 fps as DynaRec mode); when setting SH4 Mode to FashInt it runs even slower than Interpreter Mode (MEX 4.1), or stuckes at WinCE logo(MEX 4.0x).
Attached are representative error reports with different Makaron versions, hope this information could help improving Makaron to a perfect DC Emu. And I would like to provide SRW image if necessary. If figures are not available, just let me know.
Finally, many thanks to you again, Makaron authors (and contributors if any), I can't wait to hear reponse from you.
MEX3.0_error1
[img]http://p.kaixin001.com/privacy/photo/53/36/2285658_941533676_rotate.png?3b2583056f14ff46aefa6fb0f66013b8[/img]
MEX3.0_error2
[img]http://p.kaixin001.com/privacy/photo/53/36/2285658_941533683_rotate.png?d406f5b889145404f23cf8ce1087e6c9[/img]
MEX3.0_error3
[img]http://p.kaixin001.com/privacy/photo/53/37/2285658_941533723_rotate.png?aefb93428ddae5af793d7a8b8d36a690[/img]
MEX3.0_error4
[img]http://p.kaixin001.com/privacy/photo/53/37/2285658_941533725_rotate.png?0792d3afdea17ddef57ab1f3c12955ef[/img]
MEX3.0_error5
[img]http://p.kaixin001.com/privacy/photo/53/37/2285658_941533757_rotate.png?1c5ae0832f99cf6bc0cae01906309541[/img]
MEX4.x_DynaRec1
[img]http://p.kaixin001.com/privacy/photo/53/36/2285658_941533657_rotate.png?3575a9ccf5acd3343080991ca6451882[/img]
MEX4.x_DynaRec2
[img]http://p.kaixin001.com/privacy/photo/53/36/2285658_941533659_rotate.png?f7a4fc6304584cc9de96e910b099ec9f[/img]
MEX4.x_FastInt, stucked
[img]http://p.kaixin001.com/privacy/photo/53/37/2285658_941533764_rotate.png?948df8df1cbc85871d4e949d70d66080[/img]
MEX4.x_Interpreter2, very slow
[img]http://p.kaixin001.com/privacy/photo/53/37/2285658_941533770_rotate.png?501c9a5330df546fb5c5ceddcb088c8c[/img]
MEX4.x_Interpreter1, very slow
[img]http://p.kaixin001.com/privacy/photo/53/37/2285658_941533776_rotate.png?6917bbf96bfe8c1975e536433039a8dc[/img]
Second, and this is not explained anywhere, WinCE compatibility is actually highest in recompiler mode. Slow interpreter should work too but as you realize it's very slow. Fast is just something I use for testing, it's using interpreter core but in ways that break compatibility with WinCE games. So it just won't work at all in these case.
T11/2 is quite ancient version, there should be T12/5 or even T12/6 out there for Dreamcast games. Try that one, see if it works better with SRWA.
I'm seriously impressed by your skills.
Please could you re-upload your DIMM tools? The link in your earlier post (from 30th-Apr-2010) is down and Google isn't being friendly with finding an alternative source.
Thanks!
Neil
Edited at 2013-04-20 08:49 am (UTC)
Edited at 2013-05-04 12:40 am (UTC)
But good news is I might be getting some soon, so that I can finally test the signal integrity issues on close to final hardware.
DC mobo is Molex part 53408-0579
DC GD Drive is Molex part 52584-0579
i like this project a lot thanks for the update.
Can you post a demo video with the alpha state of the emulator in action? (fun request :P)
There used to be 2 short vidoes but these are now taken down. I wasn't the one who uploaded them, I just gave those to a handful of people I know. It wasn't really all that much, 2 games booting, SF3A and I don't even remember the other one (Skies of Arcadia?). SF3A was chosen as it does a lot of sound/music loading between demo stages and you could see how the prototype is just a tad too slow to keep up in some places. Since the new project has easily 2-3 times the transfer rates even with cheap SD cards I expect this to be fixed now.
Anyway, the problem right now is the signals on GD-DC link are pretty weak and don't work well with cables. You start pushing stuff through the data bus and the control lines can glitch. It's just for one clock cycle but enough to confuse FPGA. I don't see any termination or filters on original GD so it should be possible to overcome this by just shortening the link length and using proper connectors with ground lines separating the important stuff. If not I have devised a clever workaround in FPGA code but I'd rather keep it simple if possible. Again, I need the connectors to test that in first place.
Sourcing these connectors to EU is difficult unless you're prepared to order thousands and 50$ of shipping costs is not a problem for you. Not exactly what I'm aiming at for the moment. But as I said there is a light in the tunnel right now.
Is easier to emulate the signals from the laser lens or the custom ICs from SEGA and the buses of GD-Board <-> SH4 ?
Edited at 2013-06-22 01:03 am (UTC)
- for the laser head to produce a bitstream you need to rotate the disc
- rotational speed and head position, along with lens position, decide what you'll get
- GD-ROMs have two areas of different bit density
- bitstream is not the data itself, it's EFM encoded and distributed into separate frames
Saying it's easier to emulate the laser bitstream is like trying to build a car with just the engine. What about steering, brakes, wheels, seats, etc?
your board emulates the opening/closing GD-ROM deck?