Page 1 of 1

VDC registers

Posted: Wed Jun 25, 2008 6:59 pm
by Charles MacDonald
Going by equates in an include file, we have:

VDC register $03 = "CTAR"
VDC register $04 = "CTR"

Now I'll just make stuff up:

Maybe these are "color table address register" (address port, like MAWR) and "color table register" (data port, like VWR) for accessing color RAM in the VDC. While the VDC has no video output pins, it could output raw RGB data on the 9-bit color bus if you assumed VD0-VD8 were used to output three bits of red, green, and blue. My assumption would be that the VDC has a smaller internal color table than the VCE. The color bus outputs would have to be connected to a DAC for analog video output. Conveniently, such an arrangement could drive a monitor with digital RGB inputs as well.

How is this enabled? There are no spare pins on the VDC, and the +5V/ground groups are equally divided so none of then appear to be mode select pins that were tied high or low. It could be a register setting, but all bits have been tested. It could depend on having a particular pin asserted during a reset pulse, but that seems unlikely. The results of such a feature being turned on would be quite noticeable, as the palette/pixel values would have a completely different association to the color being displayed (as the digital RGB data would be addressing the VCE color table, not the pixel/palette code like normal).

Maybe this was a leftover from early documentation of the chip, and the internal color table was removed later. On-chip RAM is never cheap and we know the VDC already has ~2K of RAM for the sprite table alone, not to mention all the shift registers and other storage elements present. Perhaps it was removed to keep the cost down and allow higher yields, or it was planned for another revision of the chip that was never made. Who knows?

Re: VDC registers

Posted: Thu Jun 26, 2008 9:20 am
by MooZ
There're no hints in the patent docs? I'm not even sure if this kind of information may have been available in the nec devkit.

Re: VDC registers

Posted: Fri Jun 27, 2008 3:37 am
by Charles MacDonald
MooZ wrote:There're no hints in the patent docs? I'm not even sure if this kind of information may have been available in the nec devkit.
I checked and both the US and Japanese patents for the VDC make a point of skipping these registers in their descriptions, oddly enough.

It may have not been officially documented outside of what was present in the source code. One wonders who put it there and what their source of information was. :)

Re: VDC registers

Posted: Fri Jun 27, 2008 11:29 am
by MooZ
Do you know if this chip was used in other devices? Maybe these registers were used on them.
If only the datasheet or the hu7 docs were somewhere on the net :)

Re: VDC registers

Posted: Fri Jun 27, 2008 1:38 pm
by Charles MacDonald
MooZ wrote:Do you know if this chip was used in other devices? Maybe these registers were used on them.
If only the datasheet or the hu7 docs were somewhere on the net :)
It was used by Data East for the arcade version of Bloody Wolf, without a VCE. What they did was to connect VD0-VD8 to a SRAM which contained palette data, which was then fed to a DAC. External hardware multiplexed the CPU address and VD0-VD8 to the SRAM address bus. So if there was an internal color table, they deliberately chose not to use it. (BTW, Data East is the only company I know of that used the HuC6280/HuC670 apart from NEC)

This example may disprove a possible alternative use of CTAR/CTR, but it just hit me:

The Sega Genesis VDP also has a color bus which is intended to control an external RAM, just like Bloody Wolf. One of the VDP register bits enables a pass-through mode where the CPU address bus is fed through the color bus to the SRAM address inputs. In this way the CPU can directly address SRAM data without needing external hardware to multiplex both buses (CPU address and color bus).

The HuC6270 doesn't have enough address pins for that, but if you assumed CTAR/CTR accessed some kind of port-based memory, maybe register reads/writes translate to setting up VD0-VD8 to incrementing values so that the *external* color RAM is what's referenced. Again, this would have no purpose other than simplifying the external color RAM circuitry, and Bloody Wolf did not use this. And some additional gating of the /CS, /RD, and /WR strobes would be needed for the color RAM, maybe some VDP pin would have a secondary purpose as a strobe to indicate accesses in this way.

Lots of possibilities. :D

Re: VDC registers

Posted: Fri Jun 27, 2008 2:27 pm
by MooZ
You'll need some serious voodoo there :|
Maybe we should hunt some former Data East developer and beg them to teach us their secrets :)

Re: VDC registers

Posted: Sat Jun 28, 2008 2:02 am
by Charles MacDonald
I have been running some tests, this is what is known so far:

1. Reading from $0002 or $0003 when register $04 is selected enters 'weird mode' where the VDC output going to the VCE is corrupt somehow. Garbage is displayed instead of proper background/sprite graphics data.

2. While in this mode, reading $0000, $0001, and writing to $0000-$0003 returns you to normal mode. You can continue to read $0002/$0003 while staying in 'weird mode'. Reads do not affect MARR.

3. The garbage displayed seems to relates to the VRAM word that MARR currently addresses. Of the 16-bit word, only the following bits matter:

D10 : '1' = Screen goes blank and interrupts are disabled, '0' = Normal operation. Does this reset or corrupt all the VDC registers?
D9 : '1' = Garbage video, '0' = Normal
D8 : '1' = Garbage video, '0' = Normal

When bit 8 and/or 9 are set (setting both changes the garbage video further), bits D15,D14,D13 affect the positioning of some of the random flicker that is shown.

4. Writing any value to register $03 or $04 prior to entering 'weird mode' does not affect the output at all.

5. Colors shown are taken from within the first 256 palette entries regardless of the tile/BAT data present. No colors from the sprite palette are shown in the background areas.

As for the garbage video that is displayed: It seems that the VCE outputs the remaining data that was left in its background shift registers for 256 pixels, then outputs the same value every 8 pixels. The pixel data is the same for every scanline, however the palette data is completely random for each column and fluctuates. Y scrolling is meaningless as all scanlines look the same, X scrolling shifts the affected region over by 'scroll & 7'. Sprite positioning and other attributes are stable, but the sprite graphics become all vertical lines as well.

The only VRAM location the VDC reads is the one at MARR and there is no auto incrementing per pixel/scanline/frame.

Right now I'm fairly certain this is an unimplemented feature, or something left over from chip testing. I seriously doubt it can be used in any kind of a meaningful way by a programmer. :)

Re: VDC registers

Posted: Fri Feb 06, 2009 7:35 am
by tomaitheous
Revisiting this; I wonder what effect 2bit tile or sprite mode would have on this - if any.