VDP debug port
Iwis says
This page is missing a lot of stuff, it only includes whatever I'm confident to document right now.
General remarks
There are multiple debug registers in the VDP. In order to select a
register, write its number in bits 11-8 of $C00018
, then
access the register through $C0001C
. Registers 0 to 7 are
writable, register 15 is readable.
- Nothing that disables some part of the rendering affects VRAM bandwidth. Don't expect to gain extra room for loading graphics by using this register.
- Writing to this port goes straight to different portions of the VDP (instead of being latched properly as with the other ports), so depending on prefetch and other things going on there's risk of causing VRAM corruption when writing to it.
- On top of that, on some VDPs merely turning on certain bits will cause CRAM to be corrupted over time. The stuff in this register isn't very stable at all.
Debug register 0
Bits 8-6: layer mixing
The most interesting of the bunch and the ones Overdrive 2 loves to exploit in many of its effects. It disables and enables layers and it's possible to cause the VDP to try displaying two layers at the same time.
- Bit 6:
0
: normal rendering1
: hide all layers
- Bits 8-7:
00
: do nothing01
: force sprite layer to display10
: force plane A to display11
: force plane B to display
When bit 6 is set, using bits 8-7 lets you display a single layer. This may have been useful for debugging on real hardware. The picked layer is forced to show even in border area, so you'll get to see some pixels that are rendered off-screen, as well as noise from memory access patterns and such in the areas not covered by the plane.
The interesting stuff is when bit 6 is clear and you force a layer with bits 8-7. In this case, the VDP will try to display both what it'd normally output and the chosen layer, which results in the two outputs being AND'd together (specifically, their palette/color indices). Overdrive 2 exploits this for all sorts of tricks.
This part is really not stable. The AND effect is the result of a bus fight, and some VDP chips (mainly early ones, but also a few of the later ones) will end up displaying a horrible mess instead (or in some cases, do the effect but garble up the sprite layer). Don't expect it to work fine on every console. You have been warned if you intend to use this.
Bits 11-9: PSG override
When bit 9 is clear, PSG works as normal. When it's set, however, all PSG channels get replaced with the volume level of one of them. Bits 11-10 pick which channel is the source of the volume level.
Bits 14-12: sprite rendering
Each of these bits mess with each of the sprite rendering phases (presumably they toggle whether each phase is executed). Setting them may result in stuff like sprites not displaying or the same sprite line being repeated across the whole screen, depending which phase was altered and at which time.
Debug register 1
Bit 0: Z80 clock speed
Bit 0 toggles the ZCLK speed (Z80 and PSG clock):
0
selects MCLK÷15 (around 3.58MHz in 60Hz)1
selects MCLK÷7 (around 7.67MHz in 60Hz)
Setting this bit actually selects VCLK (the 68000 and YM2612 clock). This bit affects both Z80 and PSG, so the PSG becomes even higher pitched.
Some consoles come with slow Z80 RAM and the Z80 is rated for only up to 4MHz, so there isn't any guarantee that overclocking this way will be reliable. It will also affect any sound driver that relies heavily on cycle counting.
Bit 1: EDCLK pin function
This bit toggles what the EDCLK pin does:
0
makes the pin take EDCLK as an input1
makes the pin output DCLK instead
Remember that the console is still generating EDCLK on its own regardless of this pin, so on a Mega Drive the only thing you will get is both clock sources fighting with each other instead of doing anything useful.