Changes
V9990
,/* Technical */
The official 'Application Manual' describes the V9990 ports, registers and commands. These additional notes apply to the V9990 used in the CPC Powergraph video board and explain details that are not clearly described or are omitted from the manual.
* Reading from the Kanji ROM ports without a Kanji ROM returns databus values
=== Ports and registers ===
* Reading from the write only ports (or unused ports) returns databus values.
* If you read from a write-only register you will see data-bus value because the V9990 doesn't assert data on the bus.
* Some registers have additional bits which are not documented. The mask describes which bits are read/write and which are unchanged.
* VRAM read/write via registers, 0,1,2 and 3,4,5 and port 0 use *logical* addresses and not physical addresses. Writing in one mode, and then reading back in another can yield different data because the addresses are translated from physical to logical based on the mode.
=== Reset ====
* After reset (including software reset using the control port), all registers are reset to 0. In addition the selected register (port 4) is set to 0 and read and write increment are not inhibited.
* If using software reset and the reset is held, then reading or writing to the vram data port will cause the CPC to hang. I believe it's asserting /WAIT but I can't confirm.
=== VRAM ===
* In terms of physical addresses, if you consider physical address 0-&3ffff to be VRAM0 and physical address &40000-&7ffff to be VRAM1, then in P1 mode, the physical address equals logical address and in bitmap modes, every even address maps to &0-&3ffff (ever even is VRAM0) and every odd address maps to &40000-&7ffff (VRAM 1). This is described in the PDF.
* setting a partial vram write address is ok. e.g. set r0,r1,r2 to &80000, now set r1 to 1. Write will go to 000001. Now set r2 to 2. Write will go to 000201. Now set R3 to 3. Write will go to 030201. There doesn't appear to be a write buffer.
* v9990 seems to have a 1 byte read buffer. Setting a partial address and the reading vram will return the data from the previous address for the first read, but further reads returns correct values. This is only true of r3 and r4. e.g. set r3,r4,r5 to &80000. Now set r3 to 1. First read will come from &000000, second and subsequent reads now come from &000001. Now set r4 to 2. First read comes from &000001, second and subsequent reads come from &000201. Now set r5 to 3. First read comes from &030201, subsequent reads come from &030201.
=== POINT ===
* When reading 2bpp and 4bpp data with the POINT command in bitmap modes the pixel is moved into the topmost bits.
The undefined 'x' appear to be from the upper byte when doing a 16-bit pixel read but more testing needs to be done to confirm this.
* BMLL command: When DIX=0, then both source and destination vram addresses are incremented. When DIX=1, then both source and destination vram addresses are decremented.
* BMLL command: I can't currently see what DIY does in respect of BMLL.
=== PSET ===
* PSET seems to use an internal x and y coordinate.
* During testing I found that the 'advance' part of the PSET command differs slightly from the official document.
- The document claims that when AXE and AXM bits of the command are 0 then both DX and DY registers are read and the internal x and y are updated. I didn't find this. I found that when AXE and AXM are 0 then only the DX register is read and the internal x coordinate is updated from it. DY is not read at this time. Testing also shows this happens at the start of PSET command execution.
- If DY register is written the internal y coordinate is updated immediately.
- The internal X and Y coordinates are incremented or decremented based on AXE, AXM, AYE and AYM. The internal x and y will wrap within the width and height of the display. e.g. When the screen is 256 pixels wide, x is 0 and is decremented it will wrap to 255 and if x is 255 and is incremented it will wrap to 0. The same is true of the Y coordinate.
* With the command engine, tested on PSET currently (but to be confirmed for other commands):