Undocumented VDP commands

Ketsuban · Post by **Ketsuban** » Sat Mar 20, 2010 7:51 pm

In the documentation for the VDP in sega2 the following set of values for the bits CD5-0 are given with the resulting effect when they're used in a VDP command.

CD5-0=%000000: VRAM read
CD5-0=%000001: VRAM write
CD5-0=%000011: CRAM write
CD5-0=%000100: VSRAM read
CD5-0=%000101: VSRAM write
CD5-0=%001000: CRAM read

However, it doesn't state what happens when a value not on this list is used (for example, CD5-0=%000010). Has anyone tested these values? What happens?

Jorge Nuno · Post by **Jorge Nuno** » Sun Mar 21, 2010 11:55 am

CD5 is used on DMA transfers and fills, CD4 on VRAM copies, other command bits combinations aren't known.

Ketsuban · Post by **Ketsuban** » Thu Mar 25, 2010 12:52 pm

It was those "not known" commands I was hoping for more information on, hence the example I gave. :P

koilazka · Post by **koilazka** » Thu Mar 25, 2010 6:38 pm

VDP writes work in words, $hhhh, 16 bit.

The first 2 bits of the word, cd1, cd0, control the instruction type & size, 16bit or 32bit.

cd1 cd0 xxxxxx xxxxxxxx

00: 32bit data movement instruction.
01: 32bit data movement instruction.
10: 16bit video setup instruction (background colour, SAT address).
11: 32bit data movement instruction.

10000000 00000000 = video setup instuction $80 (mode set #1).

Sorry about my terminology.

Gigasoft · Post by **Gigasoft** » Thu Mar 25, 2010 10:35 pm

My guesses:

xx0111: write same value to CRAM and VSRAM?
xx1011: short circuit or AND/OR to CRAM?
xx1100: short circuit or read AND/OR between CRAM and VSRAM?
110100: duplicate high bytes from VSRAM to VRAM or copy high bytes within VSRAM, setting low bytes to unknown value?
111000: duplicate high bytes from CRAM to VRAM or short circuit?

Perhaps someone could test these hypothesises. Maybe these unknown commands just do nothing.

Eke · Post by **Eke** » Fri Mar 26, 2010 8:26 am

Gigasoft wrote: Maybe these unknown commands just do nothing.

most probably, just like writing DATA port after setting a read operation does nothing.

about the possible bits combination, here are some hypothesis:

CD0 indicates the type of memory access (1=write access, 0= read access) with the exception of %000010 being a register write (could be interesting to read DATA port with the code bits set like this). Interestingly enough, all DMA operations are write operations, with the exception of DMA copy which obviously need a read from VRAM first.

CD1-CD3 indicates the memory location (VRAM,VSRAM or CRAM). DMA operations always set VRAM as destination but it seems you can do a DMA fill to VSRAM and CRAM as well (not verified), nothing being known about DMA Copy. I suspect that the only supported values are the one we know, other values being ignored.

CD4 is only used by DMA Copy, so it could indicate a special VRAM access type ("write back" ?). It could be interesting to see how it works outside DMA (and what happen to DMA fill if it is not set)

CD5 is a mode bit used to trigger a DMA operation if DMA is enabled, nothing tricky about this one I guess.

Ketsuban · Post by **Ketsuban** » Fri Mar 26, 2010 11:00 am

Thanks for reminding me about CD1-0=%10 setting the registers, I apparently had a brain fart and forgot about that one.

That means I can fill in my list some more.

CD3-0=%0000: VRAM read
CD3-0=%0001: VRAM write
CD3-0=%0010: VDP registers write
CD3-0=%0011: CRAM write
CD3-0=%0100: VSRAM read
CD3-0=%0101: VSRAM write
CD3-0=%0110: VDP registers write
CD3-0=%0111: ?
CD3-0=%1000: CRAM read
CD3-0=%1001: ?
CD3-0=%1010: VDP registers write
CD3-0=%1011: ?
CD3-0=%1100: ?
CD3-0=%1101: ?
CD3-0=%1110: VDP registers write
CD3-0=%1111: ?

I'd also forgotten about CD5-4 being for DMA, so I'm going to ignore those for the moment (though Eke's suggestions for experimenting with DMA apply).

Eke · Post by **Eke** » Fri Mar 26, 2010 12:24 pm

well, $xxxx10 will always trigger a register write , but what would need to be tested is what happen if you try to read/write the DATA ports after setting the code register like this

Also note that writing a register will reset the CTRL port pending flag so you would need the following sequence to test all CD5-CD2 possible values:

(1) read CTRL port (CTRL port pending flag is cleared)
(2) write CTRL port with anything else than a register write (dummy write to set CTRL port pending flag)
(3) write CTRL port to set CD5-CD2 bits and VDP RAM address MSB (CTRL port pending flag is cleared)
(4) write CTRL port with CD1-CD0 set to 10 (register X is written and CTRL port pending flag is cleared)
(5) read DATA port : does it read a valid VDP VRAM location ? from which address ?

On a semi-related note, you could also verify that the code & address MSB are not reseted when a register write is issued (or more generally when CTRL port pending flag is cleared) by doing this instead:

(3) write CTRL port with CD5-CD2 set to 0001 and address MSB different from 0
(4) write CTRL port with CD1-CD0 set to 10 (register X is written and CTRL port pending flag is cleared)
(5) write CTRL port with CD1-CD0 set to 01 and address LSB = 0
(6) write DATA port: does it go to to VRAM or VSRAM ? is it written at address 0?

Gigasoft · Post by **Gigasoft** » Fri Mar 26, 2010 12:35 pm

According to Charles McDonald, CD4 does nothing in non-DMA mode. A register write changes the mode to VRAM read if I understood this correctly, but the effect on the current address is unknown.

Another thing to try is setting CD4 to 0 with VRAM copy mode selected in register 23, or setting it to 1 with VRAM fill mode selected. (Normally, it's 0 when doing a VRAM fill.)

The two different bits for CRAM reads and writes could be due to having a separate read and write port for CRAM, or a separate read and write enable.

koilazka · Post by **koilazka** » Fri Mar 26, 2010 1:57 pm

I did a little test, not a good one.

Wrote a pallet to cram, set background to colour 0 (pink).
Wrote a blank (0000..) pattern, then 4 test patterns to vram.
[1][2][3][4]

Wrote them acrross plane B top 2 lines.
[1][2][1][2]...
[2][3][2][3]...

Then executed the video instructions and filled vdata with 128 bytes of $ee.

// 000111 c0000010 no change
// 001001 40000020 no change
// 001011 c0000020 no change
// 001100 00000030 no change
// 001101 40000030 no change
// 001111 c0000030 no change

Things could have been happening to Plane A, Window, etcetra.

Guess you could do vctrl reads, then disable the display if something was different.
I would test more, but writing other things.

Alex Khan · Post by **Alex Khan** » Sat Mar 27, 2010 5:45 am

Hello,

Where can a Noob like me learn more about VDP commands such as producing special effects and stuff.

How much ASM do I have to know to understand these VDP effects?

Shiru · Post by **Shiru** » Sat Mar 27, 2010 9:18 am

Alex Khan, read the official documentation, known as sega2.doc. It is a must for any SMD programmer. You don't have to know assembler to work with hardware, you could access to it from C as well.

VDP has no commands and thus not able to produce special effects through commands.