[Tom41]

Ok, you all know about the 'sprite limit' of the MD's VDP. I've heard that on the earlier models of MD1s, the VDP actually had a bug involving the sprite limit. If there were too many sprites in a certain line, it could actually interfere with some of the Scroll High layers as well!

The result of this is that if you put a lot of sprites on the screen in, for example, Sonic 1's Marble Zone, you'd get lines of the floating pillars disappearing. This is normal, since the pillars are also on the sprite layer. However, with the older MD1s, you'd also get lines of the Scroll High layer (unmoving ground) disappearing as well, showing the Scroll Low layer through it!

Neither my MD1 nor my MD2 seems to suffer from this bug though - lines disappear in the sprite layer, but not in the scroll layers. From what I've heard, the bugged VDP lasted until the first revision of MD1s that contained the TMSS, and was then fixed for all future MDs. Has anyone got one of the older MD1s (preferably without TMSS) to try this on? Go to Marble Zone, use debug to create a lot of sprites near one of the floating pillars, and see what layers disappear.

[TmEE]

There's 315-5313 and 315-5313A, most MD's got the A variant.... (its the VDP chip). I'll have to check this out.

[GerbilSoft]

I have an MD1 VA2 with a 315-5313. (No TMSS) I haven't noticed this bug, so I'll have to check it again.

[LocalH]

I don't know which VDP either of my non-TMSS Genesis consoles has, but I don't think either one of them exhibit this bug. I've got one here with me at the apartment but it's not hooked up or anything, the other one is stored over at my parents' house so I don't have access to it tonight.

Maybe it was something like the first couple of production runs or something. I don't know the size of the runs they did, but they were probably fairly large.

[Sik]

I'm going to bet that it would only happen on the early japanese consoles, so you'd have to check those.

Also what's the source for this? If this was taken from looking at an ad, remember that the development boards are very DMA unfriendly (which is why all those warnings and hacks mentioned in the docs).

[ICEknight]

That never happened in my no-TMSS PAL Mega Drive... Is the source for this reliable?

[TmEE]

I've seen it in a video a friend (Epicenter, the DarkSea guy etc.) showed me some years ago... I never tried it myself... I still haven't.....

[Quickman]

Also what's the source for this? If this was taken from looking at an ad, remember that the development boards are very DMA unfriendly (which is why all those warnings and hacks mentioned in the docs).

Maybe my memory has failed me, but what are you referring to here? The only warning I recall is the "last word from RAM" business to avoid failure - that does occur on actual hardware, just very, very rarely.

I'd like to know what the source is for this as well though.

[Chilly Willy]

Page 106 of the Genesis Software Manual says this about DMA transfers -

In the case of ROM to VRAM transfers, a hardware feature causes occasional failure of DMA unless the following two conditions are observed:
* The destination address write (to address $C00004) must be a word write.
* The final write must use work RAM. There are two ways to accomplish this:
(1) by copying the DMA program into RAM, or (2) by doing a final "move.w RAM_address,$C00004".

It does not explain why.

[DigitalDuck]

Page 106 of the Genesis Software Manual says this about DMA transfers -

In the case of ROM to VRAM transfers, a hardware feature causes occasional failure of DMA unless the following two conditions are observed:
* The destination address write (to address $C00004) must be a word write.
* The final write must use work RAM. There are two ways to accomplish this:
(1) by copying the DMA program into RAM, or (2) by doing a final "move.w RAM_address,$C00004".

It does not explain why.

That's... bizarre.

I mean, why specifically $C00004? It doesn't make sense.

[Andlabs]

I mean, why specifically $C00004? It doesn't make sense.

$C00004 is the address you would write to to issue a command to the VDP. $C00000 is where you would write the data. For example:

Syntax Highlighted Code: ASM

    move.l #$C0000000,($C00004) ; command to initialize a write to CRAM $0
    move.l #palette,a1
    move.l #63,d0
-
    move.w (a1)+,($C00000) ; each write moves the pointer in CRAM
    dbf d0,-

would be the code block to load a palette.

This post has been edited by Andlabs: 24 March 2010 - 02:58 PM

[DigitalDuck]

$C00004 is the address you would write to to issue a command to the VDP. $C00000 is where you would write the data.

Ah, I see. So it's not just a random RAM bug, then. Please excuse my ignorance.

It's still a bit strange, though. I can see why only writing a byte rather than a word might cause problems, but "The final write must use work RAM"? Why would it matter?

[Chilly Willy]

It's still a bit strange, though. I can see why only writing a byte rather than a word might cause problems, but "The final write must use work RAM"? Why would it matter?

It's probably a cycle termination problem. DMA immediately halts the 68000 until the DMA is done. The "immediately" part of that is probably even worse under certain circumstances, cutting the current 68000 cycle off earlier than normal. The RAM is fast enough that an early terminated cycle still gives the 68000 bus enough setup/hold time on the data that it doesn't lose the data. However, the ROM may or may not be fast enough, and therefore the 68000 loses the data for that last cycle.

[Bibin]

I will jump to my First-revision non-TMSS Genesis 1 a bit later - what must I do to check for this bug exactly?

[Quickman]

Anything which causes sprite overflow. Marble Zone is a frequent offender.