The XScale doesn't have enough integrated peripherals for it to be cost effective. It's also a power hungry beast compared to competition. It doesn't even have integrated USB2.0
No, it isn't the XScale, unless it's some chip they haven't announced yet, which is highly unlikely.
It's not ridiculous at all. I could name at least 4 competitors with better performing, lower power, more thoroughly tested solutions than theirs. I could point out that the bugs are a large factor in why it performs so badly and has such poor power consumption compared to them. I could point out how the severe stupidity in much of the architectural design and again the bugs lead to a much higher time-to-market. I myself spent months ironing out chip bugs which they themselves couldn't work out.
It's a shit, expensive, and power hungry chip, and I'm not at all surprised Apple jumped ship the moment something clearly better came up. The only reason they've probably stuck with them so long is lock-in: the cost of porting their code to another platform. But, as you so bluntly point out, Apple is not stupid, and porting is not a problem for them. How unfortunate for PortalPlayer.
How unfortunate that the developers at Apple probably feel just the same as I do about them.
I am always confused by stockholders who are surprised when this sort of thing happens. Ignore the press released, the stock pricing, the valuation, the marketing, and all that useless stuff. The reason they are suffering can be summarised rather concisely: Their Product Sucks.
Concentrate on that in future and you might save some money:)
...is because their chips were a buggy pile of putrid crap. Seriously I'm surprised they lasted this long. It's an underpowered chip by today's standards (ARM7TDMI? are they joking?), it's not the lowest power consumption available by a long shot, and they don't integrate enough peripherals to lower total product cost. They're years behind the competition now, and they have nobody to blame but themselves.
So, congrats to Apple for finally ditching them. You should all look forward to some better performing and longer lasting iPods in the future. Yes, I'm rather bitter from having to deal with the muppets at PortalPlayer in the past.
Oh really? Search Wikipedia entries, the articles, all links - no mention of iPod except in those annoying side adverts. Why? Because it has nothing to do with it
Credit where credit is due, and none is due here.
If you want credit, how about: Shannon, Fourier and Huffman. Then there's all the folks involved in working out noise masking and all the oddities of human hearing that I don't have the names of.
I seriously need a "No iPod mentions whatsoever" checkbox for my slashdot profile to pull some more signal out of the slashdot article noise.
For dialup modems, there is some optimisation you can do. There is a small "queue" of data in the modem on both your side and the ISP's side, which is used as a buffer to get higher throughput. At the low speeds a dialup modem runs at, this also means much higher latency when your connection gets close to saturation. If you remove the buffer, your throughput suffers, but you reduce some of the latency. At ethernet speeds, such buffering has a negligable impact on latency.
Of course, it's all bullshit because that still doesn't fix the other side's modem, and the long queues you'll find at the ISP itself, etc etc. The best way of making sure your data doesn't get queued is to deliberately stay away from saturating your link.
Current generation Athlon 64 X2's are already like this. Externally, they look like a big heat spreader. The heat sink makes contact with a very large area, and the retail cooling solution is surprisingly quiet and efficient. Certainly cools a lot better than the stuff they shipped with Athlon XP 3200+.
Re:We just got tired of being insulted
on
Demise of C++?
·
· Score: 5, Insightful
What Mr. Chemisor is saying is very familiar to me. Whenever the subject of C++ comes up on Slashdot, a big bunch of drones regurgitate some absurdities they heard somewhere about how it's slow, hard to use, and bogged down in legacy support. Some morons even go so far as to suggest plain C is superior. Some morons go so far as to make enormous projects using plain C and a bunch of type information hacks using macros that only serve to move type checking from compile-time to a run-time performance hit (cough GTK cough).
We're just plain tired of giving the same answers to the same people who never listen and carry on regurgitating the same crap they heard from some uninformed idiot. There's one thing that's very obvious from the numerous appearances of C++ on Slashdot recently: very few of the readers here have actually used C++ in any serious way.
You're only hurting yourselves when you dismiss C++ out-of-hand for uninformed reasons.
He doesn't even say it well. I had to scroll my browser to read a very awkward analogy to slavery, poor poetic repetition of phrase, and a conclusion which can be summed up as "Patents are like slavery, it's evil." Guess some people prefer quantity over quality.
Nice essay, lots of rhetoric, but no conclusions. You do yourself no favours by hiding your points behind crafted statements such as "I know it does not bode well for society if everyone is spending their time searching for loot in some MMORPG, rather than actually getting a good night's sleep so they can be productive at making loot in their real life". Just say "I do not think people should be searching for loot in an MMORPG, it is harmful.".
My company is porting our C++ Windows app to C in an embedded device
Why would you do that? There's nothing about C++ that rules it out on embedded devices. I smell a bad vendor toolchain. Rule no.1 for sane embedded device development: USE THE GNU TOOLCHAIN. Then you can use C++ and half your porting task is gone. You can use the same toolchain with an x86 target for testing on PCs. You wouldn't happen to be using Green Hills, or god forbid Tasking would you?
So far I have resisted malloc/free use but it gets tedious having the same argument with the next set of managers to take an interest in the project.
Removing dynamic memory management is a noble goal but it goes deep into your coding style, to the extent that you basically end up with forked code instead of portable code - one version for each target inside big #ifs. One nice alternative I've used in the past is a stack separate from the call stack. You can either allocate a fixed size stack using malloc (say, 4MB for a task), or from a fixed location such as on-chip RAM. Allocations are stricly last-alloc'd-first-free'd, which actually fits most usage patterns. The key advantage is you can throw away the entire pool in a single call (pop all), for example when an error occurs, or if you run out of memory. This makes error handling much, much simpler than having a ton of delete's depending on how far you got. It also makes allocation overhead extremely small - it's basically just pointer arithmetic. It's just a souped up "alloca", where the stack isn't the function call stack, so it doesn't go away when the function does.
Best of all, if you use this method you can have a non-embedded version of the "stack" allocator which just uses malloc instead. I've got an example app which does no dynamic memory allocation linked from my profile (it's a Vorbis decoder).
Bah. Games benchmarks? Doom 3? Cinebench? Those are all primarily tests of memory bandwidth not latency. Not bloody wonder they found very little difference.
That's the funny thing about all this 2-2-2-5 stuff being sold to gamers - it makes very little difference for them. It is however fantastic for code compilation, simulations, and anything else that has unavoidable random access patterns.
Thankfully they do market it for gamers, because if they did market it for scientists, software developers and generally in servers, it would be even more uber expensive than it is now.
That's pretty funny, because there's this programmer out there named John Carmack who kinda disagrees with your views. Although, who the heck is that Carmack guy qnyway anyway? He's only written about a half-dozen 3D game engines from scratch and designs rockets in his spare time.
Unlike the other reply, I do disagree with John Carmack. I don't think he really knows what he's talking about in this case. The Xbox 360 is based on multiple (mostly) symmetric general purpose cores, whereas the PS3 is based on having a single general purpose core and multiple DSPs. This is a huge difference!
The DSPs on the PS3 are much, much faster than the PPC core, and your code will run faster even if you just farm a task to a DSP and wait for it to finish (i.e not parallel). They are harder to program than the PPC core, but hey that's what Devkits and proper code design were invented for. Probably the majority of your team doesn't need to know how to program it - they just call the appropriate API function like "BlendSpanLine" or "CopyBuffer" a couple of experts (or Sony) wrote for them.
I think when Carmack commented on the state of parallelism in consoles, he didn't quite grasp how different the approach is on the PS3 and how much better a solution it actually is. Sony and friends correctly identified that (I'll hand-wave here) 90% of processing is taken up in 5% of your code, and that 5% is generally a tiny little loop you can hand optimise and shove on a DSP. I mean, FFS this is exactly what we're doing on PCs using the shader engines on graphics cards! Why complain when the PS3 offers the same thing but more versatile and more parallel?
The way you describe nyquist in terms of having a sample for the peak and trough shows you don't actually understand the theory, and you shouldn't be trying to teach us anything. Upsampling without a filter generates a perfect alias in the range between your old and new nyquist frequency.
Upsampling is generally less expensive than downsampling because the high frequencies either get killed by a trivial analog filter or by the limits of human perception (i.e not hearing much above 20kHz). It is cheap enough that there is no excuse to distribute audio an an already upsampled form. Hell, 1 bit DACs upsample to the MHz range, so Creative's 96kHz feature is just pure marketing tripe.
That said, you're right elsewhere, upsampling a crappy mp3 will only give you a more accurate representation of your crappy mp3.
Upsampling a crappy mp3 will theoretically give you exactly the same crappy mp3. Not more accurate. Whoever did Creative's marketing should be fined for false advertising practices.
shame he wont tell/show anyone how its done (ie. the source code)
The only thing he hasn't explained is how he generated the raw unmodulated DVB and PAL signals. PAL is pretty text book and there's no need to explain it. Creating a DVB signal is a huge project in itself. You can look up the details relatively easily and freely, and I think the GNU Radio project even has one.
As for the signal generation, he's given you the XFree86 timings, and explained the calculation behind it. What more could you want?
The clever bit is the way he's worked out the correct VGA timings and used harmonics to place the DVB signal at just the right frequency to be received. It's an underused trick you can do with DACs and ADCs: if you turn off the filter (or just have a crappy one like VGA cards do!) then you can reach frequencies far above half the sampling rate, with certain restrictions. It doesn't defeat nyquist - you basically move the "band" you're looking at to somewhere other than starting at 0Hz (DC). If it's a hack like this one which doesn't have an appropriate bandpass filter, you get a lot of crud in your signal, but presumably it's not enough to destroy the signal altogether.
I assume there's an issue with the Hsync and Vsync which aren't eliminated - but at a 76.5MHz pixel clock, it's probably a small enough glitch to not matter.
It's a nice trick I've been thinking of using for DAB (digital audio) receive and transmit, but I never thought of using the VGA in this way!
If Transmeta does close shop, I hope they consider opening up their "Code Morphing Software". It's an interesting approach to X86 processing on non-X86 processors
It's nothing special - it's just JIT code translation by another name, with some slight hardware assistance. The software concepts are nothing that hasn't been done before. That's not to take anything away from their achievements, it really does work very, very well unlike most others JITs. The interesting bit about Transmeta is the hardware, which was designed specifically around being targetted for a JIT translator. I'd love to see that opened up, but that would never happen.
I've been toying with the idea of grabbing one of these cheap Spartan 3 FPGAs to try out similar chip ideas.
Looks to me they were testing benchmarks on FS speeds on a medium (which happens to be flash).
I wounder what would happen if you were to actually write sequential raw data to these devices? Would'nt that give no FS skew?
Considering 99.9% of people would only ever be using a flash drive with FAT32 on it, I think the benchmarks are quite appropriate.
FAT32 happens to be quite a terrible format for flash usage, and the FAT tables take quite a bit of rewrites. The block erase size on type 2 flash (common these days) is 128KB, which means the entire FAT table is contained in 1 block! That gets erased and rewritten each time the FAT table is updated. Most of these drives have really cheap CPUs running the show and can't do any kind of intelligent rewrite strategy, other than bad block remapping.
If you write 128MB to a 128MB flash drive, the FAT table gets block erased 2048 times (assuming the usual windows 128 sector write size). Do that 100 times and you'll grow a bad block, which gets remapped. Do it 1000 times and simple schemes without wear levelling run out of spare blocks.
By the way, ISO9660 isn't at all suitable for a random access writable filesystem.
In their words, it has an FM tuner interface and controller. I would more accurately describe it as having a (buggy) I2C bus interface and an analog input for the processed signal. It does not have a built in tuner - it can only control an external one and mix the output signal from it.
I've been working with these exact chips for years and I would be very surprised if we've been spending extra dollars per unit on a needless external tuner chip:)
It will be most interesting to se how they plan to evade the EU EMC directive on this one.
Spewing HF and UHF energy out on the power-line is something you can't do in a residential context. (Just think of the emissions being transformed backwards through the power grid.)
There are already powerline LAN products on sale in the UK (just seen one in PC World the other day). I believe they have lawyered themselves around the issue by claiming that the emissions count as "incidental" and are below thresholds. They also set themselves up to lose lots of money if they were disallowed and hence, by twisted logic, ensured that they didn't get banned.
What worries me more is if powerline networking is allowed, then UWB will follow. The UWB brigade seems to be using the same ploy so far: create a large industry which will lose lots of money if disallowed, run hundreds of trials even if they all show the same problem (proof by exhaustive irrelevance), bribe^H^H^H^H^Hlobby communications authorities to make UWB discussion an "A" item. I know a few people in Ofcom who are rather irritated with the amount of attention UWB is getting.
This thing most likely uses the same GUTS even as the iPod shuffle, the chip in the shuffle already supports FM radio, Apple (like any sensible company) didn't provide it out of clean UI design.
I really think that you should say that the other way around: the iPod shuffle uses the same GUTS as all the cheap and not so cheap no-name MP3 players out there. It's just another Sigmatel Stmp3500 based MP3 player without a display, but with the reality distortion field applied. It probably even has all the same filesystem, frequency response and USB bugs as all the others. I wouldn't be at all surprised if the only part Apple played in making the Shuffle was the ID. I also wouldn't be surprised, as some have pointed out, if the company in the article are the people they outsourced it to.
The Stmp3500 does NOT have a built in tuner and I have no idea where everyone is getting that idea from. Apple probably didn't add an FM tuner because: a) it would be more expensive (most likely reason), b) it would be unusable without a display. I imagine they'd just have "random station selection" and think up a funky marketing slogan to hide the stupidity.
Most cheap MP3 players are built using standard chips that come with FM tuning and voice recording as standard. All you need is the firmware to activate the functionality.
The iPod Shuffle uses a Sigmatel Stmp3550, which doesn't have a built in FM tuner. There's an external tuner chip which only supports FM.
Re:If you could install it
on
iPod Shuffle RAID
·
· Score: 2, Informative
Um, you don't have DMA on flash media because you address it just like RAM. It's just slower and non-volitile.
This is just confusion caused by the x86-centric world's definition of "DMA".
NAND flash natively cannot be randomally accessed like ordinaly memory. It's treated more like a hard drive - you read entire sectors at a time (528 byte in this case), and erase/rewrite entire pages at a time (128KB for type II).
On the other hand, NOR flash is designed to be randomly readable like ordinary external memory, but writes still require an entire page erase/rewrite. But NOR is typically only used for boot ROMs in PCs and some embedded devices. They're small - up to about 4MB, whereas NAND flash is anything up to 512MB in a single chip. Any CF FLASH card you buy will be NAND (or MLC, which is similar) based.
CF cards supposedly don't have "DMA" because they don't support IDE DMA or UDMA modes. That limits them to PIO modes, which maxes at around 16MB/sec. For some hair brained reason, the x86 IDE interface infers this as meaning that the CPU must also access in PIO mode, and doesn't provide a DMA interface from the CF to memory, which is another speed impact. On most modern embedded devices I've used, even if the CF card doesn't support DMA, you are still presented with a DMA interface to access the card in PIO mode! It's just x86 which does it wrong.
In fact, CF can support DMA. You get DMA support on some of the 4GB/5GB hard CF type II hard disks - it's just not standardised (or documented...)
Slashdot Mirror
The DAC and headphone amplifier is integrated into the Sigmatel 3500 CPU which drives most of the show in the Shuffle.
No, it isn't the XScale, unless it's some chip they haven't announced yet, which is highly unlikely.
It's a shit, expensive, and power hungry chip, and I'm not at all surprised Apple jumped ship the moment something clearly better came up. The only reason they've probably stuck with them so long is lock-in: the cost of porting their code to another platform. But, as you so bluntly point out, Apple is not stupid, and porting is not a problem for them. How unfortunate for PortalPlayer.
How unfortunate that the developers at Apple probably feel just the same as I do about them.
Concentrate on that in future and you might save some money :)
So, congrats to Apple for finally ditching them. You should all look forward to some better performing and longer lasting iPods in the future. Yes, I'm rather bitter from having to deal with the muppets at PortalPlayer in the past.
I ascribe no such thing. It is merely a readily available and publically readable example which, incidentally, Britannica is not.
Oh really? Search Wikipedia entries, the articles, all links - no mention of iPod except in those annoying side adverts. Why? Because it has nothing to do with it
Credit where credit is due, and none is due here.
If you want credit, how about: Shannon, Fourier and Huffman. Then there's all the folks involved in working out noise masking and all the oddities of human hearing that I don't have the names of.
I seriously need a "No iPod mentions whatsoever" checkbox for my slashdot profile to pull some more signal out of the slashdot article noise.
Of course, it's all bullshit because that still doesn't fix the other side's modem, and the long queues you'll find at the ISP itself, etc etc. The best way of making sure your data doesn't get queued is to deliberately stay away from saturating your link.
Current generation Athlon 64 X2's are already like this. Externally, they look like a big heat spreader. The heat sink makes contact with a very large area, and the retail cooling solution is surprisingly quiet and efficient. Certainly cools a lot better than the stuff they shipped with Athlon XP 3200+.
We're just plain tired of giving the same answers to the same people who never listen and carry on regurgitating the same crap they heard from some uninformed idiot. There's one thing that's very obvious from the numerous appearances of C++ on Slashdot recently: very few of the readers here have actually used C++ in any serious way.
You're only hurting yourselves when you dismiss C++ out-of-hand for uninformed reasons.
He doesn't even say it well. I had to scroll my browser to read a very awkward analogy to slavery, poor poetic repetition of phrase, and a conclusion which can be summed up as "Patents are like slavery, it's evil." Guess some people prefer quantity over quality.
Quit the double-speak.
Why would you do that? There's nothing about C++ that rules it out on embedded devices. I smell a bad vendor toolchain. Rule no.1 for sane embedded device development: USE THE GNU TOOLCHAIN. Then you can use C++ and half your porting task is gone. You can use the same toolchain with an x86 target for testing on PCs. You wouldn't happen to be using Green Hills, or god forbid Tasking would you?
So far I have resisted malloc/free use but it gets tedious having the same argument with the next set of managers to take an interest in the project.
Removing dynamic memory management is a noble goal but it goes deep into your coding style, to the extent that you basically end up with forked code instead of portable code - one version for each target inside big #ifs. One nice alternative I've used in the past is a stack separate from the call stack. You can either allocate a fixed size stack using malloc (say, 4MB for a task), or from a fixed location such as on-chip RAM. Allocations are stricly last-alloc'd-first-free'd, which actually fits most usage patterns. The key advantage is you can throw away the entire pool in a single call (pop all), for example when an error occurs, or if you run out of memory. This makes error handling much, much simpler than having a ton of delete's depending on how far you got. It also makes allocation overhead extremely small - it's basically just pointer arithmetic. It's just a souped up "alloca", where the stack isn't the function call stack, so it doesn't go away when the function does.
Best of all, if you use this method you can have a non-embedded version of the "stack" allocator which just uses malloc instead. I've got an example app which does no dynamic memory allocation linked from my profile (it's a Vorbis decoder).
You say that as if C++ isn't in use by the vast majority of software houses on the planet, and rather successfully for that matter.
That's the funny thing about all this 2-2-2-5 stuff being sold to gamers - it makes very little difference for them. It is however fantastic for code compilation, simulations, and anything else that has unavoidable random access patterns.
Thankfully they do market it for gamers, because if they did market it for scientists, software developers and generally in servers, it would be even more uber expensive than it is now.
Unlike the other reply, I do disagree with John Carmack. I don't think he really knows what he's talking about in this case. The Xbox 360 is based on multiple (mostly) symmetric general purpose cores, whereas the PS3 is based on having a single general purpose core and multiple DSPs. This is a huge difference!
The DSPs on the PS3 are much, much faster than the PPC core, and your code will run faster even if you just farm a task to a DSP and wait for it to finish (i.e not parallel). They are harder to program than the PPC core, but hey that's what Devkits and proper code design were invented for. Probably the majority of your team doesn't need to know how to program it - they just call the appropriate API function like "BlendSpanLine" or "CopyBuffer" a couple of experts (or Sony) wrote for them.
I think when Carmack commented on the state of parallelism in consoles, he didn't quite grasp how different the approach is on the PS3 and how much better a solution it actually is. Sony and friends correctly identified that (I'll hand-wave here) 90% of processing is taken up in 5% of your code, and that 5% is generally a tiny little loop you can hand optimise and shove on a DSP. I mean, FFS this is exactly what we're doing on PCs using the shader engines on graphics cards! Why complain when the PS3 offers the same thing but more versatile and more parallel?
The way you describe nyquist in terms of having a sample for the peak and trough shows you don't actually understand the theory, and you shouldn't be trying to teach us anything. Upsampling without a filter generates a perfect alias in the range between your old and new nyquist frequency.
Upsampling is generally less expensive than downsampling because the high frequencies either get killed by a trivial analog filter or by the limits of human perception (i.e not hearing much above 20kHz). It is cheap enough that there is no excuse to distribute audio an an already upsampled form. Hell, 1 bit DACs upsample to the MHz range, so Creative's 96kHz feature is just pure marketing tripe.
That said, you're right elsewhere, upsampling a crappy mp3 will only give you a more accurate representation of your crappy mp3.
Upsampling a crappy mp3 will theoretically give you exactly the same crappy mp3. Not more accurate. Whoever did Creative's marketing should be fined for false advertising practices.
The only thing he hasn't explained is how he generated the raw unmodulated DVB and PAL signals. PAL is pretty text book and there's no need to explain it. Creating a DVB signal is a huge project in itself. You can look up the details relatively easily and freely, and I think the GNU Radio project even has one.
As for the signal generation, he's given you the XFree86 timings, and explained the calculation behind it. What more could you want?
The clever bit is the way he's worked out the correct VGA timings and used harmonics to place the DVB signal at just the right frequency to be received. It's an underused trick you can do with DACs and ADCs: if you turn off the filter (or just have a crappy one like VGA cards do!) then you can reach frequencies far above half the sampling rate, with certain restrictions. It doesn't defeat nyquist - you basically move the "band" you're looking at to somewhere other than starting at 0Hz (DC). If it's a hack like this one which doesn't have an appropriate bandpass filter, you get a lot of crud in your signal, but presumably it's not enough to destroy the signal altogether.
I assume there's an issue with the Hsync and Vsync which aren't eliminated - but at a 76.5MHz pixel clock, it's probably a small enough glitch to not matter.
It's a nice trick I've been thinking of using for DAB (digital audio) receive and transmit, but I never thought of using the VGA in this way!
It's nothing special - it's just JIT code translation by another name, with some slight hardware assistance. The software concepts are nothing that hasn't been done before. That's not to take anything away from their achievements, it really does work very, very well unlike most others JITs. The interesting bit about Transmeta is the hardware, which was designed specifically around being targetted for a JIT translator. I'd love to see that opened up, but that would never happen.
I've been toying with the idea of grabbing one of these cheap Spartan 3 FPGAs to try out similar chip ideas.
I wounder what would happen if you were to actually write sequential raw data to these devices? Would'nt that give no FS skew?
Considering 99.9% of people would only ever be using a flash drive with FAT32 on it, I think the benchmarks are quite appropriate.
FAT32 happens to be quite a terrible format for flash usage, and the FAT tables take quite a bit of rewrites. The block erase size on type 2 flash (common these days) is 128KB, which means the entire FAT table is contained in 1 block! That gets erased and rewritten each time the FAT table is updated. Most of these drives have really cheap CPUs running the show and can't do any kind of intelligent rewrite strategy, other than bad block remapping.
If you write 128MB to a 128MB flash drive, the FAT table gets block erased 2048 times (assuming the usual windows 128 sector write size). Do that 100 times and you'll grow a bad block, which gets remapped. Do it 1000 times and simple schemes without wear levelling run out of spare blocks.
By the way, ISO9660 isn't at all suitable for a random access writable filesystem.
I've been working with these exact chips for years and I would be very surprised if we've been spending extra dollars per unit on a needless external tuner chip :)
Spewing HF and UHF energy out on the power-line is something you can't do in a residential context. (Just think of the emissions being transformed backwards through the power grid.)
There are already powerline LAN products on sale in the UK (just seen one in PC World the other day). I believe they have lawyered themselves around the issue by claiming that the emissions count as "incidental" and are below thresholds. They also set themselves up to lose lots of money if they were disallowed and hence, by twisted logic, ensured that they didn't get banned.
What worries me more is if powerline networking is allowed, then UWB will follow. The UWB brigade seems to be using the same ploy so far: create a large industry which will lose lots of money if disallowed, run hundreds of trials even if they all show the same problem (proof by exhaustive irrelevance), bribe^H^H^H^H^Hlobby communications authorities to make UWB discussion an "A" item. I know a few people in Ofcom who are rather irritated with the amount of attention UWB is getting.
I really think that you should say that the other way around: the iPod shuffle uses the same GUTS as all the cheap and not so cheap no-name MP3 players out there. It's just another Sigmatel Stmp3500 based MP3 player without a display, but with the reality distortion field applied. It probably even has all the same filesystem, frequency response and USB bugs as all the others. I wouldn't be at all surprised if the only part Apple played in making the Shuffle was the ID. I also wouldn't be surprised, as some have pointed out, if the company in the article are the people they outsourced it to.
The Stmp3500 does NOT have a built in tuner and I have no idea where everyone is getting that idea from. Apple probably didn't add an FM tuner because: a) it would be more expensive (most likely reason), b) it would be unusable without a display. I imagine they'd just have "random station selection" and think up a funky marketing slogan to hide the stupidity.
The iPod Shuffle uses a Sigmatel Stmp3550, which doesn't have a built in FM tuner. There's an external tuner chip which only supports FM.
This is just confusion caused by the x86-centric world's definition of "DMA".
NAND flash natively cannot be randomally accessed like ordinaly memory. It's treated more like a hard drive - you read entire sectors at a time (528 byte in this case), and erase/rewrite entire pages at a time (128KB for type II).
On the other hand, NOR flash is designed to be randomly readable like ordinary external memory, but writes still require an entire page erase/rewrite. But NOR is typically only used for boot ROMs in PCs and some embedded devices. They're small - up to about 4MB, whereas NAND flash is anything up to 512MB in a single chip. Any CF FLASH card you buy will be NAND (or MLC, which is similar) based.
CF cards supposedly don't have "DMA" because they don't support IDE DMA or UDMA modes. That limits them to PIO modes, which maxes at around 16MB/sec. For some hair brained reason, the x86 IDE interface infers this as meaning that the CPU must also access in PIO mode, and doesn't provide a DMA interface from the CF to memory, which is another speed impact. On most modern embedded devices I've used, even if the CF card doesn't support DMA, you are still presented with a DMA interface to access the card in PIO mode! It's just x86 which does it wrong.
In fact, CF can support DMA. You get DMA support on some of the 4GB/5GB hard CF type II hard disks - it's just not standardised (or documented...)