From DaphneWiki

Revision as of 05:23, 12 February 2014

Star Rider Main CPU Board

ROM program memory map

Page System

Star Rider employs a wacky paging system where it can modify what the address from 0-0x9FFF points to in real-time. This is most likely to workaround the 16-bit address limit of the 6809E CPU. Executable code can and is paged in and out, making reverse engineering more difficult.

The page value is 4 bits so has a theoretical range of 0-0xF however in practice it appears likely that the bits of the page value are mutually exclusive (ie valid page values would be 0, 1, 2, 4, and 8 only).

Writing

Writing to 0-0x9FFF will always modify video RAM as long as bit 3 of the page value is not set (ie page value < 8). See DMABUSS' signal below.

Reading

Reading from 0-0x9FFF is more affected by the active page value than writing.

Page 0

The default page where most of the program ROM is accessible.

Page 2

When reading when page 2 is active, the following occurs (assuming address is 0-0x9FFF):

ENBUSS' goes low. Assuming HALT is low, the DMA address bus will equal the CPU address bus. The CPU data bus will get whatever is on the DMA data bus.

Page 4

Loads an alternate ROM program.

Page 8

Unknown

PIA hookups

VGG U7 to PIF U1

Schematic signals of note

BIG9'

Active (low) if page bit 0 is set (ie page value is 1).

BI-PHASE WINDOW

Is high when there is bi-phase encoded data (such as the laserdisc picture number) available to be read from the laserdisc video signal. Will be high when vertical line count is 17 (of the top field), or when the (vertical line count >= 0xF1 and <= 0xFE).

CS TOP'

VGG 1/5, this is low if DMA address >= 0xC000 . DMA address will match CPU address is ENBUSS' is active (low).

DMA'

This gets enabled (low) if CPU is writing to address 0xCBB0-0xCBBF (controlling the special Williams blitter ICs).

DMA Address Bus

DMA Address bus will match the CPU Address bus (ie the CPU can control it) if ENBUSS' is active (low) and if HALT is inactive (low, when the blitter chips are idle).

DMABUSS'

This gets enabled (low) if:

1. Address is 0-0x9FFF AND
   1. (when CPU is reading) Active page is 1,2,3,5,6, or 7 (ie not 0 or 4, and less than 8)
   2. (when CPU is writing) Always enabled if active page < 8

DMA Data Bus

DMA Data bus will match the CPU's data bus if ENBUSS' is active (low). Both read and write directions are supported.

DMA R/W'

This signal indicates read/write direction of the DMA bus.

If the blitter chips are active (HALT being raised), then they drive this signal directly. Else, the signal is derived from a series of gates in conjunction with an open collector output and a pull-up resistor.

The value of this signal is low (write) if:

1. CPU R/W' is low (write) AND
2. HALT is low (blitter inactive) AND
3. WCNT' is active (low)

