Slashdot Mirror
Microtouch: 8-bit Open Source Media Device
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.
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.
Nobody said anything about 8-bit audio, and of course you can decode MP3's on an 8-bit turing-complete machine.
Furthermore, since we are going to be talking about irrelevant crap because of the Hatta's in this world, most DAC's in digital audio players are only 1-bit.
Stop posting.
"His name was James Damore."
You apparently didn't comprehend what you posted. The 24-bit dsp is what decodes the mp3s not the 8-bit cpu.
Not with this thing, at least... from TFA:
OK, it can't play MP3s, but it does have a 320x240 TFT color display [...]
There may be many cool possible DIY apps, but I wonder how this is a "media device", yet alone an iPod competitor.
But never an infrared light! Something like this would be perfect for a HTPC remote.
open-source alternative to the iPod Touch
... 8-bit microcontroller with only 2.5K of RAM ...
As someone who has programmed microcontrollers and 8-bit CPUs back in the day I think this is a pretty cool device.
But iPod touch alternative? Seriously?
8-bit microcontroller vs 32-bit embedded processor with integrated FPU
2.5K RAM vs 512M RAM
28K FLASH vs 8G FLASH
hint: add xbee to its serial port and have another arduino (etc) on the other side with an xbee on ITS serial port.
printf and scanf (well, sort of) after that. /end hint
--
"It is now safe to switch off your computer."
this is a control element. it does not sit on the analog audio plane. it CONTROLS things that might be analog but this is not any dsp engine. its a CONTROLLER, mate (duh!).
.
--
"It is now safe to switch off your computer."
TFA has a link to buy preassembled for $69, but it's out of stock.
A "1-bit DAC" is a time-proportioning PWM DAC, as seen on a Game Boy Advance or Nintendo DS, or a delta-sigma DAC, as seen on plenty of portable CD players.
Never on an 8bit microcontroller, no. On an 8bit graphics processor, yes (the memory was on the processor, not on the microcontroller).
However, the vga mode 13h[1] was not necessarily frame-buffer backed[2]; I used a pointer to a framebuffer at memory 0xb4000000 (I think it was this particular address, not too sure) with the full knowledge that that memory was not on the microcontroller.
However, to keep some perspective, I was referring to the PIC's, the atmels and similar microcontrollers - none of them ever had a framebuffer-based video; fb-based video (if any) was always provided by an external graphics processor.
[1] Either "0x13" or "13h", not both (redundant, see?)
[2] Perhaps I'm remembering wrong and mode 13h was not a slow-as-molasses interrupt interface to the external graphics processor. In my memory, it was a (you guessed it) slow-as-molasses interrupt interface to the external graphics processor. The Borland BGI library used the SAMIITTEGP.
I'm a minority race. Save your vitriol for white people.
A pure text mode display could not show graphics.
The Nintendo Entertainment System has a pure text mode display, albeit with sprites on top. Games show graphics by redefining the font to include pieces of graphics. In fact, some games (such as Color a Dinosaur, Elite, Hatris, Qix, and Videomation) operate by rewriting the font in real time, treating the font sheet as if it were a bitmap with its pixels in a funny order. But I'll grant that the graphics on this device don't look anything like text mode, so the VRAM must not be part of the 2.5 KiB, just as the NES VRAM isn't part of its 2 KiB.
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.
I'm not 100% certain, but I'm pretty sure that single-bit SPI reads from microSD are too slow for realtime 16-bit PWM stereo. In other words, even if you buffered a few bytes in the chip's SRAM, the time it would take to physically shift 32 bits from the card (for the next two 16-bit samples) would exceed 1/44,100th of a second. In fact, if you were trying to bitbang 16-bit 44.1KHz stereo audio, I'm not sure you'd even have enough time to iterate through the 32 bits and decide whether or not the output should be high or low at a sufficiently high rate to avoid audible artifacts.
There are some things an 8-bit CPU just wasn't meant to do, and high-quality digital audio is one of them. It makes more sense to just wire a dedicated .mp3 codec chip up to the flash, and use the 8-bit CPU as the controller (in fact, that's basically what most dedicated MP3 players used to DO circa 2001). You use the MCU to do things like sense button presses, and communicate with the mp3 player chip itself (and possibly the amplifier chip) via i2c or SPI.
Nowadays, the moment of truth for jumping to ARM (instead of adding ASICs to 8-bit MCUs) tends to arrive with network connectivity. You can pair an 8-bit MCU with a Wiznet chip, but at that point the 8-bit MCU starts to feel kind of vestigial, and it usually ends up being cheaper to just step up to an ARM9 paired with a dumb ethernet chip instead of pairing a relatively expensive Wiznet chip (that does the heavy lifting for tcp/ip) with a mid-level 8-bit MCU.