Video - Update 2

A little more progress made.  I have routed the R2R DACs and HSYNC and VSYNC signals to a 4x2 pin header.  This will go out to a chassis mounted VGA port.

I think I have mostly worked out how I'll coordinate between the two GPU.  I have introduced a D-Type Flip-flop to perform the role of a hardware mutex.  When the GPU AVRs start up, they will read the value on their PORTD5 pin.  The left hand GPU PORTD5 pin will be connected to the Q output of the Flip Flop and PORTD5 on the other GPU will be connected to Q'.  Whichever GPU reads a high value is going to render while the other will perform the RAMDAC role.  Then the Flip-flop flips, the roles will reverse. 

The RAMDAC GPU will be responsible for handing off to the other.  The hand off process will look like this:

1. At the end of the video frame the RAMDAC GPU will drive the Flip-flop clock pin high causing:
1. The Flip-flop will toggle.
2. The VSYNC will go high (or high depending on how I wire it)
3. The Serial ports will be connected to the new Render GPU.
4. The SRAM data line buffers will toggle their enabled state.
5. The SRAM address line buffers will toggle their enabled state.
2. The new RAMDAC will wait for the VSYNC period and then drive the Flip-flop clock pin low.
3. The new Render GPU will set appropriate pins to High-Z and then can get on with rendering.

Things left to do on the video board:

• Ground plane
• Decoupling capacitors

Video - Update

I have completed a bit more of the routing work on the Video board.  I still need to add decoupling capacitors and fix up a few other things.  I don't have any ground plane yet, that's next - once I figure out how to do it properly in Eagle.

I changed plan slightly with the clear screen counter.  In the end I chose an 8-bit counter.  That means I can clear a contiguous run of 256 pixels without intervention from the AVR.  There is also a jumper selectable 2x or 4x clock multiplier on the counter.  Each AVR will need to increment address bits [8..16] on its own.  That should be fine at 4x since the address will only increment every 64 AVR cycles; that is plenty of time to increment a variable and load a port.

VMS - Getting somewhere

Have thought a lot about the Video board since the last post.  Building a switch for this kind of thing out of discrete logic chips not practical.  I'm limited in my board size in Eagle.  I'm limited in my ability to route the thing anyway.  I have an alternative design in mind.  Instead of having a separate GPU and RAMDAC, I'll just have two GPUs which can also act as RAMDACs:

 

This removes the switching logic and now each GPU has a dedicated SRAM bank. Each GPU will be either in Render Mode or Scan-out Mode.  They will never be in the same mode.  A third AVR controls the two GPUs and tell them what mode to be in.  This coordinator chip also controls which GPU is "writing" to the R2R DAC.

I have also included a clock multiplier and 24-bit counter which will be able to quickly clear the framebuffer.  This will free up the GPU for useful drawing instead of spending 80%-90% of the time clearing the screen.  A clever GPU firmware might be able to sync on this and use the counter for drawing pixel spans of solid colours - yum.

Here is the routing so far...

VMS - Back to the drawing board

Here is the result of 20 minutes work in Eagle on the VMS board.  I have place the 14 74HC157 ICs required to form the switching logic.  I have also placed a header for connection to the GPU IC.  I still have to place a header for each bank of RAM and a header for the RAMDAC IC.

It doesn't take a Rocket Scientist to work out that this is not going to work.  I'm already at the full board size Eagle support for the free version and I don't have any room for routing traces. 

I need to re-think this.  My options are:

1. Abandon the switch and RAMDAC and have the GPU to it all.
2. Come up with a better switch.
3. Use dual-port SRAM.

The first option doesn't appeal to me greatly.  If I lose the switch then I lose the ability to render and scan-out at the same time.  This is a big deal.  Based on the figures from here, active video accounts for approximately 91% of a full second of video. That leaves only 9% of the AVR CPU time to actually render.  My previous design allowed rendering 100% of the time. 

The second option could be solved with something like a FPGA of CPLD. I need to look into the cost of these.  An initial look reveals this one has 120 GPIO pins and is $31.  The other cool thing about an FPGA is that I could move the CLEAR SCREEN command to the FPGA and free up the GPU too.

