The project scope and grown and shrunk a few times, but at its heart.. yes, an 8bit machine.
The trouble is the VGA output; you'll note that in modern machines the GPU is often far more beefy than the CPU; theres somethign to be said for that in the older machines as well.. though they usually did say NTSC/PAL which is pretty easy to spit out (and most TVs do not support it anymore), they still often had hardware assistance (like the VIC chip, say.) So even in 8bit land.. if you're making a new machine from scratch, the video subsystem is a challenge. I'm trying to do VGA or other vaguely modern display protocol .. I did NTSC originally, and its _Really annoying_ to do (I just had bad taste from doing it
, and I don't actually have any TVs that can do it beyuond an old C64 monitor. So I cut over to VGA, which is very simple to implement conceptually, but in actuallity.. you get challenged by speed. The VGA protocol demands you do various minimum speeds, and for most of the basic 8bit stuf fI originaly designed for.. its hard to keep up. You end up with a very limited VGA display .. I've got mono text modes pretty well, basic colour text modes, and basic colour displays (low res); I've done double buffered (at hardware level) with a pretty useful resolution .. but that was a 'lot' of chips on a board (ie: where you might have 1 cpu, 1 ram, one rom, one IO, .. and then 17 or 20 chips for a nice display? that seems overkill.)
So lately (aside from losing a month or two to sick kids/wife/hell
I've been trying to sort out other VGA generation techniques that are small chipcounts, but providing a better VGA output.. but 'without cheating'. "cheating" is the rule for this project which implies i) simple to understand, so that noobies (like me
can understand and hack it, and ii) not using modern do it all chips. Honestly, you can get a single-chip for $10 that runs linux, has many MB of RAM, spits out DVI, does it all. That defeats the purpose of learning it from scratch with an old school bent. I've got chips pulledfrom old Ataris and arcade pcbs I'm using for audio, that sort of thing
So my goal is something like a Vic-20 or Spectrum, that level of usefulness.. but lacking my own chiob fab ot make a VIC chip.
So the _current_ (it changes a lot
thought is using a 32bit chip as a display; I had fiddled with some funky chips like Propeller and some high speed low RAM 8bits.. (I've got an 8bit cpu that runs at 80MHz but has only like 150b of RAM
, but in the end.. going 32bit seems like a valid option .. greatly reduced chipcount, but not 'cheating' per se.
Originally I was sticking with atmel avr8 chips since I'm fond of them, they're cheap and readily available, and well documented and with good toolchain support but the 32bit avrs are goofy. PIC32 from Microchip look pretty good, but to get higher speed ones is goofy as well.
Someone above suggested STM's which I'd not looked into yet (I was looking into TI MSPs at the time actually), but the STM32 platform looks pretty hot.. I've gotten some of the ICs, and going to solder up some DIP adaptors so I can breadboard up some tests. (the ones I ordered are 64 pin TQFP surface mount chips.. really teeny.) Weird toolchain issues and stuff will make it 'fun', but implementing VGA in code shoudl be a piece of cake (I've done it a dozen times in avr8 land already.)
So, yeah, current plan is something along the lines of..
Z80 (classic 70s/80s era cpu)
a RAM
a ROM (eeprom really) to hold the 'firmware'/OS/game/whatever
a VGA chip (STM32, say)
a IO chip (we'll see.. STM32 is beefy enough it may be able to do it for us, but that might be 'cheating', but does save me a chip.. we'll see when I design the schematic up.) Plan is avr8 for IO, since I love them
But not sure I want z80 + avr + stm32.. 3 different chip families is a bit much for noobies to swallow.
The STM32 I have runs at 120MHz, which is pretty awesome. (the avr8's tend to max out at 16 or 20MHz, and VGA really wants 26MHz and up, and you want a lot more so you can actually code things up on it instead of just ticking up a counter.) So imagine if your VGA generator is 15 or 20MHz, every single opcode that goes by is like a finger-width of pixels on your VGA display gone; doesn't leave room for _anything_, and at best you're getting pretty crummy
(my big daddy double buffering one was clever and did pretty high res and such, but thats out of scope for this posting.) STM32 at 120MHz gives a lot of room, and also has some RAM for a framebuffer; theres faster ones but with nastier packages (like 100pin or more) so I just avoided that.
120MHz should make coding a bit easier (interrupt overhead cost shoudl be swallowable, or just using busy loops and timers); it shoudl allow enough room to generate a pretty nice higher res colour displsy and still leave a bit of performance left over for other stuff (such as perhaps sprites or scaling or effects, or doing IO work such as joystick and keyboard interface.) I've already coded up keyboard and joystick reading for avr8 mind you.
So.. its 8bit cpu and RAM and so on, with a 32bit GPU just to make VGA generation nicer; with enough ram for framebuffer, we can probably keep speed of display up, run the cpu fast and so on..with the avr8 doing VGA, those suckers tend to have 4K or 8K or the like of RAM, not enough even for a framebuffer except for realyl warped or limited ones. You really ideally want a framebuffer, so your cpu can run game logic, handling input etc, and let the video system run itself independantly.
Sorry for my usual digression and wandering around the point.. I don't sleep much.
jeff