Else the value gets pulled high by a 4.7k pull-up resistor (meaning it's in read mode).

ENBUSS'

I believe this stands for Enable [DMA] bus and refers to either writing to the special blitter chips or reading/writing to DMA (video) memory. This gets enabled (low) if:

1. HALT (VGG) is low AND
   1. DMABUSS' is low OR
   2. DMA' is low (0xCBB0-0xCBBF address)

END SRN'

Same signal as VERT BLANK'

FIELD

Top/odd field is low, bottom/even field is high.

HALT (VGG)

HALT originates from the special Williams blitter chips. It appears to prevent most of the ICs related to video RAM from functioning, presumably to allow the blitter to have full control over the DMA bus. HALT does not halt the main CPU. Instead, it appears to be connected to the main CPU's FIRQ through the PIA (U7?) on the VGG board. If the main CPU attempts to do a DMA-related operation while HALT is active, the operation appears to just get dropped as a NOP. I will hopefully know more later.

IMAGE WR'

Will be active (low) if:

1. Page bit 0 is set (ie page value is 1) AND
2. Page bit 1 is not set (ie page value is not 3) AND
3. WRX' is active (low) AND
4. WCNT' is active (low) AND
5. Page bit 1 is not set (this is a redundant check)

OERAM'

I believe that this stands for Output Enable RAM, and it is active low. It defines the conditions when the video RAM may be read by the CPU.

It will be active (low) when:

1. DMA R/W' is high (read) AND
   1. Image Page (PP) is 0x1E and bit 0 of active page value is 1 (ie page value is 1) OR
   2. Image Page (PP) is 0x1F OR
   3. Bit 1 of active page value is 1 (ie page value is 2)
2. AND
3. Address < 0xc000 AND
4. XDMA is disabled (high)

OEROM'

I believe that this stands for Output Enable ROM, and it is active low. It defines the conditions when the ROM board may be read by the CPU.

It will be active (low) when:

1. DMA R/W' is high (read) AND
2. OERAM' is disabled (high) AND
3. XDMA is disabled (high)

VERT BLANK'

This value is latched depending on the current vertical count (see timers & counters section). Will changed to active (low) if vertical count & 0xFE is 0. Will changed to inactive (high) if vertical count & 0xFE is 0x10.

Note that this does not quite match the actual vertical blanking period of NTSC which suggests that the vertical count is offset somewhat. Line 23 (where line 1 is the first line in the top field) is typically the first visible line after vertical blank ends.

WCNT'

Will be active (low) if:

1. ENBUSS' is active (low) AND
   1. CPU address < 0x8000 OR
   2. Image page is not 0x1E OR
   3. Active page value >= 8 (bit 3 is set) OR
   4. CPU R/W' is high (read mode)

WRX'

Same as the CPU's R/W' being low except the timing window is shorter (more strict). This will be low (active) if E and Q are both high, and R/W' is low.

XDMA'

VGG 1/5 XMDA will be active(low) if DMA' is active (low) and HALT (vgg) is inactive (low).

It is active when CPU is attempting to write to 0xCBB0-0xCBBF (blitter chips) and the blitter chips aren't already busy doing a previous operation.

Colors

The color RAM (0xC000-0xC7FF) holds 0x400 bytes of data (10-bit address). However, it is split up into 4-bit nibbles, where the first even address refers to the first nibble, the first odd address refers to the second nibble, and so on. So for example, if I write to 0xC000, I would be writing to the first nibble of the first color. If I then wrote to 0xC001, I'd be writing to the second nibble of the first color. The first nibble holds color info for red (lower) and green (upper). The second nibble holds info for blue (lower) and luminosity (I think?) (upper). So the color palette has a range of 16-bits if I am understanding this right. At the very least, it is 12-bit color (just like my beloved Apple //gs had!)

Color Palette

When CBE0-CBEF written to, it updates U94 on the VGG board (74LS374 octal register) with the current 8-bit value on the data bus. Only the bottom 6 bits are used. The output of this register is enabled as long as the CPU's memory address is not in the 0xC000-0xC7FFF range.

The value written here is latched as the upper 6 bits of the color RAM internal address (used by the hardware to lookup a color value).

The lower 4 bits are changed by the graphics hardware at will and refer to the active color index.

This means that each color palette can hold 16 colors and there are 64 total color palettes available. (seems like it would've been a lot cooler if there had been 16 total color palettes with 64 colors each!)

Laserdisc background

Color 0 is the transparent laserdisc background (see VGG 4/5 schmatic A2).

Timers and Counters

Clocks

Master

The master clock is 24 MHz and is located on VGG 3/5.

12 MHz

The master clock immediately gets divided in half to create a 12 MHz clock. This clock is used to update an 8-bit flip flop (U101), to generate a 6 MHz clock, and to influence the CAS' signal.

U114 PROM

This 32-byte PROM is like a fancy gate array to describe how the 6 MHz clock will influence a bunch of signals. The high bit of the address (bit 4) alternates with each clock. The lower 4 bits of the address get the value of the lower 4 bits of the data that the address contains, hence the lower 4 bits of all data are a GOTO.

The PROMs contents are:

Unknown counters

On VGG 3/5, there is an 8-bit counter on the far-left, about halfway down. This counter increments (via a 4 MHz clock) until it hits 228 at which point it lowers the "INCREMENT VERTICAL COUNT" line and waits. More details later, hopefully.

Vertical Counters

The vertical counters are three 4-bit counters for a theoretical size of 12-bits. However, only the lower 9 bits are used. The lower 8-bits correspond to VA6-VA13 on the schematic. The 9th bit apparently does not ever make it to the video address bus.

By sniffing vsync and the vertical counters on the real Star Rider hardware, we've learned that the vertical counter is equal to 1 when the NTSC top field line number is equal to 8. Or in other words, vertical count is offset 7 from the NTSC line number (where the first line of the NTSC top field is 1, not 0). Behavior for bottom field is unknown but most likely very similar. This means that a vertical count of 0xB (11) is NTSC line 18, which contains the laserdisc picture number on it. When the vertical count is 0xB, the hardware enables the BI-PHASE WINDOW signal to read the picture number (which is precisely what we would expect).

Expander Control

The video expander will always get disabled when the vertical counters exceed 0xB4.

Horizontal Counters

The horizontal counters are two 4-bit counters that make up an 8-bit counter. The bits correspond thusly:

The horizontal counter increments every 0.5 microseconds. It gets reset at the end of the HSYNC pulse (ie when HSYNC pulse goes high). It is used to generate the HSYNC pulse if the laserdisc's video signal is not present. HSYNC from NTSC signal is supposed to be about 4.7-4.8 microseconds long. (It is almost exactly 4.68uS on raspberry pi + LM1881 CSYNC pulse.) If the board has to generate the HSYNC pulse (due to the lack of a laserdisc video signal), this pulse will be low for exactly 4.5 microseconds.

The horizontal counter will loop from 0-129 continuously. Hsync will be active while counter is 121-129 (9 0.5 microsecond periods, or 4.5 microseconds).

For reference, a horizontal line is supposed to be approximately 63.5 microseconds long. The exact length of a horizontal line is H = (1001 * 1000000 * 2) / (1000 * 60 * 525) microseconds.

If the board is generating HSYNC, its horizontal lines will be exactly 65 microseconds long (130 0.5 microsecond periods).

HSYNC VGG

HSYNC VGG is the pulse that the board will generate if HSYNC DISC is not available. HLOAD is the complement of HSYNC VGG and leads it by 1 clock. HLOAD can be calculated as:

hload = (((hcount & 120) == 120) || ((hcount >= 128) && ((hcount & 1) == 0))) ? 1 : 0;

Or in other words, HLOAD will be high if hcount >= 120 and hcount <= 128, which means HSYNC will be low when hcount >= 121 and hcount <= 129. LOAD will only go low when HLOAD and HSYNC are both low, which only happens when HLOAD goes from high to low. When LOAD goes low, the counter resets to 0.

Each row in the table below represents a positive transition of the 2 MHz input clock.

Video

Using the schematics to understand how the video RAM maps to the pixels rendered on the RGB monitor is quite a difficult and slow process.

Total video memory capacity: 384x256 pixels Total video memory that is addressable by the CPU and blitter ICs: 320x256 pixels

^ - this took me FOREVER to figure out! so hard!!!

The video memory is composed of six 8k DRAM chips for a total storage capacity of 49,152 bytes. Each byte contains two pixels, thus giving a total capacity of 98,304 pixels. The video hardware will render 6 pixels every 1 microsecond to the monitor (via a 6 MHz clock). The video hardware also uses the horizontal counters (divided by 2) to keep track of the horizontal position of the CRT gun. The horizontal counters loop from 0-129 which means that horizontal resolution is effectively (129/2 * 6) which is 384. Boom! This took me forever to validate even though I suspected it for quite some time because I had mistakenly calculated the DRAM size as being 2k, not 8k. 98,304 divided by 384 gives us our vertical resolution of 256.

How did I conclude that the addressable video memory is 320x256? I did it by emulating the game far enough to take some screenshots. But it's easier in hindsight. I already knew that the video RAM ranges from 0-0x9FFF so simply dividing 0xA000 by 256 gives 160 bytes per line. And there are 2 pixels per byte, hence 320 pixels per line.

How does the game hardware know where to put these 320 pixels on this 384 pixel line? By the Horizontal PROM, U74.

See: http://www.daphne-emu.com/graphics/starrider/rug.png

SER0-SER3

The 4-bit value here is the 4-bit color index to be rendered to the monitor at any given time. It is influenced solely by the horizontal and vertical counters which are in sync with the video signal's vertical and horizontal sync signals. The color index is translated into an RGB value by the circuitry on VGG 4/5, using the active color palette and the color palette RAM.

This value comes from a set of 74LS166's (known as "pixel shift register"s on VGG 2/5). These registers hold 6 bits each, and there are 4 of them, hence the registers hold 6 pixels at a time. After each set of 6 pixels has been rendered, the next set is loaded in via the SRL' line (active low) and the low->high transition of the 6 MHZ clock.

The pixels will be available on the bus to be loaded in because of the values of the MUX0/MUX1 lines in conjunction with the current value of the horizontal and vertical counters.

DRAM layout

On the schematic, each DRAM shares the same 14-bit address, which will change depending on whether video hardware is reading the memory in order to render it to the screen, or if CPU/blitters are doing I/O. The data lines of each DRAM are labeled Zn1-Zn4 where n is 1-6 for each DRAM.

For any given 14-bit address, the DRAMs combined simultaneously present 24-bits on the data bus, or 6 pixels (where each pixel is 4 bits). So when rendering pixels to the screen, the hardware puts a 14-bit address on the DRAM address bus, then reads in 6 pixels into three 8-bit shift registers. After the shift registers have rendered the 6 pixels, the process repeats and the next set of 6 pixels are read.

DRAM 1 will present the first 4-bit pixel, DRAM 2 will present the second pixel, etc.

Video Address

The schematics have the concept of a video address which is calculated by the following method:

Video Address = ((vertical counters & 0xFF) << 6) | ((horizontal counters & 0x7E) >> 1)

The lower 8 bits of this address become the DRAM's "row" bits, while the upper 6 bits became the DRAM's "column" bits.

Here are some examples of a theoretical video address and its row/column bits.

Mapping of CPU address to video address

This mapping is partially handled by the U74 PROM on the VGG board.

The lower 8-bits of the CPU address are the vertical coordinate on the screen (there are 256 lines). So it's a little backward from the usual standard of top-to-bottom, left-to-right. The upper 8-bits of the CPU address refer to the horizontal coordinate, but since they can only cover a range of 0-159 (0-0x9F), they get filtered through the U74 prom which will translate the coordinate so as to add horizontal margins on the left and right side. Remember, that one byte holds 2 pixels, so a range of 0-159 can describe 320 horizontal pixels.

When CPU writes to video memory, a full byte is written to two of the six DRAM chips simultaneously. A byte may be written to DRAM 1/2, 3/4, or 5/6. In other words, writing a byte to video memory will change 2 pixels (like you'd expect).

The CPU's address is filtered through U74 PROM. The PROM decides which pair of DRAM chips the address maps to. It may also opt to make the write a NO-OP by not enabling any of the DRAM chips for writing, but from what I have seen, it will never do this if the address is in range of 0-0x9FFF.