The third option appears infeasible at this point.  I can find dual-port SRAM at good price.  That said, I could de-solder some from an old video card.  Hmmm, might look into this.  This is the ultimate because it means I can put the GPU and RAMDAC on opposite side of a single RAM IC.  This is likely to be a dead end though as I'm pretty sure all most video cards use a derivative of DRAM, and I'm not getting into that.

VMS - Video Memory Switcher

I drew out the VMS below:

Goodness me!  This looks like PCB routing nightmare.

Block Diagram

A basic architecture is emerging for this machine.  This is basically what I want.  The CPU can address any of the following devices:

• GPU - Graphics Processing Unit
• APU - Audio Processing Unit
• PPU - Peripheral Processing Unit
• RAM - A 512KBytes SRAM.

The interesting thing is that the CPU can't directly access the frame buffer.  The reason I have done this is due to the result of the testing I did in my previous post.  It appears that the GPU is going to monopolise the bus just to clear the screen.  I worked out that if the GPU was in a fact a 16MHz ATMega328 (same as Arduino Duemilanove), then just clearing the screen at 60 FPS would consume 97% of the CPU time and as a consequence a similar proportion of the bus bandwidth.  Now, my GPU will run at 20MHz and I'll probably refresh at 50Hz since but the situation is still pretty dire.

So, the direction I'll take will be to separate these buses.  The CPU will just write commands to the GPU over the Main Address/Data bus and the GPU will render to the VRAM.  This means filling single pixels is going to be much slower but other operations like solid fills should be much better.

There is a potential problem here.  I probably don't have enough pins on the GPU for two address and data buses.  I'll need to work something out here.  I have an idea involving overlapping address spaces and tri-state data buses.  More to follow.

Finally the VMS stands for Video Memory Switcher and is a fancy cross-bar switch.  I got the idea from another project: Lazarus-64

Ok, I have worked out the problem earlier.  The Arduino IDE uses the following compiler flags:

avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=21

This caused my loop to be optimised out!

I worked out how to build and upload outside the Arduino IDE and using an optimisation flag of -O0 I now get 39.6 seconds with the single pixel version.  Writing 8 pixels per loop takes 3.9 seconds.  16 pixels is dispatched in 1.9 seconds and 32 pixels takes 0.97 seconds.  At last now we have some real data!  Here is a graph of those points.

We have certainly reached the point of diminishing returns at 32 pixels.  We might be able squeeze a bit more bit more by increasing the pixels but I tried 64 pixels and I think the Arduino ran out of flash.  So if all we are doing is clearing the screen at 60 FPS, we have a 97% duty cycle.  At 20 Mhz this becomes 78%.  That leaves some time for drawing other things.


Further improvement could be made.  For example, in most games we won't need to clear the entire screen if we track the dirty regions.  Finally, we can always over-clock ;-)

Video Modes

I have been thinking about video modes.

I want to be able to offer both 4:3 modes and 16:9 mode (since most TVs are widescreen now). So I did up a little spreadsheet that computes the Video RAM and pixel clock requirements given that I want the following features:

• Double buffering (2 frame buffers in VRAM with page flipping).
• Clear entire screen at 60 fps.
• 8 bits per pixel (3 bits Red, 3 bits Green and 2 bits Blue)

Having 8 bits per pixel arranged in this way yields a palette like this:

This should look pretty tasty indeed.  Here is the spreadsheet:

