JOTEGO
patreon
Missing bits
🕑 Added 2020-08-28 21:07:58 +0000 UTC
I'd like to discuss a technical topic this week: missing elements in emulators and, well, some FPGA cores. Let's use the palette memory of Side Arms for our case study.
Side Arms uses a regular RAM chip to store colour palette values. The GPU decides which pixel has priority from the character, scroll, object and star layers. Then the pixel value of that layer is used to address the palette RAM. The value at the addressed position is taken to the video digital-to-analogue converter (video DAC).
But if the video DAC has to output pixels all the time when are the colour values written to the memory by the CPU? If the RAM is disconnected from the video DAC and connected to the CPU, the video output will be blank, right? That gives you part of the answer, the memory must be updated only during blanking. Arcade games usually trigger an interrupt to the CPU just before the vertical blanking. That's the time when the CPU will update the colours.
On an emulator the action occurs sequentially. The emulator runs the CPU with full access to peripherals at full speed for a fixed number of cycles and then stops it and draws the image from the state of video memories. At the beginning of each run cycle an interrupt is generated.
On the real Side Arms arcade both the CPU and GPU are constantly running. The CPU actually gets not one but two interrupts per frame and there is a bit mapped to memory on which it can check the vertical blanking status. The address multiplexer gives priority to screen drawing so if the CPU tries to change a colour while not in blanking the request will be utterly ignored. The CPU cannot read the palette data back. Only writes are allowed. So the CPU cannot check data written. However, there is one bit that gets set if CPU writes to palette RAM were missing. The CPU checks that bit and repeat the write until it is successful.
As you see the original hardware works quite differently from emulation. For Side Arms we can trust that we have the right FPGA implementation. Sadly, I cannot say the same about Section Z/Legendary Wings.
In these two games if I gate CPU access to palette RAM with the blanking signal, then you get miss writes. If you check videos of the Section Z beta on YouTube you'll see that on the third level some colours go wrong. I don't have the schematics for that game, neither do I have the board. The core is made by combining the CAPCOM know-how from other games plus information available in MAME. So some fine details are not covered. These two games may use a scheme like Side Arms, or they may just give priority to the CPU instead. We don't know.
In such cases, I can only document the assumptions and the list of work-arounds used and hope to get access to the information in the future.
I hope you have enjoyed this technical post. I had hoped for another core release this week too but it still needed a bit more work. Please bear with me.
Comments
JOTEGO
Hi Amineko, try asking @caiusarcade on Twitter. He usually work with reproductions. Many of these small custom chips do not contain complex logic and can be implemented in many different ways when porting the system to FPGA without altering overall time accuracy.
Amineko Stone
Mr Jotego - is there any information around the net about vhdl/verilog versions of the custom Konami chips, e.g. 502, 503, 504 and 82, 83? I see years ago they have been reverse engineer for CLPD boards to sell, but I'm not aware of any place the code is.
