But the strangest thing about Mr Do's Castle board is the third Z80. This CPU has a tiny program ROM - 256 bytes, and most of them empty. It sits there, doing almost nothing. It communicates with the main CPU using the same method described in the previous article, but it doesn't send anything back.
The interesting thing is what the main CPU sends it. It's not just 9 bytes as with the second CPU. It is 0x200 bytes, and it's the sprite data. So essentially what the third CPU does is sit there, wait for the sprite data from the main CPU, and pass it over to the video hardware.
Why couldn't the main CPU just send the data to the video hardware by itself? That's the difficult question. I haven't an answer yet.
7 comments:
I can just imagine the pointy-haired boss walking up to the Universal hardware engineer: "Hmm, our competitors at Namco just released a game with *three* Z80's in it. Why don't we make a game a with three Z80's in it?"
Could it be that the 3rd processor was provided in case of (or originally intended to do) sprite preprocessing such as special effects etc?
Is it true you are being paid to fix the old MAME drivers?
CPU #3 is delivering the pre-fetched sprite data to the video hardware while CPU #1 is busy with something else? What is it that needs to be done at the same point in time that the video hardware is processing the sprite data?
CPU #1 cannot do anything else while CPU #3 sends data to the vodei hardware, because the communication is done through a single buffer, and when CPU #1 writes to it it pauses until CPU #3 has read it (and copied it to the video hardware).
Could CPU #2 be operating while CPU #1 is waiting for CPU #3 to deliver the sprite data to the video hardware?
My question is this:
How on earth do these games run properly in Mame at all if CPU usage is unknown?
Very interesting stuff.
Post a Comment