Project RAD

(It seems hackaday.io ate all of my images... oh well)

RAD uses a tile-based rendering system. Everything on screen is either a background tile or a sprite tile. Each tile has attributes, one of which is a palette ID pointing to one of 4 palettes of 16 colors each.

Palette entries are 8 bit, using the RRGGGBBS encoding. 

This encoding gives us a 256 color subset of the 512 color RGB333 color space where red and blue share the lowest weighted bit. It requires a 9 bit DAC and 9 output pins from the FPGA.

We considered other encoding schemes like RRGGBBSS and RRRGGGBB, but we settled on this one because it gave us real neutral grays and a good assortment of hues.

This is the main RRGGGBBS palette and it's associated color spectrum :

For comparison, here is the Sega master system RGB222 palette sorted by hue with associated spectrum :

I don't have a spectrum for it, but here is the gamma correct NES palette for reference :

Our rejected alternatives :

RRGGBBSS, a 256 color subset of the 4096 color RGB444 space. Lots of shades but many missing hues. Very crunched reds. Requires a 12 bit DAC (3 more resistors not a big issue. 3 more output pins from the FPGA... more problematic).

RRRGGGBB, terrible grays. Otherwise a pretty good assortment.

Performed some measurements with the logic analyzer to see how close we were regarding rendering time.

Game resolution on RAD is 256x240. Since composite monitors are getting less and less common, we upscale to 512x480 and add black bars on the sides to display on a VGA monitor.

Render, upscale, display

Our upscaling method is very simple. RAD has no framebuffer, rendering is done line by line to a pair of 256 bytes line buffers. One buffer is displayed while the other one is rendered to and we swap every second display line (every game line). We also display each horizontal pixel twice so each chunky game pixel corresponds to 4 small VGA pixels.

First we render all background tiles to the line in order and then we check the sprite attributes and render those that are visible on the current line, up to our maximum of 16 sprites on a single line.

Each line is displayed twice on the VGA port so we have a total of 63 microseconds to prepare the next game line.

Timing analysis

M1 marker indicates the end of background tile rendering which started on the first new_line pulse (M4 marker). Elapsed time for rendering the background tiles is 23 microseconds.

M2 marker indicates the end of sprite rendering. In this test, there are 16 sprites visible on the line, which is our worst case scenario. Elapsed time for sprite rendering is 17 microseconds.

At this point, render_state goes to WAIT for 23 more microseconds while we are displaying, but not rendering.

Opportunities

I am tempted to signal the end of line processing using the FIRQ line to the CPU.  At 3.6864MHz, 23 us translate to only 84 cpu cycles. It might just be enough to send a couple palette entries and allow for cool palette tricks.

It's worth a try if I can find a tiny bit of space in the FPGA (currently using 576/576 LUTs).

As a test of the sound system here is a recording of the Space Harrier main theme, as arranged for the PC88.

Straight from the console RCA output to the Scarlett soundcard.

https://soundcloud.com/user-28436304/spaceharrier-ym2203-rad86

I added the schematic for the current board revision.

So far I know of 2 problems in this revision :

1. I used the wrong footprint for my pcb-mounted buttons at the front and therefore I cannot mount them.

2. My soft power-ON/OFF scheme only works when it is the only part of the board that is assembled. When everything else is mounted, power state just follows the state of the button. I make do with a jumper on the PW SW pins for now.

I had made a cute little simulation of the circuit, but it did not survive contact with reality. I blame my very limited analog design skills.

Controllers 1 and 2, connected to VIA1 are now fully operational.

I bought a few of these inexpensive Hyperkin GN6 controllers and so far I like them very much for the price.

Got the VDP working with hardware scrolling in both directions.

It's a tight fit but I am very happy!