width	height	bytes/ page	rounded page	bytes total	SRAM Chip	total waste	A pins/ page	total pins	Pixel Clock	Mode
104	78	8,112	8,192	16,384	(16K x 8)	160	13	23	486,720	104 x 78		4:3 resolutions
144	108	15,552	16,384	32,768	(32K x 8)	1,664	14	24	933,120	144 x 108
208	156	32,448	32,768	65,536	(64K x 8)	640	15	25	1,946,880	208 x 156
288	216	62,208	65,536	131,072	(128K x 8)	6,656	16	26	3,732,480	288 x 216
320	240	76,800	131,072	262,144	(256K x 8)	108,544	17	27	4,608,000	320 x 240
360	270	97,200	131,072	262,144	(256K x 8)	67,744	17	27	5,832,000	360 x 270	1080 mode
416	312	129,792	131,072	262,144	(256K x 8)	2,560	17	27	7,787,520	416 x 312
480	360	172,800	262,144	524,288	(512K x 8)	178,688	18	28	10,368,000	480 x 360	720 mode
512	384	196,608	262,144	524,288	(512K x 8)	131,072	18	28	11,796,480	512 x 384	768 mode
584	438	255,792	262,144	524,288	(512K x 8)	12,704	18	28	15,347,520	584 x 438
720	540	388,800	524,288	1,048,576	(1024K x 8)	270,976	19	29	23,328,000	720 x 540	1080 mode
160	90	14,400	16,384	32,768	(32K x 8)	3,968	14	24	864,000	160 x 90		16:9 resolutions
224	126	28,224	32,768	65,536	(64K x 8)	9,088	15	25	1,693,440	224 x 126
320	180	57,600	65,536	131,072	(128K x 8)	15,872	16	26	3,456,000	320 x 180
480	270	129,600	131,072	262,144	(256K x 8)	2,944	17	27	7,776,000	480 x 270	1080 mode
640	360	230,400	262,144	524,288	(512K x 8)	63,488	18	28	13,824,000	640 x 360	720 mode
960	540	518,400	524,288	1,048,576	(1024K x 8)	11,776	19	29	31,104,000	960 x 540	1080 mode

I have computed the number of GPIO pins required to address one page of the framebuffer.  For example, a video mode of 480x270 (Widescreen) consumes 230,400 bytes per page. Rounding up to the nearest power of 2 and multiplying by 2 (for 2 pages) requires a 512 KByte VRAM.  In order to clear the screen at 60 fps, I need to be able to write 7,776,00 bytes per second.  Now that is a lot of bandwidth for a 20Mhz 8-bit AVR.

Can it be done?  Well, at that resolution I would need 17 address pins per page + 8 pins for the data + 1 pin for SRAM Write/Enable + 1 pin for the page select.  So I'd need 27 GPIO pins in total.  That rules out the ATMega328 (Arduino).  An ATMega164A might to the trick (digikey.com.au) as it has 32 GPIO pins.  So I have enough pins but can I write to the memory fast enough to clear the screen?

In order to test this I dug out my trust Arduino and ran some tests.  Here is some sample code:

void loop() {   time = millis();   addr = 0;   do {     PORTC = (byte)(addr);     PORTC = (byte)(addr>>8);     PORTC = (byte)(addr>>16);     addr++;   }    while (addr < 7776000);   time = millis() - time;   Serial.print("Time: ");   Serial.println(time); }

This is supposed to simulate walking through a 18bit address space (17bits per page + page select).  The idea is that this is basically what is required to clear a 480x270 area of an SRAM chip 60 times.  This runs in 11.2 seconds.  Now the chip is running at 16Mhz in this case, so on a 20Mhz setup the time would be more like 8.9 seconds but I'll stick to 16Mhz for now.

11.2 seconds is far too slow.  This needs to be less that 1 second in order to meet the constraint I set and ideally much less in order to allow some time to draw some other shapes!  There are some things I can do here.  I could unroll the loop a bit.  Given that I'm clearing the screen to one colour I can safely unroll it as much as I like.  This is speed/space trade-off though.  Unrolling a loop uses more Flash but my whole Arduino sketch is on 2990 bytes right now and the target chip has 16Kbytes of Flash so I'm pretty safe.  This is what the code looks like if I unroll the loop by a factor of 8:

