Hmm, debating IO -> VGAs comms again.
Constraints:
- lots of pins on VGA available (now that IO is doing all the funny business)
- not many pins on IO available (now that IO is doing all the funny business)
- assuming Z80 -> IO -> VGA, so we want to minimize any additional latency
(not that since we have IO in the middle, and framebuffer or sprites possibly on either/both IO and VGA, its not as bad as you may suspect; z80 can issue command like 'move everything up' and IO and/or VGA can just do that..)
- VGA has to be non interrupt driven messaging (or at least, interrupts only occurring during vblank)
Again, this is a subsystem that can be improved enormously later, but I am going for the Cheap Fast Hack now. Limited time means cheaping everything
Once the VGA code is written nicely and tightly, we can get much higher reoslutions, and much more flexibility in communications.
Updated schem so far:
So you'll notice I moved the VGA stuff all to one side, so the other is free; theres not much free on the IO chip, but we can use the 2 i2c pins, and a cople of the ISP programmer pins IO_MISO and IO_SCK, and VBLANK. So thats 4-5 pins available on IO.
Some easy options..
- i2c as intended .. leverage some hardware in the avr mcu's, but tends to imply (but not require) interupts at haphazard times. We could probably do it without interupts, but meh.
- bitbang it out; not too bad, but at fist blush lots of twiddling pins to ACK receival of a bit or bitpair, that sort of thing; given our slow speed (currently default 8MHz on the avr, or coudl add a clock to drive it up to 16 or 20), all those twiddlings will slow us down, and also get in the way of the VGA mcu, who is busy as hell. We'd end up only getting a few bytes over per vblank or something
- SIPO shift register (serial in, parallel out); this would need 4-5 pins .. data pin to register, shift clock, store clock, and maybe a 'data is ready' to the VGA mcu; we can use a single register, or even two (chain them together for no additional pin cost.) This would get us an 8bit or 16bit parallel right into the VGA. Its still 'slow' (we have to twiddle pins on the IO chip side), but its fast on the VGA side (it can, at its leisure check and see the 'data ready' pin is high, and then just read the byte or two off the side, and thats in.
---> so the SIPO register may be the way to go; any work/twiddling is done on the IO chip side (slow, but not screwing up our VGA display) and then twiddle one pin and boom, the VGA chip gets it.
So if we use 2 registers (16 bits), we can do something like a packaged command-message:
byte 0: command (or even, if limited to 16 commands, could be 4bit command, 4bit data)
byte 1: 8bitdata
example commands:
in text mode:
cmd 10: block data receive, see data for block length (then receive 2b data blocks until count is done)
cmd 11: set cursor X, see data for X coord
cmd 12: set cursor Y, see data for Y coord
cmd 13: append character, see data for character
cmd 14: clear screen
in graphics mode:
cmd 10: as above .. receive say a sprite data, or raw (x,y) point data, or (x,y,x,y) line data...
cmd 11: clear screen
cmd 12: set colour
.. etc.
So that'd work pretty well as a protocol to VGA.
(and framebuffer woudl be on VGA, and maybe some buffering on IO. So its a serialized interface to text/vga, which is goofy, but simple.)
(for true RAM bitmapped framebuffer, you just don't get too easy an interface; go back to zikzak-r3 for that sort of thing in minimal form; if we want bitmapped RAM onto screen, its going to be adding another bigger VGA chip or designing our own discrete video card, or other various heavy options; for this low low end, minimal chip count zikzak, it seems out.)
But how fast would it be?
vsync itself is only 3-4 'lines'; 'back porch' is 23-30-odd lines. VBLANK is the combination of vsync and back porch. I forget the timings entirely and too lazy to work it out, but at 20MHz we get say 100 instructions per line (wild guess.) If we're 8mhz, .. half that.
FWIW, the 20MHz clock on the board can probably drive both mcus (no need of a second clock); worst case, we have the VGA CKOUT pin (clock-out) turned on, and drive IO; in theory having both at 20mhz should be fine, just not done yet.
So we get up to a couple thousand cycles in IO, per vblank.
cycles needed at least, per datum are..
begin loop:
set data pin 1 cycle
set registers shift high 1 cycle
set registers shift low 1 cycle
shift data over 1 cycle
end loop 1-2 cycles for the loop handling
<do the loop again, for second byte>
set registers store low 1 cycle
set registers store high 1 cycle
.. so about 100 cycles per 16bit at a WAG (wild ass guess)
this suggests about 40b or more sent through the pipe during vblank. Thats not too bad. I mean, for text mode its plenty. For graphics mode.. for linedraws and such, its not too bad... but raw 'heres a pile of data', its pretty crummy.
ie: Say we're doing a 40x40 low res screen, we're talking 40 VBLs to render a full screen .. ie: 2/3rds of a second just to draw a full picture. If we'r doing a high res screen, say 240x240, its many seconds to update the full screen. Poor.
Not to mention that we're talking z80 -> IO -> VGA, and the z80 is pretty damned slow (and the multi step latency etc.)
So this suggests we want a command based protocol, leveraging the mighty framebuffer on the VGA (currently a whopping 4K, but if we use a atmega1284 I've got on hand, thats 16K, which is a raw 120*120 display without any tricks at all. If we do small sprites, we could do a lot of tricks, or compress things in various ways.. or add external ram to that guy, etc and so on.)
ie: in graphics mode, we'd want to limit how much data we're sending per second, as dumb as that sounds
....
So, hmrf, maybe using a SIPO shift register or two would be a neat way to get data into VGA, easily and 'fairly quickly', without much brains on our part; but at the chipcount +1 or +2.
.... and really, it all makes me want to toss this whole thign out, and go for a real framebuffer again. It was really fun having a true framebuffer in zikzak r3 .. made coding very easy, made everything fancy and high res and fun. But pretty complex, and a nightmare pcb to design, and expensive to make
Going cheap and dumb and spare time sure makes things painful
jeff
