skeezix
Internal Development
Now, we'll have different modes, but maybe should default to a 256x240 or 256x200 mode. 256x240 shaves off a little bit of memory, and the main part would be that 'X' is now one byte instead of two.
I'm leaning towards now, hooking up both serial and i2c from intermediary chip to GPU chip, so we can use either .. whatever someone gets fasted or prefers, or whatever. But theres a limit to how much you can shove through there, so it may be beneficial to keep bandwidth down; if you're moving 100 sprites every frame say (which would be a lot), and you have to send a sprite move command (1 byte), and then sprite # (1 byte), and then X and Y .. be nice if they also were 1byte each:
Packet:
1 Sprite Move
1 Sprite ID
1 Sprite X (instead of 2byte)
1 Sprite Y
That becomes 20% less.
100 * 4 * 60fps = 24KB per second.
I'm sort of assuming that theres a text mode, and graphics modes; graphics modes for action games would be say pacman, or space invaders; pacman doesn't have much change per frame.. 4 ghosts and pac, and 4 blinking dots, and any score change; not much to send over. Space Inmvaders is what, 4 rows of 15 guys, so adding up to a few sprites. zikzak sprites aren't limited to mono or anything, could be 64x64 full colour sprites say, possibly with an alpha channel who knows.
The 'hard' one is (and always was) scrolling backgrounds; scrolling vertically is not too hard and should be doable okay, but horizontal scrolling is always trickier.
I may update to the LQFP100 chip, the F429, which gets a bit more RAM, a bit faster (180MHz instead of 168), and includes DMA2D (2d blitter) and such, which people may find useful who knows. But soldering QFP100 is a bit of a pita if you've got just an iron and no practice with SMD, so may be too much for kit-folks.
...
For intermediary, an STM8 or AVR8 would be slick; STM8 to avoid multiple programmers, and AVR8 since I really like working with them; both 8bit guys have very low RAM though, and limited speed (so trouble with higher serial rates; I think I maxed out at 38400bps on avr8 20MHz on zikburner (or maybe 16MHz?) .. either way, it seems a reasonable max. The STM32 can do 512kbps, but unless we're using another stm32 we're not getting that. 38400bps is about 3KB/second, which is a pretty harsh limit.
Given I'd like to also support single programmer for other-than-z80 components, it is tempting to use an stm32 as intermediary; an avr8 or stm8, the 'higher end' ones with faster speeds and some RAM (like, 6K, that sort), are about $6ea say. An STM32 low end model would be like $8 or something, and the high end liek the GPU uses is about $13-$16ea roughly. On the one hand, adding another $5 to the cost of a kit few people will likely see isn't too bad, but on the other.. its dangerous to idly toss in upgrades all over. Software side of me says 'more more! fun!', but hardware is better to be conservative
Z80 -> STM32 IO -> STM32 GPU .. crazy
fun fun..
jeff
I'm leaning towards now, hooking up both serial and i2c from intermediary chip to GPU chip, so we can use either .. whatever someone gets fasted or prefers, or whatever. But theres a limit to how much you can shove through there, so it may be beneficial to keep bandwidth down; if you're moving 100 sprites every frame say (which would be a lot), and you have to send a sprite move command (1 byte), and then sprite # (1 byte), and then X and Y .. be nice if they also were 1byte each:
Packet:
1 Sprite Move
1 Sprite ID
1 Sprite X (instead of 2byte)
1 Sprite Y
That becomes 20% less.
100 * 4 * 60fps = 24KB per second.
I'm sort of assuming that theres a text mode, and graphics modes; graphics modes for action games would be say pacman, or space invaders; pacman doesn't have much change per frame.. 4 ghosts and pac, and 4 blinking dots, and any score change; not much to send over. Space Inmvaders is what, 4 rows of 15 guys, so adding up to a few sprites. zikzak sprites aren't limited to mono or anything, could be 64x64 full colour sprites say, possibly with an alpha channel who knows.
The 'hard' one is (and always was) scrolling backgrounds; scrolling vertically is not too hard and should be doable okay, but horizontal scrolling is always trickier.
I may update to the LQFP100 chip, the F429, which gets a bit more RAM, a bit faster (180MHz instead of 168), and includes DMA2D (2d blitter) and such, which people may find useful who knows. But soldering QFP100 is a bit of a pita if you've got just an iron and no practice with SMD, so may be too much for kit-folks.
...
For intermediary, an STM8 or AVR8 would be slick; STM8 to avoid multiple programmers, and AVR8 since I really like working with them; both 8bit guys have very low RAM though, and limited speed (so trouble with higher serial rates; I think I maxed out at 38400bps on avr8 20MHz on zikburner (or maybe 16MHz?) .. either way, it seems a reasonable max. The STM32 can do 512kbps, but unless we're using another stm32 we're not getting that. 38400bps is about 3KB/second, which is a pretty harsh limit.
Given I'd like to also support single programmer for other-than-z80 components, it is tempting to use an stm32 as intermediary; an avr8 or stm8, the 'higher end' ones with faster speeds and some RAM (like, 6K, that sort), are about $6ea say. An STM32 low end model would be like $8 or something, and the high end liek the GPU uses is about $13-$16ea roughly. On the one hand, adding another $5 to the cost of a kit few people will likely see isn't too bad, but on the other.. its dangerous to idly toss in upgrades all over. Software side of me says 'more more! fun!', but hardware is better to be conservative
Z80 -> STM32 IO -> STM32 GPU .. crazy
fun fun..
jeff