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).