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.
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.
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.
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.
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).
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.....
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.
$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: 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.
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?
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.
I will jump to my First-revision non-TMSS Genesis 1 a bit later - what must I do to check for this bug exactly?
There are more warnings in the addenums. Also the last page of the main docs show how the board should be set up to prevent the VDP from going insane. The issues are worse with the 32x (those docs have more warnings involving development boards).
In my experience working on Wolf32X and talking with Steve Snake, you can just ignore all the 32X warnings when working on 32X homebrew. Which is good - it means we can do things like use the free-running timers.
Except that the hardware we use currently has nothing to do with the development boards Sega used back in the day. Current hardware is designed to gimmick ROM characteristics to the MD, while development boards used crappy DRAM and other components in a pretty hackish way.
Dev HW was generally only slightly modified retail units ala CPU replaced with emulator terminals for low level debugging... and stuff was run on EPROMs or PSRAM(aka DRAM) boards... nothing hackish about the DRAM stuff, just 32X does not pass the refresh signal through untouched and that will cause some timing related problems which result in peculiar random crashes etc.... which 32X love to do when the ribbons are not tight...
I'm not sure if this is even relevant at all since I'm no MD tech wizard or anything, but it sounds kinda like what's going on. I've got a Genesis Model 1/TMSS and whenever I clear virtually any second act in Sonic 2, the flickies leaving the egg container cause the parts of the container they're parallel with to disappear. It looks like there's more or less an eraser moving up and down it, revealing what's behind. IIRC my friend's Genesis 2 doesn't do this, but it's been forever so I'd have to check.