void loop() {   time = millis();   addr = 0;   do {     PORTC = (byte)(addr);     PORTC = (byte)(addr>>8);     PORTC = (byte)(addr>>16);     addr++;     PORTC = (byte)(addr);     PORTC = (byte)(addr>>8);     PORTC = (byte)(addr>>16);     addr++;     PORTC = (byte)(addr);     PORTC = (byte)(addr>>8);     PORTC = (byte)(addr>>16);     addr++;     PORTC = (byte)(addr);     PORTC = (byte)(addr>>8);     PORTC = (byte)(addr>>16);     addr++;     PORTC = (byte)(addr);     PORTC = (byte)(addr>>8);     PORTC = (byte)(addr>>16);     addr++;     PORTC = (byte)(addr);     PORTC = (byte)(addr>>8);     PORTC = (byte)(addr>>16);     addr++;     PORTC = (byte)(addr);     PORTC = (byte)(addr>>8);     PORTC = (byte)(addr>>16);     addr++;     PORTC = (byte)(addr);     PORTC = (byte)(addr>>8);     PORTC = (byte)(addr>>16);     addr++;   }    while (addr < 7776000/8);   time = millis() - time;   Serial.print("Time: ");   Serial.println(time); }

40: sts 0x0000, r24 44: sts 0x0000, r25 48: ldi r18, 0x00 4a: ldi r19, 0x00 4c: ldi r20, 0x00 4e: ldi r21, 0x00 50: ldi r24, 0x01 52: ldi r25, 0x00 54: ldi r26, 0x00 56: ldi r27, 0x00 58: std Y+9, r24 5a: std Y+10, r25 5c: std Y+11, r26 5e: std Y+12, r27 60: ldi r24, 0x02 62: ldi r25, 0x00 64: ldi r26, 0x00 66: ldi r27, 0x00 68: std Y+5, r24 6a: std Y+6, r25 6c: std Y+7, r26 6e: std Y+8, r27 70: ldi r24, 0x03 72: ldi r25, 0x00 74: ldi r26, 0x00 76: ldi r27, 0x00 78: std Y+1, r24 7a: std Y+2, r25 7c: std Y+3, r26 7e: std Y+4, r27 80: ldi r16, 0x04 82: mov r2, r16 84: mov r3, r1 86: mov r4, r1 88: mov r5, r1 8a: ldi r17, 0x05 8c: mov r6, r17 8e: mov r7, r1 90: mov r8, r1 92: mov r9, r1 94: ldi r27, 0x06 96: mov r10, r27 98: mov r11, r1 9a: mov r12, r1 9c: mov r13, r1 9e: ldi r26, 0x07 a0: mov r14, r26 a2: mov r15, r1 a4: mov r16, r1 a6: mov r17, r1 a8: out 0x08, r18 aa: eor r27, r27 ac: mov r26, r21 ae: mov r25, r20 b0: mov r24, r19 b2: out 0x08, r24 b4: movw r24, r20 b6: eor r26, r26 b8: eor r27, r27 ba: out 0x08, r24 bc: ldd r25, Y+9 be: out 0x08, r25 c0: ldd r24, Y+9 c2: ldd r25, Y+10 c4: ldd r26, Y+11 c6: ldd r27, Y+12 c8: mov r24, r25 ca: mov r25, r26 cc: mov r26, r27 ce: eor r27, r27 d0: out 0x08, r24 d2: ldd r24, Y+9 d4: ldd r25, Y+10 d6: ldd r26, Y+11 d8: ldd r27, Y+12 da: movw r24, r26

