email sol follow sol rss feed of the blog wishlist Sol::Stuff

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:

1. I figured that, in order to get anywhere in my studies regarding electronics, I probably should build something.

2. 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.

SubsystemDescription
LauraAudio; probably 4-channel software synth
JackBootloader; boot menu (if needed), re-flashing and stuff
TinaGraphics; sprites, text, scanlines
PeteHardware 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..

PinsFeature
8LCD data (continuous)
2LCD chip select
2LCD controls (R/W, D/I)
1LCD clock
13LCD total
1Audio (specific pin)
6Buttons
2TWI for flash cardridge (specific)
4JTAG (specific)
26Probables subtotal
3USART (specific)
1Vibration (specific)
1Analog steering (specific)
1Motion sensor (specific)
32Maxed out

And here's how the pins in the AVR go, as this project is concerned:

PinFeaturePinFeature
PA0ADC PC0TWI I/O
PA1ADC PC1TWI clock
PA2ADC PC2JTAG clock
PA3ADC PC3JTAG mode select
PA4ADC PC4JTAG data out
PA5ADC PC5JTAG data in
PA6ADC PC6 
PA7ADC PC7 
PB0USART clock PD0USART out
PB1  PD1USART in
PB2  PD2 
PB3DAC PD3 
PB4  PD4 
PB5  PD5 
PB6  PD6 
PB7  PD7DAC

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.

Site design & Copyright © 2021 Jari Komppa
Possibly modified around: May 02 2010