I'm sorry for everyone who's following this thread. Slow doesn't even begin to describe it. However, there is so many parts involved that I hope you understand.
Here's a small update about the LCD mini-marquee. Since the last update I've decided to go with an SD card instead of two 8-pin DIP flash memory ICs.
Apart from the computer, the LCD mini-marquee display will be the most complex part of this cabinet.
List of parts required for the marquee display controller:
- Microcontroller: Atmel ATtiny861 (8-bit, 20MHz, 8192 bytes of code space)
- Small color display: ET-LCD6610 (132x132 pixels, 4096 colors)
- SD Card socket: SparkFun (BOB-00204)
- Serial port level converter: MAX232 (don't have one, will need to order it)
I'm also using the AVR Programming Adapter from SparkFun (
BOB-08508) but this will be part of the custom PCB I'll be making.
Why so many parts? Well, here is a list of all the things this module must do:
- Communicate with the computer to know which marquee to display. I will have to add something to either the front-end or to MAME. Ex: I select Black Tiger. The front-end needs to send "blktiger" via the serial port to the marquee display microcontroller.
- Convert voltage levels between the computer and the microcontroller (MAX232)
- Access the graphic files on the SD card (SD Card socket + software I'm writing for the ATtiny861)
- Output the graphic data to the LCD display (again, my own software that's going to reside in the ATtiny861)
At last count the ATtiny861 had enough I/O pins to do all of this.
To simplify the graphics decoding and SD card reading parts of the project I will only support very specific, erm, specifications:
- I didn't want to mess around with saving raw data files and I wanted something supported under Mac OS X's Preview program. So my choice ended up with uncompressed TIFF files. I don't need to write specifications-compliant TIFF decoding routines since I know where the graphic data is located inside my files. Another reason to use TIFF is because I didn't want to use Microsoft's BMP format.
- FAT16: I don't need to support FAT32 and long filenames. MAME ROM filenames are "8.3" and FAT16 allows up to 2GiB partitions. The marquees are 132x132 pixels in 24-bit color (RGB), so 132x132x3 equals 52272 bytes. The files as written by Preview end up at 52494 bytes because of the TIFF header and other various data. And 52494 bytes multiplied by 99 games equals ~4.96 MiB (5196906 bytes) so the 2GiB maximum of FAT16 is more than enough. An old 32MB SD Card would still have been overkill but unfortunately the only spare SD card I have for this project is 1GB.
And since I know you all like drawings, pictures and photos when reading about an update, here it is (and yes, only the AVR Programming Adapter is wired up so far, the spaghetti-like wire mess will come soon enough):
Going clockwise, on the outside, starting from the LCD:
- LCD, of course
- SD card socket
- AVR Programming Adapter
- Atmel ATtiny861 (20-pins IC in the middle)
I'll probably start with outputting pixels on the display by embedding a tiny graphic directly inside the code of a test program.
The "MVS Neo-Geo" mini-marquee with a white background can be cropped as two graphics on an all-white background. Using the 108x132 graphic I've already done, it seems it would require 80x28 pixels for the top "MVS Multi-Video System" part and 65x64 pixels for the yellow/blue "Neo-Geo" part. Reducing to 256 colors doesn't do much impact to the quality, so (80x28)+(65x64) = 6400 bytes, leaving only 1792 bytes for the test program itself. If it fits, there won't be much room left.
Worst case scenario, I'll only use the yellow/blue "Neo-Geo" part of the graphic for the test. Stay tuned.