Another late-night post for you
Story of my life..
Astute followers may have noticed that rev1 GPU pcb doesn't have the RAM bus and control lines; the board is fairly tight as-is, and I was hell-bent on getting it done by a (arbitrary) date, so it could get finally sent out and back to me for fun fiddling. Fusk it, I says, wanted to see if the thign would work 'at all' in pcb form, and I've not 'well defined' the RAM bus on the base-pcb and cpu-adaptor boards yet. (Its a fair number of pins.. most of the little 8bit cpu's can't address a lot of RAM anyway, but the bus for zikzak is up to what, 20 or 21 max pins for addresses (due to cart limits, you can go more if you're skipping using the default cart system), plus the 8 data pins, plus some control lines (plus the other lines.. power, flags like vblank, some misc gpios, etc and so on.) So add another 16+ for address, 8 for data, say 8 for control and flags.. thats another 32 points of header on there, and all the routing to make it happen. Later, baby
Anyway, so that left two slower but easier to prototype with GPU control systems, and could still proto the RAM bus on the break-out pins. (And if you notice, the STM32F405 that I'm using is the 64pin one, which may not be enough pins to run the RAM bus anyway, depending how we limit it.) For the full RAM bus supporting board, I might make it a slightyl larger board, and use the 100pin QFP version of the chip; more pins to play with, but also means another 32 header pins for breakout, and the 32+ pins for the RAM bus. Bleh
Of interest.. the rev1 GPU pcb supports serial and i2c control (or others via BoB headers.) One serial (usart2) is assumed to be console and is wired to the IO header (and I feed that to an FTDI chip, to talk USB to PC.); usart1 is in turn wired to the GPU interface header. IIRC, usart1 is a much faster one as well.
The rev1 GPU pcb I figured could be useful for a general display pcb (or of course, as a general stm32 project board of course.) A single serial TX pin from some random chip, over to the gpu board heree and voila, we've got easy control VGA text and graphics modes. I may use it on my robot car for the LCD driver, for example, instead of the lame little 2 line LCD we all use.
Now, working with the GPU in serial/i2c makes it more like a opengl style driver; simple interface, scene graph on the gpu board, talk to it over the wire.
With the full RAM bus, you cna do bitmapped graphics in RAM and have the GPU just display it (sweet!), or route your protocol throgh RAM (queue up an array of instructions in RAM and have the GPU just iterate it; like sprite listings, etc.) This is very much more like old arcade boards and such. Worry about that for rev2, once I've nailed it down in the other prototype boards.
I really do like the STM32 pin routing options; usart1 RX and TX can be represented on GPIOB pins 6, 7 or whatever, and also on GPIOA on pins 10,11; just pick where you want the alt-functions to go, and thats that. Brilliant! Sure makes layout out the pin choices more interesting, and easier .. routing hard? Send the Alt-func over the other side instead!
--
Anyway, got an atmega644 with RX/TX hooked up to the GPU protocol line; GPU console is to FTDI to PC.
So now the atmega can drive the GPU board, and GPU board dumps all the requests to the PC for verification.
... now I just need to write a lame little protocol and the framebuffer manipulation stuff. Brute force ftw, time is tight, but goal is both a text mode for a dumb terminal, and some basic sprite handling to make a space invaders light, or something
Oh, need to tweak the VGA timings quite a bit; the values I'm using now were for the F2 instead of F4, at a slightly different clockrate, so it still (miraculously!) renders to VGA but blorps out a bit depending how the monitor is feeling at the time, since its not quite hitting the timings right. An hour or two on the scope adjusting things should get that sorted out.
.. fun
jeff