dc: eor r26, r26 de: eor r27, r27 e0: out 0x08, r24 e2: ldd r25, Y+5 e4: out 0x08, r25 e6: ldd r24, Y+5 e8: ldd r25, Y+6 ea: ldd r26, Y+7 ec: ldd r27, Y+8 ee: mov r24, r25 f0: mov r25, r26 f2: mov r26, r27 f4: eor r27, r27 f6: out 0x08, r24 f8: ldd r24, Y+5 fa: ldd r25, Y+6 fc: ldd r26, Y+7 fe: ldd r27, Y+8 100: movw r24, r26 102: eor r26, r26 104: eor r27, r27 106: out 0x08, r24 108: ldd r25, Y+1 10a: out 0x08, r25 10c: ldd r24, Y+1 10e: ldd r25, Y+2 110: ldd r26, Y+3 112: ldd r27, Y+4 114: mov r24, r25 116: mov r25, r26 118: mov r26, r27 11a: eor r27, r27 11c: out 0x08, r24 11e: ldd r24, Y+1 120: ldd r25, Y+2 122: ldd r26, Y+3 124: ldd r27, Y+4 126: movw r24, r26 128: eor r26, r26 12a: eor r27, r27 12c: std Y+13, r24 12e: std Y+14, r25 130: std Y+15, r26 132: std Y+16, r27 134: out 0x08, r24 136: out 0x08, r2 138: eor r27, r27 13a: mov r26, r5 13c: mov r25, r4 13e: mov r24, r3 140: out 0x08, r24 142: movw r24, r4 144: eor r26, r26 146: eor r27, r27 148: out 0x08, r24 14a: out 0x08, r6 14c: eor r27, r27 14e: mov r26, r9 150: mov r25, r8 152: mov r24, r7 154: out 0x08, r24 156: movw r24, r8 158: eor r26, r26 15a: eor r27, r27 15c: out 0x08, r24 15e: out 0x08, r10 160: eor r27, r27 162: mov r26, r13 164: mov r25, r12 166: mov r24, r11 168: out 0x08, r24 16a: movw r24, r12 16c: eor r26, r26 16e: eor r27, r27 170: out 0x08, r24 172: out 0x08, r14

174: eor r27, r27 176: mov r26, r17 178: mov r25, r16 17a: mov r24, r15 17c: out 0x08, r24 17e: movw r24, r16 180: eor r26, r26 182: eor r27, r27 184: out 0x08, r24 186: subi r18, 0xF8 188: sbci r19, 0xFF 18a: sbci r20, 0xFF 18c: sbci r21, 0xFF 18e: ldd r24, Y+9 190: ldd r25, Y+10 192: ldd r26, Y+11 194: ldd r27, Y+12 196: adiw r24, 0x08 198: adc r26, r1 19a: adc r27, r1 19c: std Y+9, r24 19e: std Y+10, r25 1a0: std Y+11, r26 1a2: std Y+12, r27 1a4: ldd r24, Y+5 1a6: ldd r25, Y+6 1a8: ldd r26, Y+7 1aa: ldd r27, Y+8 1ac: adiw r24, 0x08 1ae: adc r26, r1 1b0: adc r27, r1 1b2: std Y+5, r24 1b4: std Y+6, r25 1b6: std Y+7, r26 1b8: std Y+8, r27 1ba: ldd r24, Y+1 1bc: ldd r25, Y+2 1be: ldd r26, Y+3 1c0: ldd r27, Y+4 1c2: adiw r24, 0x08 1c4: adc r26, r1 1c6: adc r27, r1 1c8: std Y+1, r24 1ca: std Y+2, r25 1cc: std Y+3, r26 1ce: std Y+4, r27 1d0: ldi r24, 0x08 1d2: ldi r25, 0x00 1d4: ldi r26, 0x00 1d6: ldi r27, 0x00 1d8: add r2, r24 1da: adc r3, r25 1dc: adc r4, r26 1de: adc r5, r27 1e0: add r6, r24 1e2: adc r7, r25 1e4: adc r8, r26 1e6: adc r9, r27 1e8: add r10, r24 1ea: adc r11, r25 1ec: adc r12, r26 1ee: adc r13, r27 1f0: add r14, r24 1f2: adc r15, r25 1f4: adc r16, r26 1f6: adc r17, r27 1f8: cpi r18, 0xE0 1fa: ldi r25, 0xD4 1fc: cpc r19, r25 1fe: ldi r25, 0x0E 200: cpc r20, r25 202: ldi r25, 0x00 204: cpc r21, r25 206: brcc .+0 208: rjmp .+0

The loop time is now 1.8 seconds.  Wow. That really helped.  I have included the assembly output where you can see the effect of the unrolling.  This assembly covers the do() loop only.  Unrolling to 16 pixels per loop yields 545 milliseconds.  Now we are in business.

I need to check these calculations.  I seems unreal that an 8-bit micro can write 7.7 million bytes in 0.5 seconds.  That is a bandwidth of 15.4 MiBytes/second on a 16Mhz part.  Something must be wrong.  I have certainly made a mistake somewhere...