Microtouch: 8-bit Open Source Media Device 115
First time accepted submitter misterbarnacles writes "The Microtouch is a mobile media device that aims to become an open-source alternative to the iPod Touch."
Deeper investigation reveals that the Microtouch is a nifty little device. Powered by an 8-bit microcontroller with only 2.5K of RAM there is an example ebook reader application. A primitive application framework (for some definition of the phrase) is available as Free Software, and for the hardware hackers the EagleCAD PCB files are published under a CC attribution-share-alike license.
Re:For a low-power 8-bit MC with 2.5k RAM... (Score:4, Informative)
I think the touchscreen is single-touch only, but pressure sensitive (from the diagnostics screenshot). The article does say it has an accelerometer.
For DIY purposes, it would be cool if it had any other I/O besides USB -- e.g. ADC or just serial-- which isn't clear to me.
Re:Cool concept (Score:4, Informative)
1-bit DAC defined (Score:5, Informative)
Re:8 bit audio? (Score:5, Informative)
Way back in the ancient days of yore (when 2600 was a videogame system and not a magazine dedicated to hacking), there was something called a "Sprite", and its purpose was to allow you to control individual pixels of a "large" (or what passed for it in 1977) and sparse display with lots of potential pixels, and very little ram. Back then, you literally had the following graphic elements at your disposal:
* A 20 pixel "playfield" that could be doubled, mirrored, and/or stretched. The 20-pixel chunk could be stretched, duplicated, or mirrored. You could reload its definition registers between scanlines and reuse it to display different things on different rows.
* A pair of 8-pixel sprites that could also be doubled, mirrored, and/or stretched. 8 pixels wide, one pixel high. You'd set it to some horizontal offset from the left, enable it manually when the raster reached a specific scanline, then leave it on until you got to the end of the last scanline where it should be displayed. If you wanted it to look different on the next scanline, you reloaded its 8-bit register with a new value.
* Three single-pixel sprites -- two missiles, one ball. They basically consumed ~two bytes apiece... one byte for horizontal offset, and one byte for control & attributes (width, motion-delay, etc).
Just to give you an idea how crude it was, there's a reason why the score digits in Circus Atari were uneven... it used player 0 to draw digits 1 and 2, and player 1 to draw digits 3 and 4. It drew digits 1 and 3 on the odd scanlines, then reloaded the register and offset to draw digits 2 and 4 on the even scanlines. When some game I can't remember came out that had a 6-digit scoreboard, it was considered groundbreaking because it went a step further, and reused the same sprite twice on the same scanline. It used player 1 to draw digits 1, 2, 5, and 6, and player 2 to draw digits 3 and 4. It defined the sprites for digits 1 & 3 or 2 & 4, then paused a few clocks and reloaded the byte for player 1 with the data for digits 5 or 6.
The crazy thing about the 2600 is that few of its limits were truly hard. I think someone a year or two ago actually hacked a homebrew 2600 cartridge using an ARM9 microcontroller that tricked it into doing 160x384 interlaced graphics (by tickling the vertical retrace clock register at exactly the right moment to trick the TV into drawing the next field as an even interlaced field instead of just redrawing odd fields over and over again) and did insane things like simulate cartridge rom so it could rewrite itself on the fly in ways that would have been physically impossible on any cartridge of the era. From what I recall, it actually sparked a debate among the 2600 homebrew community over how far you could legitimately go stuffing modern microcontrollers into faux 2600 cartridges to act as coprocessors before you defeated the whole point of saying it was a "2600 game". I think the consensus was that it was OK to do things like the later Activision games did (incorporating shift registers and stuff into cartridges to auto-update the bank of ram seen by the 2600), but pre-rendering 26 megabytes of video kernel code into 6502 assembly to reload the registers in slightly different ways, then spooling it from a microSD card was just being kind of silly. Still, it's kind of amazing what you can pull off with the crude, primitive chips in a 2600 when you're able to offload everything from program logic to kernel code onto modern chips, and just drive the 2600's bare metal "from the outside" (so to speak).
It's sobering, in a way, when you consider that much of what modern GPU chips do is software controlled as well, and think about just how far a modern GPU could probably be pushed if Moore's Law didn't automatically mean there'd be a version that's 500MHz faster on the shelves next year. If Mars were colonized today, had a videogame industry, and a new videocard on Mars cost $15,000 ($89.95 plus $14,909.05 shipping, with roughly 14-18 month delivery time), we'd probably see similar tricks being hacked out of 10 year old videocards by Martian programmers today.