I'm concerned that he said his core runs the CPU much faster than the original, though. If the synthesized 68000 runs at the original 16MHz, and the video subsystem is accurate and clocked at the original 28.00MHz, it shouldn't be troublesome to get the delay to be correct.
If, however, he just means the maximum sprite bandwidth (hence the HUD not dropping out on ESP Ra. De., etc) then that won't affect the game speed. It shouldn't be a huge deal to measure the maximum bandwidth for the blitter and restrict the new core with it.
It's good that he's using ESP Ra. De. as a base for his work, as it and Guwange represent the most complicated superset of Atlus 68000 hardware. In particular, the sprites not only support scaling, but it also has some screwball GAL logic in place to inject an extra upper 4 bits of color depth to the sprite framebuffer during blits. This means that ESP Ra. De. and Guwange can not run on the previous boards that use this sprite chip (Dangun Feveron and, lol, Uo Poko). The older, previous-generation SPATTR 013 chip (the sprite chip) is missing the scaling, and isn't directly usable in the same way.
The Atlus 68000 games are only a stone's throw away from one another in terms of capabilities. The memory map, input bitfield definitions, and the sprite chip generation are the only real changes.
I posted this on April 1st:
but... it's not
really a joke? That's DoDonPachi running on ESP Ra. De. (obviously with the graphics and sound ROMs unchanged, so it looks garbled). The primary challenge to running DoDonPachi on that hardware is that the sprite attributes are laid out differently in VRAM.
DP, and DDP, are like this:
Code:
Single sprite definition:
+0.w: code
+2.w: attr
+4.w: x
+6.w: y
+8.w: size
+A.w: n/a
+C.w: n/a
+E.w: n/a
ESP Ra. De, Dangun Feveron, Guwange, and Uo Poko are like this:
Code:
Single sprite definition:
+0.w: x
+2.w: y
+4.w: code
+6.w: attr
+8.w: x scale
+A.w: y scale
+C.w: size
+E.w: n/a
So, while DDP's memory map is so close to ESP Ra. De.'s, the issue remains that the sprite definitions are incompatible.
The hastiest thing to do is to modify the hardware, and invert an address line when the 68000 talks to Sprite RAM, but not the SPATTR 013 IC. With that you can unscramble the sprite data, but then DDP must also be instructed to set a scale value that leaves the sprites unscaled ($0101).
Of course, for the FPGA system's author, this is a trivial thing to support.
(This post is now derailing a little bit into the unscrupulous topic of "Can something be converted to DoDonPachi?")
A software fix for the sprite format mismatch is to hook into the end-of-frame vsync wait function, and iterate through the sprite table to swap longwords around in order to transform sprites. This is the first thing I did, and it does work. The downside is that this is very slow, and it causes slowdown when there are even a moderate number of sprites on screen.
The other, more laborious bit of work is to modify the sprite drawing routines in DDP to write sprite definitions in the correct order to begin with. Unfortunately, there isn't just a single spot from which sprites are written. Rather, the game was certainly programmed with a healthy amount of macros, so there are hundreds of places that sprite writes are done. You can expect thousands of lines of changes and nearly one hundred new / modified sprite routines. However, this method provides a working DDP that runs at the correct speed.
The second method is not a fun task, but it's the best one for making a multi and not cutting up a board, other than ROM socketing. This method has been completed, and the game runs on ESP Ra. De. without any errors. There is another non-Cave PCB that DDP can now run on, but you'll have to solve a genuine bug in DDP's code that is innocuous, but locks up the other board (because of varying behavior in latching /DTACK, which had to be solved with a logic analyzer!)
tl;dr: with changes, DP and DDP can run on an unmodified ESP Ra. De. PCB, and another non-Cave PCB; I'm not releasing the files, but with this FPGA solution I'm very happy that we probably will never have much of a need for them any longer. Let's see how the final thing turns out. it's open source, so if there are issues, maybe they can be addressed as well.
Thats cool..
