Page 1 of 3

VDP 128Kb Extended VRAM mode

Posted: Sun Feb 03, 2013 11:00 am
by Nemesis
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.

Posted: Sun Feb 03, 2013 11:09 am
by TmEE co.(TM)
Very cool stuff !

Posted: Sun Feb 03, 2013 12:22 pm
by ElBarto
How does this work electrically speaking ?
Is there a /RAS2 and /CAS2 pins on the VDP which select another pair of ram chips ?
Does the vsram is doubled too in this mode ?

Anyway, thanks for this awesome information.

Posted: Sun Feb 03, 2013 12:48 pm
by Nemesis
I described my theory of how the connections worked in that other thread I linked in my first post. This theory was basically confirmed later in that thread when we managed to get the full pinouts for the 315-5487 (VDP + Bus Arbiter/IO), which named the unused pins for the second bank of VRAM, which matched my expectations. Basically, there's separate SE and WE lines for the second memory bank, as well as a separate set of address lines. I wrote in detail about why this is necessary in the other thread.

VSRAM is unaffected by this setting, it purely affects the operation of VRAM access.

Posted: Sun Feb 03, 2013 1:22 pm
by ElBarto
Oh yeah I didn't see those scans, thanks.
I guess that those pins are the ones still unknown on the 315-5313, did you test this on a MD1 too ?

This is weird that the VSRAM is unaffected as there is a /SE1 line.

Posted: Sun Feb 03, 2013 6:58 pm
by Chilly Willy
While pattern data in the extra range couldn't be used DIRECTLY, you could still store extra patterns for animation or scrolling a level there and copy it below using DMA. Unlike DMA from rom/wram, it won't stop the 68000 while it runs.

Posted: Mon Feb 04, 2013 3:38 am
by Nemesis
ElBarto wrote:Oh yeah I didn't see those scans, thanks.
I guess that those pins are the ones still unknown on the 315-5313, did you test this on a MD1 too ?
I've tested on the Mega Drive to confirm that it doesn't work correctly, but that's about all, I haven't made any hardware modifications to add in 128Kb of VRAM to the Mega Drive. All my tests so far have been done on the TeraDrive, but it has a stock 315-5313 VDP, so everything that applies here should apply on the Mega Drive, with the correct hardware modifications.
ElBarto wrote:This is weird that the VSRAM is unaffected as there is a /SE1 line.
Well I should say I haven't done any real testing on VSRAM when extended VRAM mode is enabled. What kind of side-effects would you expect to see?
While pattern data in the extra range couldn't be used DIRECTLY, you could still store extra patterns for animation or scrolling a level there and copy it below using DMA. Unlike DMA from rom/wram, it won't stop the 68000 while it runs.
Very good point! VRAM copy is normally pretty much useless, since everything in VRAM is addressable all at once anyway. This extended VRAM mode makes the DMA copy mode make a lot more sense.

Posted: Mon Feb 04, 2013 8:49 pm
by Chilly Willy
Nemesis wrote:
While pattern data in the extra range couldn't be used DIRECTLY, you could still store extra patterns for animation or scrolling a level there and copy it below using DMA. Unlike DMA from rom/wram, it won't stop the 68000 while it runs.
Very good point! VRAM copy is normally pretty much useless, since everything in VRAM is addressable all at once anyway. This extended VRAM mode makes the DMA copy mode make a lot more sense.
Yeah, about the only other thing VRAM COPY is good for would be shifting the name table on scrolls. Maybe shifting the HSCROLL table (line mode, and shifts back and forth rather being unrelated values).

Posted: Wed Feb 06, 2013 2:17 pm
by Nemesis
And now here's where something pretty cool becomes extremely awesome. I completed tests tonight looking for ways to rebase the pattern data to the extended VRAM area, and I found it.

To rebase sprites, they resurrected the old "Sprite Pattern Generator Base Address" register. On the 315-5313 VDP used in the Mega Drive, it has the following form:

Code: Select all

//         ----------------------------------
//         | 7 | 6 | 5  | 4 | 3 | 2 | 1 | 0 |
//0x06(6)  |--------------------------------|
//         | / | / |AP16| / | / | / | / | / |
//         ----------------------------------
//AP16: Sprite Pattern Generator Base Address, bit 16. This bit only has an effect in
//      extended VRAM mode.
This makes it compatible with the original TMS9918 register, and the SMS VDP register, which used bits 0-2 to represent bits 11-13 of this base address. Only bit 16 can be controlled on the Mega Drive however.

To rebase pattern data, I bring you the previously unknown register 14:

Code: Select all

//         -----------------------------------
//         | 7 | 6 | 5 | 4  | 3 | 2 | 1 | 0  |
//0x0E(14) |---------------------------------|
//         | / | / | / |PB16| / | / | / |PA16|
//         -----------------------------------
//PA16: When this bit is set, layer A is rebased to the upper memory area.
//PB16: When this bit and PA16 are both set, layer B is rebased to the upper memory area.
Setting bit 0 of this register will rebase all layer A (and window) pattern data to begin at the upper bank of the VRAM. Bit 4 of this register only has an effect when bit 0 is set to true. Setting bit 4 to true as well will rebase all layer B pattern data to the upper VRAM bank as well.

