excellent/excellent_spr.cpp: Fix sprite delay, Cleanups/updates: #13213
Conversation
- Fix background tilemap bankswitching - Use ROMREGION_ERASE00 for Fill empty ROM area
…excellent/excellent_spr.cpp, Cleanups: excellent/excellent_spr.cpp: - Reduce duplicates - Remove unused variable - Use decode_gfx for gfx decoding routine - Fix docs
cam900
changed the title
| void excellent_spr_device::vblank(int state) | ||
| { | ||
| if (state) | ||
| std::copy_n(&m_ram[0], 0x1000, &m_ram_buffered[0]); | ||
| } |
There was a problem hiding this comment.
Does the hardware appear to use DMA to copy the data like this, or does it simply swap the buffer currently accessible to the CPU with the buffer that it draws from?
You may be able to work this out by looking at what the main program expects to see when reading from sprite RAM. Does it need to see the contents of the most recent frame, or will it work if it sees the contents from the previous frame?
If it works seeing the contents from the previous frame, it’s likely just exchanging buffers, and you can implement it by exchanging a pair of pointers rather than copying from one buffer to the other. If it needs to see the contents of the most recent frame, it’s likely using DMA, which means the copy here is accurate.
If it’s using DMA, is the CPU halted or prevented from accessing sprite RAM during DMA? (For example some Capcom games like Ghosts ’n Goblins block CPU bus accesses during sprite DMA, although MAME does not emulate this.)
There was a problem hiding this comment.
I think it's DMA, there's 2 6116 (2kword x 8bit) RAMs (possibly sprite RAM) are mentioned in gcpinbal and aquarium PCB docs. But I don't think the CPU is halted or prevented from accessing sprite RAM during DMA.
There was a problem hiding this comment.
How would it work in that case? It’s unlikely the RAM is clocked at double the CPU speed to allow transparent sprite RAM DMA.
excellent/excellent_spr.cpp:
excellent/gcpinbal.cpp: