Thursday, February 03, 2005

Universal, part 2

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:

Anonymous said...

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?"

Anonymous said...

Could it be that the 3rd processor was provided in case of (or originally intended to do) sprite preprocessing such as special effects etc?

Anonymous said...

Is it true you are being paid to fix the old MAME drivers?

Anonymous said...

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?

Nicola said...

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).

Anonymous said...

Could CPU #2 be operating while CPU #1 is waiting for CPU #3 to deliver the sprite data to the video hardware?

Anonymous said...

My question is this:

How on earth do these games run properly in Mame at all if CPU usage is unknown?

Very interesting stuff.