ATmega168 Tetris
Sunday, 22nd November 2009
The tvText library I discussed last entry allows you to display text on a PAL TV in black and white using a 20MHz ATmega168 and a pair of resistors. If this doesn't sound terribly exciting, it's probably because it isn't. However, if you bear some limitations in mind and change the font, you can use this text output as a more general tile-mapping system and use it for games that employ simple graphics.
The new circuit, featuring five sloppily-wired input buttons.
I added five buttons to the test circuit — up, down, left, right and fire — to act as game input. This circuit is shown in the photograph above. I also added support for 8×8 characters alongside the existing 6×8 characters to the library, set as a compile-time option. This drops the number of characters per line from 32 to 24, but having square tiles makes producing graphics much easier. The reduction in size of the text buffer also frees up more of the precious 1KB of SRAM for the game!
Even though it was always recommended as an excellent game for beginners to write, I don't believe I've ever written a Tetris clone before. Its simple block graphics makes it an ideal candidate for this system, and it always helps to work on a game that's fun to play. Armed with a Game Boy and a stopwatch I attempted to recreate a moderately faithful version of what is probably the most popular rendition of the game.
I think the result plays pretty well, but don't take my word for it — if you have an ATmega168 lying around, you can download the source and binaries here.
USB joypads and text on your TV courtesy of an ATmega168
Saturday, 14th November 2009
Nearly a month since my last update - my, how time flies when you're having fun (or a heavy workload).
I ended up building myself a cheap and cheerful SI Prog programmer for AVR development. After installing the development tools, scanning through the documentation and writing the microcontroller equivalent of Hello, World (flashing an LED on and off) I needed to find a suitable project. The first one was getting to grips with V-USB, a software USB implementation for AVRs. All you need for this are a couple of I/O pins, a few configuration file changes to set your USB device's vendor ID, product ID and device class, and a few lines of C code to actually implement your device. I attached six tactile switches to an ATmega168 and made the most uncomfortable USB joypad I've ever used. I managed two levels of Sonic the Hedgehog before my thumbs admitted defeat, but it's nice to know that building USB devices is very easy with an AVR.
#include <avr/io.h> #include <avr/interrupt.h> #include <avr/wdt.h> #include <util/delay.h> #include <avr/sleep.h> #include "usbdrv.h" /* Joystick port bits */ #define JOY_1 (1<<0) #define JOY_2 (1<<1) #define JOY_UP (1<<2) #define JOY_DOWN (1<<3) #define JOY_LEFT (1<<4) #define JOY_RIGHT (1<<5) /* USB HID report descriptor */ PROGMEM char usbHidReportDescriptor[USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH] = { 0x05, 0x01, // USAGE_PAGE (Generic Desktop) 0x09, 0x05, // USAGE (Game Pad) 0xa1, 0x01, // COLLECTION (Application) 0x09, 0x01, // USAGE (Pointer) 0xa1, 0x00, // COLLECTION (Physical) 0x09, 0x30, // USAGE (X) 0x09, 0x31, // USAGE (Y) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255) 0x75, 0x08, // REPORT_SIZE (8) 0x95, 0x02, // REPORT_COUNT (2) 0x81, 0x02, // INPUT (Data,Var,Abs) 0xc0, // END_COLLECTION 0x05, 0x09, // USAGE_PAGE (Button) 0x19, 0x01, // USAGE_MINIMUM (Button 1) 0x29, 0x02, // USAGE_MAXIMUM (Button 2) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x25, 0x01, // LOGICAL_MAXIMUM (1) 0x75, 0x01, // REPORT_SIZE (1) 0x95, 0x08, // REPORT_COUNT (8) 0x81, 0x02, // INPUT (Data,Var,Abs) 0xc0 // END_COLLECTION }; static uchar reportBuffer[3]; /* Buffer for HID reports */ static uchar idleRate; /* 4 ms units */ uchar usbFunctionSetup(uchar data[8]) { usbRequest_t *rq = (void*)data; usbMsgPtr = reportBuffer; if ((rq->bmRequestType & USBRQ_TYPE_MASK) == USBRQ_TYPE_CLASS) { switch (rq->bRequest) { case USBRQ_HID_GET_REPORT: return sizeof(reportBuffer); case USBRQ_HID_GET_IDLE: usbMsgPtr = &idleRate; return 1; case USBRQ_HID_SET_IDLE: idleRate = rq->wValue.bytes[1]; break; } } return 0; } ISR(TIMER0_OVF_vect) { /* Fetch input */ uchar input = ~PINC; /* X-axis */ switch (input & (JOY_LEFT | JOY_RIGHT)) { case JOY_LEFT: reportBuffer[0] = 0; break; case JOY_RIGHT: reportBuffer[0] = 255; break; default: reportBuffer[0] = 128; break; } /* Y-axis */ switch (input & (JOY_UP | JOY_DOWN)) { case JOY_UP: reportBuffer[1] = 0; break; case JOY_DOWN: reportBuffer[1] = 255; break; default: reportBuffer[1] = 128; break; } /* Buttons */ reportBuffer[2] = input & (JOY_1 | JOY_2); usbPoll(); usbSetInterrupt(reportBuffer, sizeof(reportBuffer)); }; int main(void) { usbInit(); /* Initialise USB. */ PORTC = 0b00111111; /* Pull high PORTC0..PORTC5 */ TCCR0B = 0b00000101; /* CS2..CS0 = 101: prescaler = /1024 */ TIMSK0 |= (1 << TOIE0); /* Enable timer 0 overflow interrupt. */ sei(); /* Enable global interrupts. */ for (;;) { /* Infinite loop */ } }
I should only really call usbSetInterrupt when a button or axis has changed, rather than every loop, but the above code works as is.
One thing that always bothers me when it comes to electronic projects is the difficulty of providing text output. LCDs are generally quite expensive and low resolution, and typically require a great many pins to drive them. Video display processor chips are difficult to find, and appear to require quite complex external circuitry (the best thing I've found thus far are some TMS9918 chips being sold as spares for MSX computers). Having briefly experimented with generating PAL video signals in software before, I thought I'd try the two-resistor approach to getting PAL video output on an ATmega168.
I had a hunt around and found AVGA, which is close to what I wanted - video output from an AVR using cheap hardware. However, it outputs RGB directly, and I don't own a TV or RGB converter so couldn't use that - all I have is a VGA box (accepting composite or S-Video input) and a TV capture card (also only accepting composite or S-Video input). AVGA does work with VGA monitors, but I'd like to keep the hardware interface simple - just two resistors, ideally.
In the end, I ended up writing my own library. It currently has the following specifications:
- 32×16 characters: 512 bytes (half of the total SRAM on the ATmega168) are used to store the text buffer.
- Full 256 characters at a resolution of 6×8 pixels each.
- Total screen resolution: 192×128.
The library is interrupt-driven, and uses the sixteen-bit TIMER1 to schedule events. This means that the AVR is only busy generating video signals when it absolutely has to, leaving some CPU time to the user program. When outputting at full quality, the AVR appears to be capable of running user code at 3.3 MIPS, but by skipping alternate scanlines (each scanline is scanned twice anyway, so this mainly just makes the display appear darker) the AVR appears to be running user code at 9.9 MIPS. (I say "appears" as my calculation has been to execute a busy loop that would normally take one second on the AVR running at its normal 20 MIPS then seeing how long it takes with the video output driver enabled).
The above video demonstrates some of the currently rather limited features of the library. The text console handles a subset of the BBC Micro VDU commands - I'd like to support as many of its features as possible. The code behind the BASIC-like part of the demo is simply written like this:
#include "tvtext/tvtext.h" void type_string_P(const char* s) { char c; while ((c = pgm_read_byte(s++))) { tvtext_putc(c); delay_ms(100); } } int main(void) { tvtext_init(); tvtext_clear(); tvtext_puts_P(PSTR("AVR Computer 1K\r\n\nATmega 168\r\n\nBASIC\r\n\n>")); delay_ms(2000); type_string_P(PSTR("10 PRINT \"AVR Rules! \";\r\n")); tvtext_putc('>'); delay_ms(500); type_string_P(PSTR("20 GOTO 10\r\n")); tvtext_putc('>'); delay_ms(500); type_string_P(PSTR("RUN")); delay_ms(1000); tvtext_puts_P(PSTR("\r\n")); for (int i = 0; i <= 200; ++i) { tvtext_puts_P(PSTR("AVR Rules! ")); delay_ms(20); } tvtext_puts_P(PSTR("\r\nEscape at line 10\r\n>")); delay_ms(1000); type_string_P(PSTR("CHAIN \"DEMO\"")); delay_ms(1000); // ... }
All of the high-level console code - text output, viewport scrolling, cursor positioning &c - has been written in C, so should be relatively easy to be customised. The output driver itself has been written in assembly as timing is critically important.
With a few more features and a bit of tidying up I hope that people would find this a useful library. I'd certainly like to get a blinking cursor working within the driver, and if I add support for a reduced 128-character version I could save quite a bit of ROM space and add support for "coloured" - inverted, that is - text. NTSC support would also be quite useful.
64-bit IThumbnailProvider, BBC BASIC matrices and clocks
Friday, 16th October 2009
Work commitments have left me with little time to pursue my own projects of late, hence the lack of updates.
A chap named Jeremy contacted me with problems relating to the IThumbnailProvider code I'd posted here before. We narrowed it down to a 64-bit issue, demonstrated by the fact that the thumbnails appeared in the file open dialog of a 32-bit application, but not in Explorer. Not having a 64-bit version of Windows to tinker with, I was unable to help, but he found the solution was to register the assembly using the 64-bit version of regasm. You can read more about his experiences on his blog.
I had made a mistake in the BBC BASIC (Z80) for TI-83+ documentation, describing the old coordinate system in the graphics documentation rather than the current one (which is more closely aligned to other versions of BBC BASIC). I have uploaded a new version of the documentation to ticalc.org. This build also includes some basic matrix operations via the MAT statement. This statement is rather incomplete, but I've run out of ROM space (not to mention time) to implement it fully. Still, the bits that are there are quite useful, and a half-arsed implementation is better than no implementation... right?
On a whim, I purchased a 32×8 LED display on eBay which I've (very) slowly been turning into a remote-controlled clock. A Sony-compatible remote control is used to type in the time, after which you can cycle through different styles with the channel up/down buttons and change the brightness with the volume and mute buttons. I'm using a 4MHz PIC16F84 to drive the display, with a DS1307 responsible for time-keeping and a 32KB 24LC256 to store the font data and text strings.
As well as dates and times, I thought a thermometer might be a useful addition so I put together an order for a DS18B20. It's silly to just order one thing, so I bulked up the order with one of the snazzy new PICAXE-20X2 chips (yes, they run a BASIC interpreter but the new 64MHz clock speed is certainly impressive). I find PICAXE microcontrollers invaluable for prototyping, being so very easy to use! 
In an attempt to broaden my horizons, I also purchased two AVRs, as I have zero experience with these popular chips. I went for the two ends of the scale as offered by the supplier - an ATmega168 and an ATtiny13. Having lost a battle with PayPal's cart (it kept forgetting old items as I added new ones) I neglected to purchase a D-sub hood so I'll be waiting until I can go and buy one before I start assembling a programmer. I was intending on going for the simple SI Prog, but if anyone has any suggestions for variations I'd be interested in hearing them!
Cogwheel 1.0.3.0 beta 3
Monday, 24th August 2009
I managed to break save states in the last build of Cogwheel (attempting to load a save state would fail, not being able to set a property). I've marked the offending read-only property with [StateNotSaved] and made the loader slightly more robust in Cogwheel 1.0.3.0 beta 3. It's beta 3, not 2, because I uploaded 2 and then noticed another issue - you couldn't change the controller mappings! This is something that must have been broken for ages, but either nobody noticed or they just didn't care to report it. Oh well, that's been fixed now. For some reason Google don't let you re-upload files, so beta 3 it has to be.
Another addition is this build is preliminary support for persistent cartridge RAM. Some games, such as Phantasy Star (pictured above) let you save your progress in the game onto battery-backed RAM built into the cartridge. If you come back to the game later you should now be able to continue your progress without needing to manually save the entire emulator state.
I've had reports of rather bizarre crashes bringing one poor user's machine to its knees. I'm at a loss to establish why; I've tried the emulator on four machines (two Vista, two XP) and although one of the machines displays a white screen instead of the emulator output (no pixel shader 2.0 support on its Radeon 9000) the software trundles along just fine otherwise (I can at least hear the game music!) The one notable difference between my machines and his machine is that he's using a 64-bit version of Windows, and all of the ones I have access to run 32-bit Windows. To see if this is the issue, I've changed the configuration to x86 (I've encountered strange bugs with .NET code using unmanaged 32-bit code on 64-bit Windows) to see if this will remedy issues, but if anyone has any bright ideas I'd be interested to hear them.
Cogwheel 1.0.3.0 beta 1
Thursday, 20th August 2009
I've released a beta version of Cogwheel 1.0.3.0 in the hope of getting some feedback. My main concern is with the new 3D glasses code, so I'd be very grateful if you could install the emulator and run this ROM in it. The ROM simply alternates between showing a red screen for the left eye and a cyan one for the right eye (the emulator defaults to only showing the left eye, so you'll just see red for the moment). If you select a different 3D glasses mode (Options, 3D glasses, Row interleaved) you should end up with something like this:
If you drag the around the desktop the lines should appear fixed on the spot (as long as you drag it slowly enough to allow it to repaint), and if you resize it the entire form should always be covered in lines one pixel apart. The same should apply to the column interleaved and chequerboard interleaved modes.
I've also added VGM recording and VGM playback. VGM playback is handled by bundling Maxim's SMS VGM player.
The console's region (Japanese or Export) and video standard (NTSC or PAL) are now user-configurable via the Emulation menu. The YM2413 (FM sound) emulation has been converted to straight C# (it used to be a P/Invoked native DLL). Drag-and-drop support has been added to aid in loading ROMs, save-states and VGMs.
There have been a number of internal optimisations, fixes and tweaks (such as per-scanline backdrop colours), but nothing too major (compatibility is roughly the same as it was). If you do find any bugs, please report them!
