GameToy hardware project
These pages describe a sort of blog-ish time log on my 'GameToy' hardware project (stalled indefinitely).
[<< First entry] [< Previous entry] [Next entry >] [Latest entry > >]
June 1st, 2006 - General
Started this log. This is bound to be a brain-dump, so bear with me.
So, what's GameToy? The project has two motivating factors:
-
I figured that, in order to get anywhere in my studies regarding electronics, I probably should build something.
-
Whilst changing jobs, I arranged myself some vacation.
So, I figured, why not build a portable game device? The project name is 'GameToy', although that's probably not final.
The heart of the device will be a Atmel AVR microcontroller, and the display is a graphic 128x64 monochrome LCD. After browsing through data sheets for some days, I ended up choosing ATmega32 chip for the controller, mainly since it's the biggest AVR you can get in a human-solderable form (40 pins), and Lumex LCM-H12864GSF LCD. The screen should, as far as I can tell from the data sheets, work with just one 5V power source, unlike many screens that require a negative -12V as well.
I've acquired 10 AVR chips and one screen from digikey (primarily since they had the screens in stock), and I should be receiving a STK500 AVR starter kit/programmer either late this week or early next.
So why the AVR? It's a 8-bit microcontroller with C language support and truckloads of features. It has an internal 1-8MHz RC oscillator as a clock source (although it can use up to 16MHz external clock as well). It has a rather efficient instruction set, and so on. As far as 8-bit controllers go, it's about as powerful as they come.
I could, of course, have chosen some 8-bit CPU instead, such as the trusty Z80 or its derivatives, but I think there's enough challenge in building this project using a microcontroller =) And anyway, I don't even know whether there's a more powerful 8-bit CPU than what AVR is.
So why limit myself to 8-bit? That's also a complexity issue. I'd like to learn and understand as much as possible of this project.
On the screen - I originally tried to find a 64x64 or smaller LCD screen, but, apart from cell phones, they don't seem to be available. I also considered using a character screen, but it would be too much of a "toy" in that case. 128x64, landscape, is the best I could find. It's a bit wide, but you can't have everything.
All of the graphic screens I browsed through had an embedded controller with exactly as much memory as is needed to display the graphics. Other features pretty much consist of "set y offset" and "clear" functions. Since I'd like to have a backbuffer, I'm expecting to use half of the 2k SRAM in the controller as back buffer. Nothing stops a game from updating the screen directly and using the RAM for something else, though..
The AVR can only execute code from inside the internal flash memory, so I'll have to figure some way to download new games into it on the fly. Luckily the chip can program itself, so it should be a matter of plugging in some TWI-controlled flash chip, detecting this at bootup and copying the contents to flash.
Which brings us to software architecture. I'm currently seeing four major subsystems that I need to write. All of these are part of the "boot rom", and would offer services to a game.
| Subsystem | Description |
|---|---|
| Laura | Audio; probably 4-channel software synth |
| Jack | Bootloader; boot menu (if needed), re-flashing and stuff |
| Tina | Graphics; sprites, text, scanlines |
| Pete | Hardware interfaces; memory transfer to LCD, etc |
Hardware-wise, the absolute minimum I'll have to implement is the screen, bunch of buttons (using microswitches most probably) and audio. Audio can be done using pulse width modulation generation with hardware low-pass filtering. On top of that, I'll have to see how many pins are available and how conveniently they are available, but possibilities include analog steering control (potentiometer to the ADC), motion sensing (ADC), vibration (another PWM), wired multiplayer (USART, SPI, TWI), and of course the swappable game cardridge idea expressed above.
Doing everything listed above would complicate the software side a lot, since talking to the LCD, for example, needs 8 bits for the data bus. Splitting that to two 4-bit nibbles is of course possible, but might still slow things down. Splitting the data further would make it much slower. As pin configurations go, buttons can happily live anywhere, since they are separate bits..
It's rather easy for this project to get way too complicated, so I'll try to keep it relatively simple. Stuff can always be added later.
As an example, what about the audio? I'm thinking of doing something relatively simple, like a few simple waveforms (sine, saw, square, noise), but this could easily blow up to be very complicated (like ring modulation, envelopes, filtering, 32 channels and stuff). At 8kHz, using 100% cpu power would mean that the audio generation takes 1000 cycles, which at 32 channels would mean about 30 cycles, which will either mean crazy optimization, higher cpu clock, separate mcu for audio, or "forget about it". I'm pretty sure it's the latter. =)
Pin requirements..
| Pins | Feature |
|---|---|
| 8 | LCD data (continuous) |
| 2 | LCD chip select |
| 2 | LCD controls (R/W, D/I) |
| 1 | LCD clock |
| 13 | LCD total |
| 1 | Audio (specific pin) |
| 6 | Buttons |
| 2 | TWI for flash cardridge (specific) |
| 4 | JTAG (specific) |
| 26 | **Probables subtotal |
| 3 | USART (specific) |
| 1 | Vibration (specific) |
| 1 | Analog steering (specific) |
| 1 | Motion sensor (specific) |
| 32 | Maxed out |
And here's how the pins in the AVR go, as this project is concerned:
| Pin | Feature | Pin | Feature |
|---|---|---|---|
| PA0 | ADC | PC0 | TWI I/O |
| PA1 | ADC | PC1 | TWI clock |
| PA2 | ADC | PC2 | JTAG clock |
| PA3 | ADC | PC3 | JTAG mode select |
| PA4 | ADC | PC4 | JTAG data out |
| PA5 | ADC | PC5 | JTAG data in |
| PA6 | ADC | PC6 | |
| PA7 | ADC | PC7 | |
| PB0 | USART clock | PD0 | USART out |
| PB1 | PD1 | USART in | |
| PB2 | PD2 | ||
| PB3 | DAC | PD3 | |
| PB4 | PD4 | ||
| PB5 | PD5 | ||
| PB6 | PD6 | ||
| PB7 | PD7 | DAC |
As you can see, the choises I have in order to have one 8-bit output port free would be to ditch ADC or to ditch USART and one of the DACs - or to slow things down by using 4 bits from PA and 4 bits from PB.
While waiting for the STK500 to arrive, I've started doing some software work.
I spent last night writing a .mid file parser, so I could have material for the audio synth. We'll see how well that goes, especially since I don't know just about anything about audio..
Comments are appreciated.