The Mega Drive has a 16-bit register at memory location $C0001C (Appears to also be mirrored at $C0001E) which controls and disables various features of the VDP (Video Display Processor) and was probably used as a debugging aide during the design of the VDP. During a recent IRC conversation, this subject came up and I decided to research a little more into it. I wrote this programme that lets you set individual bits of the register and view what they do to the VDP. This is what that programme looks like with none of the bits activated (at which point it plays a square wave over the PSG channel 1 — this is so the effect of bit 9 can be heard. Note that the corruption on the first line of text is caused by the VDP after setting a specific bit): With this tool running on hardware (You can run it on an emulator, but none of the bits will have any effect) I was able to decode what the different bits meant and did on my Model 1 VA5 NTSC Mega Drive with a Sega CD attached (No difference was observed with it removed): Bit 14 set = Sprites hidden (perhaps part of a 'debug mode' register) Bit 13 set = Sprites hidden (perhaps part of a 'debug mode' register) Bit 12 set = Sprites hidden (perhaps part of a 'debug mode' register) Bit 9 set = PSG disabled Bit 8 set = BG layer hidden, dots at top of screen, line at right and sprites hidden (besides artefact of one all the way to the right.) Bit 7 set = FG starts using an odd tile for everything, BG uses odd palette - possibly reading corrupt data. There's small black lines on the side of the rainbow bars (BG has been disabled for clarity) Bit 6 set = Display is disabled Bit 5 set = Some sort of grid pattern, all planes seemingly hidden (Causes some brokenness in A plane at $C000) Bits 7 and 8 set = Garbles FG and sprites. Bits 15, 14 and 8 set = BG hidden as well as sprites disappear. Bit 10 or 11 toggled = Causes a click in the audio (Thanks to Chilly Willy for pointing this out — I didn't listen carefully when I ran this test) Here is a video of the programme in action on hardware, with various bits being set. (The audio is slightly out of sync) I'm interested in seeing if other models of the MD (and other VDP chips) deal with these modes differently — so if you've got a flashcart, please try setting the bits on your hardware and report back what happened, as well as your hardware version and VA revision. You can download the ROM here. Lastly, I'd like to thank Jorge and Tiido for giving me the idea to toy around with this by suggesting I figure out if the VDP has more access cycles in one line if a specific plane was disabled. And I also apologise for the shitty quality of the video — my composite cable disappeared and my capture card likes being an asshat.
Neat. We should make a table of board/chip compatibility with these effects in case anyone feels dangerous enough to actually do this in production code... I mentioned this in IRC but: The VDP can take in an external CRAM source; the System C arcade board does this. I wonder if any of the remaining bits involve this...
Well, that's a very interesting discovery. I wonder if you can modify the signal that is sent out of the VDP into the TV using software, as I've seen it being done in a C128 demo Risen From Oblivion in the VIC part, where it altered the FIXED palette of the VIC-II(The VDC used in C64 and C128) by screwing with a bit in a specific way.
I was curious about this register when I read about it in Charles MacDonald's hardware notes. Glad to see you had the time to give us more info about it. Kudos.
I posted this over at SpritesMind, but might as well here, too. I ran this on my Model 2 Genesis and CDX. It works just like you report; however, I did notice something you didn't report - when you set either bit 10 or 11, it causes a click in the audio when the bit toggles (0 to 1 or 1 to 0).
I wonder if that could be abused like the Apple II speaker to generate tones and/or sample output without having to touch the Z80 bus at all?
Again ,thanks for pointing this out — I wasn't really listening as this was more of a VDP thing and it was late. I've updated the topic with that info, as well as uploaded a new version of the ROM that displays pink CRAM dots (A bug in the VDP itself that causes writes to CRAM to be written to the RGB output) to check for timing changes. They appear as small pink dots between the sprites and the last line of text, and are best visible with the BG layer turned off. They should appear every 32 pixels (that's when a CRAM access slot is available.)
