VDP 128Kb Extended VRAM mode
Posted: Sun Feb 03, 2013 11:00 am
Hey, quick post, it's late and I need to get to bed, but I mentioned awhile back last year (in this thread: viewtopic.php?t=1121 ) that based on my examination of the TeraDrive, and some documents I'd been shown, that the VDP had an "extended" 128Kb VRAM mode. I just wanted to mention that I did some tests tonight, and I confirmed that the VDP does in fact have this mode.
Here's how extended VRAM mode works:
-Bit 7 of register 1 enables extended VRAM mode
-If bit 7 is not set to 1, writes to VRAM happen as per a system without extended VRAM, namely, they wrap at 0xFFFF.
-If bit 7 is set to 1, and extended VRAM is present, VRAM writes are permitted from 0x00000-0x1FFFF, with the upper memory region written from 0x10000-0x1FFFF.
-With extended VRAM mode enabled, all name table addresses have an added bit 16 in their registers, which allows the name table data to be relocated to the second bank of VRAM.
The major limitation of this mode is that "Pattern Name" words (IE, mapping words) cannot target the extended block of VRAM memory, since there are no additional bits available in this word to add an extra bit of address information. I tested all settings for this word, and there's no magic combination of bits in this word that shift the pattern data to the upper VRAM memory block, it appears that pattern data must always be located from the beginning of the VRAM.
I was unable to locate any additional settings bits in the registers which would cause all patterns for any particular layers to shift to the upper VRAM block. I haven't tested this exhaustively however, and I haven't done any tests with sprites yet, so it's possible such a setting does exist somewhere. Being able to read sprite mapping data from anywhere in VRAM, upper or lower sections, on a sprite by sprite basis, would be extremely useful, and would largely mitigate the limitation of not being able to shift pattern data for the scroll layers to the upper section of VRAM. There's plenty of extra space in the sprite attribute table entries, so I wouldn't be surprised if such a setting exists.
I also suspect that when you're using interlace mode 2, you'll find that you can simply use the entire 128Kb of VRAM without issue. Since pattern blocks are 0x40 bytes in this mode, not 0x20 bytes, the ordinary mapping words should be able to address the entire 128Kb region of VRAM. I haven't done any tests in interlace mode 2 with extended VRAM enabled however.
As another note, when extended VRAM mode is enabled, the additional VRAM memory isn't just added to the end of the existing VRAM region, it's interleaved together with it. This means all existing data in VRAM is effectively corrupted when you change this register. It also explains why enabling this register produces strange results on the Mega Drive, where extended VRAM isn't present. Half the data being read from VRAM for patterns and mapping data is trying to come from memory chips that aren't present.
That's about all I have to say about this mode right now, just thought some other people might be interested to know about it. That's one more mysterious VDP register setting explained at least.
Here's how extended VRAM mode works:
-Bit 7 of register 1 enables extended VRAM mode
-If bit 7 is not set to 1, writes to VRAM happen as per a system without extended VRAM, namely, they wrap at 0xFFFF.
-If bit 7 is set to 1, and extended VRAM is present, VRAM writes are permitted from 0x00000-0x1FFFF, with the upper memory region written from 0x10000-0x1FFFF.
-With extended VRAM mode enabled, all name table addresses have an added bit 16 in their registers, which allows the name table data to be relocated to the second bank of VRAM.
The major limitation of this mode is that "Pattern Name" words (IE, mapping words) cannot target the extended block of VRAM memory, since there are no additional bits available in this word to add an extra bit of address information. I tested all settings for this word, and there's no magic combination of bits in this word that shift the pattern data to the upper VRAM memory block, it appears that pattern data must always be located from the beginning of the VRAM.
I was unable to locate any additional settings bits in the registers which would cause all patterns for any particular layers to shift to the upper VRAM block. I haven't tested this exhaustively however, and I haven't done any tests with sprites yet, so it's possible such a setting does exist somewhere. Being able to read sprite mapping data from anywhere in VRAM, upper or lower sections, on a sprite by sprite basis, would be extremely useful, and would largely mitigate the limitation of not being able to shift pattern data for the scroll layers to the upper section of VRAM. There's plenty of extra space in the sprite attribute table entries, so I wouldn't be surprised if such a setting exists.
I also suspect that when you're using interlace mode 2, you'll find that you can simply use the entire 128Kb of VRAM without issue. Since pattern blocks are 0x40 bytes in this mode, not 0x20 bytes, the ordinary mapping words should be able to address the entire 128Kb region of VRAM. I haven't done any tests in interlace mode 2 with extended VRAM enabled however.
As another note, when extended VRAM mode is enabled, the additional VRAM memory isn't just added to the end of the existing VRAM region, it's interleaved together with it. This means all existing data in VRAM is effectively corrupted when you change this register. It also explains why enabling this register produces strange results on the Mega Drive, where extended VRAM isn't present. Half the data being read from VRAM for patterns and mapping data is trying to come from memory chips that aren't present.
That's about all I have to say about this mode right now, just thought some other people might be interested to know about it. That's one more mysterious VDP register setting explained at least.