So, using these registers, it's possible to place sprite, layer A, and layer B pattern data in whichever VRAM bank you want to. This makes the extended VRAM mode extremely useful. I really wish the Mega Drive had made use of this now, it would have made a huge difference to a lot of games to have double the VRAM memory available.

Obviously the only barrier to providing this feature was cost, because it's already there and working from the VDP design point of view. I have documentation revealing that the official Mega Drive development system did in fact have 128kb of VRAM provided, and we can see that the Teradrive also had it, supporting the idea that it was designed as a possible development system as well. It seems likely that Sega were planning to provide 128Kb of VRAM in the Mega Drive, and decided to cut it to save on costs.

Anyone happen to know how much a couple of 64Kb CMOS RAM chips would have cost back in the late 80's? I'm curious to know how much of a price per unit was saved by cutting this.

Posted: Wed Feb 06, 2013 2:30 pm
by TmEE co.(TM)
This in really really really wow !

So much tiles wold be possible....!

Such NOS DRAM still costs several dorrals a piece, I imagine it was quite a few more dorrals more expensive 25 years ago...

Posted: Wed Feb 06, 2013 3:32 pm
by Charles MacDonald
These are some incredible findings! Totally amazing stuff.

At least for VRAM, the price must have plummeted in a few years -- on their System 32 arcade board (1991) they have no less than 24 64Kx4 VRAMs. :D

It's a shame the Genesis didn't have an slot like the N64 where you could have plugged something in to add the two extra VRAMs. Would have been one heck of an upgrade back then.

And if they had brought out the digital video bus to a connector we could have gotten a palette upgrade too. Oh well!

Posted: Wed Feb 06, 2013 5:06 pm
by Huge
Nemesis wrote:I have documentation revealing that the official Mega Drive development system did in fact have 128kb of VRAM provided
Is this documentation publicly available?

Posted: Thu Feb 07, 2013 10:58 pm
by Nemesis
Not yet, but I'm hoping it will be made available soon. Teancum on assemblergames has the documents. He's already scanned and released a few of them, but there's a bunch more he hasn't done yet. He sent me a few scans that he hasn't released yet but he asked me not to share them around until he has a chance to finish off the scans and release them.

Here's the stuff he's told me he has:
SNASM2 Mega CD Manual I have one binder but there is two sets of docs seems kind of odd.

Sega Mega Drive Manual Rev 02/20/92
bunch of bulletins haven't had time to catalog them all.

CTrac Manual
-CTrac Emulator for Sega Genesis
-CTrac Builder for Sega Genesis
-CTrac BuildDisc - A compact disc image building tool
-CTrac Write ONce - A write-once compact disc mastering tool.
-CTrac BuildTrack - An ISO 9660 track image building tool.
-CTrac CD Emulation System - Sega Mega CD Game Machine
-CTrac ISOUtil - An ISO 9660 image manipulation tool.
ISO IEC 10149

CD-ROM Manual
-Mega-CD Outline v1.0 12/13/91
-Mega-CD Hardware Manual - The Hardware v1.0 10/14/91
-Mega-CD Hardware Manual - PCM Sound Source v1.0 10/14/91
-Mega-CD Software Development Manual v0.10 3/6/91
-Sega-CD Software Standards May 6, 1992 "Attached is a preliminary description of the Sega-CD Software Standards for the U.S. This will bea growing document and is subject to change."
-Mega-CD Disc Format Specifications -(conforming to ISO9660) v2.0 Feb.24 '92
-Mega-CD BIOS Manual v2.0 Feb.24 '92
-Mega-CD User Interface 3/5/92
-Sanyo LC7883 marked as Tentative
-Sanyo LC8950 & LC8951 - Real Time Error Correction and Host Interface Processors for CD-I and CD-Rom Applications. "First English edition revised to include LC8951 June 1989"
-Super Mega Drive Manual Jan.29-'91
-Cinepack 1 Tech bulletin
-Mega CD 1-7, 16-20 Tech bulletins

Also included another ISO/IEC 10149
and CEI IEC 908 (Red Book Partial)

Some of that stuff is already available from other sources, and some of it isn't. The MegaCD tech bulletins in particular will be very interesting, as most of those are not currently available. I'm also hoping some of the documents he has are better quality and possibly more complete than what we currently have available.

The document describing the development system that I've been referring to is the "Super Mega Drive Manual". This system is mentioned once in the currently available "Mega Drive Technical Memo #4", where it is referred to as the "Super Target". This unit would have been the official development/reference system that would have been used during development, kind of like a Sophia system is for the Saturn. Most likely it was replaced by other hardware later on, like the Cross Products MegaCD unit, and a lot of development studios probably only had a single one of these units, if any, and relied on cheaper systems such as a stock Mega Drive with a ZAX ICE unit fitted.

If you want to let him know there are people waiting on this stuff, drop Teancum a line in this thread:
http://www.assemblergames.com/forums/sh ... .php?38240
He's going to release them, just snowed under with other stuff.

Posted: Mon May 06, 2013 9:40 pm
by TmEE co.(TM)
Added the extra VRAM to my clone MD :

http://www.tmeeco.eu/BitShit/VRAMallConnected.jpg
(There's 2 more chips on the bottom of the board)

I'll do some experiments later on when I'll make a test ROM.

Posted: Mon May 06, 2013 11:15 pm
by Charles MacDonald
The VDP part numbers look funky, is that a clone part?

Nice job on the wiring and soldering, looks like a ton of work.