On Fri, 8 Sep 2006 17:44:08 +0200, Dave Long wrote: > I just ran across the Korean GP32 console, which, although still 10-20x > Kragen's target price, is at least a linux-based open platform intended > for third-party development. > > There seems to have been a corporate fork, and the original handhelds > are no longer in production, but the GP2X is available now, at about > USD 170-180: > > http://wiki.gp2x.org/wiki/Main_Page
Nifty! I hadn't been following the GP2X project in a while. It is a really neat idea. Open is good, but Linux is bad --- it's a symptom of the reason it costs so much, which is that it's really a shrunk-down Unix workstation. > Of interest to the CEDP, it uses a pair of ARMs, with one core as a > problem state CPU, and the other to run the graphics. (QVGA built-in > display, S-Video out). It uses SD cards (USD 24 at the low end?) for > storage. SD cards, and also bare NAND flash chips, do seem to be $24 at the low end; NOR costs more per bit but starts at a lower price, under $1. I think that in general non-shared-memory multi-CPU computing is going to be really important, for the following reasons: - Doubling the number of computers means you can run each one at half the speed (thus half the voltage and 1/8 the power, down to some minimal limit) at the same number of MIPS. This is less true for multicore SMP-on-a-chip designs. - IPC between processes on different computers can take less than a nanosecond, so you can divide your system into processes without paying as big a context-switching cost as you would on a uniprocessor, or even an SMP. - It's a lot easier to build a cluster in which one node is safe from malicious code running on another node than it is to build an operating system that is safe from malicious code running in another process, and you don't need MMUs to do it. Traditional MMUs take more silicon and consume more power than entire CPUs these days. Being able to run malicious machine code safely means that you don't pay JavaScript's 2-3 orders of magnitude performance cost in order to run untrusted code safely. In 1999 or 2000, I think I thought mainstream CPUs in the future would look more like the Tera MTA, in that they would adopt multithreading to tolerate greater memory latency. (I haven't been able to find evidence that I thought that, though.) Today, I think I was right: Intel's new CPUs have "hyperthreading", Alphas had "symmetric multithreading" before they died, and the SPARC has something similar as well. Now I think mainstream CPUs in the future will look more like Beowulfs. > Although TVs are probably at or below the metric of "suitable for > viewing web content on" (especially if driven by cheap microcontrollers > and minimal DACs) at this point they still seem like the best chance of > finding a cheap and cheerful medium-bandwidth display. Yeah, I agree. I think WebTV showed that they work pretty well if they're driven by more sophisticated electronics. Did the Apple ][ ever get readable 80-column text on them? (Thanks to HTML, that matters less than it used to, but it's a good kind of baseline for screen size.) > The ever-prolific Fabrice BELLARD has a small project which produces > mono PAL and SECAM still images as well as Digital TV-out: > > "A Low Cost Analog and Digital TV (DVB-T) Modulator" > http://fabrice.bellard.free.fr/dvbt/ > > with the caveat that his "low cost" assumes one already has a VGA card > (he uses a 76.5 Mhz pixel clock for the DVB-T, and a harmonic for VHF) Yeah, I thought that was really nifty. My del.icio.us entry for that page: url: http://fabrice.bellard.free.fr/dvbt/ description: A Low Cost Analog and Digital TV (DVB-T) Modulator, from Fabrice Bellard extended: How to get your ATI Radeon 9200SE video card to emit VHF digital video in DVB-T at e.g. 178.71 MHz, carried on the second harmonic of the 76.5 MHz dot-clock. Also PAL and SECAM. tags: hardware hacking rf video Maybe I should have a tag for "TV output hardware designs".
