But I had a problem when I tried playing it at a resolution other than 1280x1024. I couldn't read some of the text (especially when trying to join an internet game).
I had this problem but discovered it was because the display settings for my Ti4200 were at "performance" rather than "quality" (right click desktop, settings, advanced, directX, blah, blah). It's probably because fonts are treated just like textures and are reduced in resolution along with everything else. It seems to me there's no difference in speed between performance and quality settings, so it's no loss - and it looks way better anyway.
Hope that helps... it certainly had me puzzled for a while. I think they need to at least add this to the FAQ.
This is the conventional wisdom, and in my experience, this particular nugget causes more embedded and real time software projects to fail than any other.
The conventional wisdom is "a production system doesn't have bugs so we don't need to protect against them". They obviously never use their own chip designs. It takes so much longer to ever get the damn system working, and when it works you still don't know if you're just being lucky with memory corruption. I'm really going to have to shoot the next manufacturer I see quoting that memory protection is unnecessary. Unfortunately, embedded chip manufacturers all seem to have forgotten that development time needs to be factored into cost.
First off, on a modern PowerPC processor, memory protection (that is, without virtual memory support) can be implemented very cheaply. If you can do it just with the IBAT/DBAT registers, it should be a constant-time overhead, which is good enough for hard-real time. Oddly enough, I can't find a single reference on the net that measures the cost of memory protection alone on a modern CPU. Anyone? Anyone?
I don't know about PowerPC, but a typical ARM MMU has a very small overhead, especially if you use large page sizes. From memory, there's 1 page directory (or large page) per 4MB of address space, which points to a page table containing 32 bit entries for each page (4KB or 64KB pages). There's something like 32 TLBs, and lookups are done in hardware straight from memory.
So, every time there's a TLB miss, there's an additional latency of two 32 bit SDRAM reads. You can put the tables in internal SRAM (if you have it), which means it only takes a few extra clocks on a TLB miss. TLB misses generally aren't an overhead in my experience - you're going to be dwarfed by the cache miss cost anyway.
Basically, anyone telling you an MMU has overhead is talking out of the wrong orifice. There are very, very few things which would ever need better latency than a couple of cache misses and TLB misses. If you need that kind of low latency, it should be done in hardware.
But let's say they're looking at 1v just for kicks.
10-50mA would suddenly turn into 50-250mA. So, "x"mA is kind of a misleading ter
No, I meant 10-50mA at 5v. The PXA255 is absolutely shockingly efficient. It really is better than pretty much any other low-power-high-perfomance CPU. I know this from experience - as in trying it on an actual board and sticking it on an accurate meter:)
The reason he's got 200mA is really most likely because of the combination of incorrect setups (no low power SDRAM mode) and bad components selection. 200mA is way, way off anything I've ever seen on any platform comparable to the gumstix one.
I realize that 200 mA is likely to be less than one watt, but that's still a significant amount of heat to emit for a device worn next to the skin.
I'm a little surprised by that figure, but it's probably either because it doesn't use low power flash and SDRAM parts, or simply because it's not configured correctly. For example, there's a well hidden bit in the SDRAM controller on a PXA255 which enables a low power mode (it goes unclocked except for refresh when idle), which shaves off a ton of power.
I would expect something more like 10-50mA at 5v with a PXA255, flash and SDRAM.
In the UK, broadband-over-powerlines hasn't quite been abandoned yet - see the effort being trialled by Scottish Hydro-Electric. 30 quid a month for 1Mbit/s symmetric is a fairly competitive price compared to UK cable/ADSL prices, but one wonders if they have indeed solved all the interference issues.
They are constantly in a trial. The broadband-over-powerline lobby are attemping a "proof by exhaustive irrelevance" much like the UWB lobby. It's a inherently flawed technology - no, wait that's far too polite for these idiots - it's an inherently incredibly stupid idea that a few people with lots of money and lots of influence are attempting to push through to consumers.
None of these trials have worked. Nearly every trial has ended abruptly because either they interfered with TV reception next door, or blocked something more essential like police radio. All have proved it won't work. The only reason this is still being proposed is because a few people have a lot of money invested in it. There is an overwhelming amount of evidence already accumulated to show that it's as flawed as the theory it works by.
The thing which irritates me most is that despite every trial showing that it will definitely interfere with other services, they will probably be allowed to roll out. Just like UWB. Probably they'll just keep having trials until we get bored and give in.
Well, seeing as I wrote a fair bit of the client-side software for the Rio Receiver I guess I can point out these are both wrong:
Unlimited storage (on the server PC). Some folks have more than 20GB of music (legitimately purchased even)
The Rio Receiver is exactly the same class of product as the Squeezebox - it's a diskless thin client that streams music stored on a server. The only space limit is the size of the hard disk(s) in your PC.
Ability to stream MP3s to multiple Squeezeboxes from a single server, centralizing your music collection.
Multiple Rio Receivers can stream from a single server. You're pretty much limited only by ethernet bandwidth, which is pretty huge compared to the 16KB/sec or so MP3 takes up. If you do stream many (like, 16+) then you might end up chewing a bit of your PC's CPU time up. We had a setup in a hotel in Ibiza supplying every room that way.
The only thing which I think sets aside the Squeezebox is the built in 802.11b, because quite frankly most people end up sticking an ethernet-to-802.11 dongle on their Rio Receivers.
Not at all true for the UK. SSE is going ahead with commercial trials in Stonehaven and Winchester, after earlier technology trials in Crieff and Cambeltown.
That's just it - the broadband-over-power-lines brigade have been attempting a "proof by exhaustive irrelevance". They hold a new trial every few months in another remote place and end up with the same results: it usually interferes with TV reception, and in some cases interferes with an emergency band so badly they abort the trial.
This is very much like the UWB brigade, who are attempting to circumvent normal acceptance procedures by building themselves up for a massive failure - thereby claiming that it's all unfair and would destroy their business. At the end of the day they're both just inherently flawed technologies pushed forward by people who only really care about the potential returns.
Dont get me wrong on this, Im no way in favour of DRM. But if people are going to buy things from IMS then they know its got it. Its not the same as me buying a CD and finding i cant play it on my PC. Not by a long stretch. Now, if apple didnt tell you they use DRM on IMS then id agree that its only fair to expect to be able to use it elsewhere, but they dont, so i wouldnt.
tightly controlled, overpriced, and incompatible market.
An unfair deal is still an unfair deal even if you accept it. The logic of "people buy it therefore it's ok" is unfortunately the same logic people are using to say that DRM wrapped online music sales works. BBspot has some fun things to say about that. At the end of the day iTunes is still giving you less than you deserve, and there is absolutely no reason to be an apologist for the monumental amount of screwing that's going on here.
I tend to agree; nevertheless, compact computing devices will continue to grow in capacity and speed. They will accomodate even the capacious appetites of Microsoft-engineered software. Developers learned to accept MS's engineering bloat on desktop/server operating systems, and it will be no different here.
NO! One major factor in embedded systems is cost - memory and CPU are always sacrificed first. I suggest that MS should learn to accept that they cannot write bloated operating systems and expect embedded systems to bend over a barrel for them.
Already handheld devices are at the performance level of desktops of the early-to-mid 1990s, albeit without rotating mass storage. But SD-Flash is in the multi-gigabyte range, which is more storage than we had on desktops in those days.
Disproof:
Multi-gigabyte SD cards are hideously expensive.
The most you should expect from a PDA these days is about 400MHz of XScale, 32MB SDRAM, and 256MB flash. That's state-of-the-art.
The current state-of-the-art PDA will NOT run (acceptably) the current state-of-the-art Microsoft desktop OS.
If you put a faster processor in, more RAM, and larger flash, you would have a hideously expensive PDA that sucked for battery life.
An interesting thing is that while the power of portable devices has increased about 10x in recent years - the efficiency hasn't got better by more than about 2-3x. That's yet another thing to add to the list of "things people don't get about embedded systems": inefficient code leads to short battery life. Anyone who's programming an embedded system and doesn't understand that needs to be shot. Repeatedly.
In short, the book is the image of what it purports to describe : big and heavy.
MS still don't seem to understand the fundamental problems faced with making embedded applications. You can't just "get rid of a bit of functionality" - you either should have started with slimness in mind, or you've got to redesign a lot of code. I've worked on many a platform where some piece of Microsoft code had to be integrated. Usually it ends up being the make-or-break of whether everything fits or not. Usually it's a tight squeeze. Usually we need to ditch some of our functionality to fit it:)
Quite frankly Microsoft are stuck with the misfortune of designing only for x86 PC desktops. You end up assuming memory and CPU are infinite - both of which are in short supply in embedded systems. A laughably short supply in some cases: how about 64KB of RAM and 30MHz to fit an API into? How about not having a dynamic memory allocator? Yeah, no mallocs allowed! How about if your endian isn't little, your chars aren't signed, your shorts aren't short, and your ints won't work unaligned? Practically every piece of "portable" code I've used from a commercial entity completely ignored these problems.
The thing is - you can have your cake and eat it! It is entirely possibly to write compact APIs which don't lose anything when used on desktop system. They usually benefit from a thoughtful design. I hate to use Linux as an example (especially in the same context as Microsoft), but it really is a good example of thoughtful API design - especially in the sense that "x86 != world". It's not in the same ball-park as some embedded OS's, but it's compact enough to use in devices with around 1MB of RAM (with a bit of tweaking, granted). A much better example is Redhat eCos, which is great for anything from an MMU-less device with less than 100KB, to a full blown "desktop class" PC running a single application.
The thing which makes me laugh most from your post...
SQL CE, Embedded Visual Basic or XML
Yep - you couldn't even fit the parser for any of those in a large class of embedded systems, let alone the back end:)
It's no wonder Microsoft never managed to break into the mobile phone market... they were too busy integrating buzzwords.
You do realize that Motorola SPS is an ARM licensee, and that the i250 platform mentioned is a Motorola CPU with both ARM and DSP cores optimized for wireless.
You're right, Motorola still make their own chips, just with ARM cores instead of their own. I suppose I could more accurately say that I find it funny Motorola favours other core designs to their own.
About the only core they have which is both high performance and low power is the 56k, which they use in that i250. But 56k is a pain to program and extremely inefficient at anything except DSP.
Yes, that is fairly strange. The low-power PPC chips are pretty nice.
The XScale has an order of magnitude better performance per watt than PPC - we're talking fractions of a watt flat out at 400MHz (see the spec sheet). Also note that this is an Intel/DEC improved ARM core, and isn't x86 based in the slightest.
This particular XScale also has a large wedge of on-chip flash and a bunch of handy peripherals for mobile devices - which is unsurprising seeing as that's what it seems to have been made for.
It is funny that Motorola favour other manufacturer's chips for embedded low power devices, but the reason is simple: none of their stuff fits the bill. Even their own mobile phones seem to use ARM these days.
It irritates me to see someone drawing such awful conclusions from bad information.
There is nothing Linux does fundamentally different to Windows with CDROM drives. Windows makes no attempt at spinning at less than maximum speed. In fact, a large portion of the drives I've tested don't even support speed setting. So, there is no reason why Linux would "shorten dramatically [your] cdrom lifecycle". I suspect you added that just to troll a bit.
I've personally had the displeasure of implementing CD ripping software for an embedded device, and dealing with the multitude of buggy-as-hell CDROM drives. It's a nightmare - every single drive I tested ended up requiring at least one workaround for a firmware bug. It's shocking how little testing has obviously gone into these devices. CDROM drives suck, basically.
Also something you don't understand is that CDROM drives are inherently not made just for windows. They all run (these days) to either the ATAPI or SCSI MMC spec (which are pretty much the same thing). There's nothing in those documents which refers to Windows, or Linux for that matter. CDROM drives are open hardware, in a sense.
Where it all goes wrong (and where it's gone wrong in LG's case) is when a manufacturer only tests their drive against one system, rather than against the spec, or multiple systems. That not only ensures that it's largely untested, but it also pisses off the software developers of the system they test against - they're stuck with not touching "untested" commands from then on! You end up with stupid whitelists or blacklists or just never supporting any enhanced feature set, for fear of destroying drives, or otherwise malfunctioning.
I'm actually not shocked that LG have the incompetence to create a firmware which can destroy itself. It's normally a very, very hard thing to do because flash chips have a "write protect" you normally turn on first thing, so software bugs can't accidentally kill it. But given the very obvious lack of technical skill of the people involved in writing CDROM drive firmware these days, nothing surprises me.
This is also the reason that gun manufacturers can't be held responsible for crimes commited with guns. If the intended use is hunting or self protection, then they cannot be held responsible for any other use. However, if there is reasonable evidence to suggest that the guns have a forseealbe intended use to commit crimes, the manufacturer can be held responsible.
I can foresee killing somebody by cramming 20 twinkies down their throat. Should we hold the manufacturer reponsible?
Really, I was almost tempted to not bother sending this because it's so obvious. Quite frankly there are too many people using that weak argument to make lots of money out of frivolous lawsuits. That's basically the reasoning being used to sue games developers, i.e GTA3.
Let me guess, you live in the US and don't have a fucking clue what the metric system is all about. For your information, the metric prefixes kilo, mega, and giga stand for 10^3, 10^6, and 10^9, and NOT 1024, 1024^2, 1024^3. The new units (KiB, MiB, etc) are meant to stop the abuse of the metric prefixes.
No, I live outside the US and I'm constantly baffled by peoples' willingness to keep using confusing units. That's the point - powers of 10 are confusing and pretty useless when talking about storage which more naturally works in powers of 2. The "new units" are an unnecessary and ugly hack by SI who have absolutely no right to talk about computer standards. The most telling thing is that they didn't even bother with units you can pronounce.
What irritates me most of all is the viral history rewriting that hard disk manufacturers started. There was never any confusion over what a kilobyte, megabyte or gigabyte was until some bright spark decided they could cheaply one-up on their competition just by redefining the units. And slowly people started buying the argument that "everyone knows M is a million, you're just wrong if you think otherwise." Suddenly people (including you apparently) have the nerve to claim some kind of superior knowledge on this matter. You've been lied to, cheated and now you're repeating the same lie to everyone else.
Go back in time a bit. Everybody knows that when you talk about storage or processors a byte is 8 bits, a kilobyte is 1024 bytes, a megabyte is 1024 kilobytes, a gigabyte is 1024 megabytes, etc. Everybody knows that when you talk about communications a bit is the basic unit of transfer, a kilobit is 1000 bits, a megabit is 1000 kilobits, and gigabit is 1000 megabits, etc. Whenever you talk about both, you indicate which you mean. Nobody is confused, and everyone uses the same standard. I find it insulting that anyone can claim to me that history is other than I remember.
Hard disk and flash manufacturers have a point that their storage is no longer based on powers of 2. But that's all I'll give them. It's obvious they're trying to be deceptive with their numbers. Here's an example - flash manufacturers can pick any old number of bytes to cram into their flash device, but they decide to pick 64 million. Why 64 million? It's obvious - it implies a power of 2. They could have picked any number, but powers of 2 imply you're getting slightly more than 64 million.
I wouldn't be surprised if a lot of focus in the lawsuit is on the transition between when manufacturers all used powers of 2, to the gradual shift to powers of 10, and why some still use powers of 2 for the major part of the size, when they could have picked any size.
This was standardized years ago and is valid for all people*, not only engineers on one side or computer geeks on the other.
This is history rewriting. Everybody's been using powers-of-2 when it comes to KB, MB, GB, etc for decades. SI come along thinking there's some confusion - which there isn't, it's only the hard drive manufacturers who are causing confusion - and slap down a horrible "standard".
Let me guess, you've only been using computers for a past 5 years?
It's generally true that low clock speed gives you low power, but when you're throwing a custom core at a problem, that's not necessarily true. The amount of power is basically proportional to the number of gates you have to switch. If you're running at 1/4 the clock speed, but you're switching 4 times as many gates, you'll probably end up with the same power requirement. Put simply: imagine running 4 processors in parallel at 1/4 the clock speed - assuming perfect parallelism, I'd say it'd still take at least as much power. If you run into limits such as having to turn up the voltage at higher clocks, that's another matter, but at these clock speeds it's not a major factor.
The trick is they have is a single issue RISC core (1 instruction per clock) running in parallel with a 4 issue VLIW DSP core (4 instructions per clock). Assuming it's all running at peak rate (which it hopefully will be for the majority of time) that's about 60 MIPS of processing going on there for a 64kbit Vorbis stream. Compare that to an ARM7TDMI (which a lot of players are based on), which requires (ball park) 30-50MHz for the same stream. The figure they state of 74MHz is nonsense - that's the general class of processor you require, not the actual MHz. You'll find higher bit rates requiring most of that 74MHz, though.
If they can come up with a real piece of hardware or a simulation that says it takes less than 100-200mW in an actual system, then I'll be impressed. That's about how much your average MP3 player takes. (Power = Battery mAh * Battery Voltage / Time in hours, work out how much yours takes). Just having a low clock speed is as incomplete a power consumption picture as Intel's use of high clock speeds alone is to performance.
Apart from giving the NYT your e-mail addy for spam purposes, what real point is there to free registration?
That's the thing - it's not free depending on your definition. By my own definition, you're giving them valuable information, and they get to keep it and use it as they will, including spamming if they feel like it (or spam from any company which buys them out, they sell it to if they're feeling bankrupt, etc). It's practically misadvertising of a service, but it's accepted now, so everyone gets away with it.
If it really were free, why would you need to register in the first place?
Now we can sort out the legitimate Spam from the illegitimate ones.
Since when is any unsolicited email legitimate? This is what I find most disgusting about the proposal - it diverts away from the real issue. Spam is just plain wrong.
Those trying to claim the high road of "we are just marketers" will have to comply and get filtered, or risk jail. Those that don't are branded as law breakers. This law could put every American based spammer out of buisness eventually.
How about this - they all comply and tag everything with "ADV:". And because it's all "legitimate" now, they'll send more spam, to more people, and all the other businesses who previously considered spam wrong will also join in. We'll soon have the vast majority of email traffic as spam, as opposed to the slight majority we currently have at some ISPs. Everyone who knows how to filter will still be receiving all that bandwidth, and all the fibres and routers in the world will still be passing them on. I currently receive up to 50 megabytes of spam a month - and that's a single IP on a 512kbit DSL account. So I'm supposed to just put up with the bulk of spam and filter stuff out at my end?
Quite frankly either the anti-spam people behind this proposal don't understand the issues, or the spam people behind this proposal know them very well. Perhaps both.
This is not a good thing. Oh yeah, everyone can simply filter out by "ADV:" - like that'll stop people actually sending spam, stop the enormous bandwidth usage (the majority of email is spam for some ISPs), and make the whole practise less attractive. On the contrary, I expect nothing less than the big spammers sending even more, and when their ISPs turn on them they'll sue with reference to the legitimacy as written in law. I expect no less than every single business in the afflicted states sending you endless amounts of spam. After all - it's legal, so it must be ok. The boards of directors can sleep well at night, marketing can happily smoke some more crack, and the only people with a frown on their faces are the few who remember a time when you didn't fuck with the beautiful creation that was the internet and the people that inhabited it.
Don't believe the hype - it's just another opt-out proposal. Opt-out is a flawed scheme only ever pushed by people who are naive to both the technical and practical issues. It's an enormous waste of resources (bandwidth, energy, people's time), and at the end of the day it's only partially solved just one of the issues at the expense of ensuring that we'll never solve any of the others. This really is a case of "the slippery slope exists and it will happen".
Like all the other opt-out schemes, all you have to do is opt-out of those 50 million emails you're about to receive. Legitimately. Enjoy your day.
We have software patents in the US and have had it for many years. I'm not aware of any case where Microsoft or any other big company is trying to shutdown an Open Source project using patent laws.
It is, dare I say, ironic that Microsoft hasn't engaged in that activity, but there are plenty of other big companies that have and still are trying to shut down open source projects using patent laws. I'm not even going to bother quoting any, there's so many instances.
The claim that "with patent law allowed, the floodgates would be opened and Linux distributors swamped and bankrupted by court claims - with Microsoft leading the charge." is baseless.
You neatly chopped off the start of that quote, "The fear is that with patent law allowed...". They're not claiming anything, they're just giving a likely scenario. The aggressive anti-Linux retoric of the heads of Microsoft and their dubious involvement in the SCO vs Linux nonsense is enough to give weight to that outcome being likely.
If a company does some real research in computer science then it invests millions of dollars and severals years of time into the development of new technologies. However without a strong system to prevent IP theft, any jerk company can come and steal those technologies.
Software is relatively cheap. I would raise an eyebrow at any company which said it has invested millions of dollars in researching a new software "technology". It's not like you have to buy lasers, or break apart pieces of DNA to aid that research.
This is all irrelevant anyway. The real theft in my opinion is the patent system. I find it offensive that I can independently come up with a software idea only to find that somebody has "done it first", and therefore they own all rights to the use of it. This isn't even a rare occurrance - there are an enormous number of trivial and even complex software patents out there which any number of people could have come up with independently, with or without research. I personally have thought up countless algorithms indendently which all turned out to have been already patented (including natural order spreadsheet recalculation, parts of LZW, some specifics of voxel rendering). There are an enormous number of people out there who can and probably have also. It is absolutely fucking ridiculous that my efforts at furthering the art are in fact being constantly restricted by the very process that was setup to encourage it.
Even worse, the original inventor will go out of business because the thiefs don't have the development expenses, so that they can offer the products much more cheaply. And patents are there to prevent such stuff.
The software patent system has always been and still is used solely for the purposes of protecting against other people invoking patent law. This is recursive, and boils down to being pointless. Products which are protected by patents inevitably end up being more expensive to the consumer, simply because the company has been granted a monopoly. Worse, a company granted a patent doesn't even have to sell anything. They can just sit back and collect taxes from anyone crossing over their piece of land grab.
Many people fear that stuff like Amazon's one-click patent and other trivial patents will come out. But I don't think this is a real problem. Such trivial patents are cause by a fucked legal system.
I don't think the triviality of a patent is relevant at all. I don't think I can identify any piece of software which at the very least hundreds of other developers around the world could also have come up with. This does lend a certain amount of uniqueness to the situation with software patents. The legal system problems are not the cause here, they're the symptoms of the wrong model and wrong premise being used to solve a problem that doesn't exist.
I'd rather have cheap products that sometimes don't work on 10 year old players (and protects rights for a creator of art) than expensive ones that can be pirated but work on all players.
Why the choice between these two absurd cases? Why does it logically follow that cheap products don't work on 10 year old players, or that ones which can be pirated are more expensive?
It doesn't logically follow, though many in the industry would rather it were the case. Making a product require DRM uses up lots of valuable developer time, and tends to increase your hardware requirements just to handle encryption and secure handling of keys and other crap. It just makes it more expensive at the end of the day, and only serves to piss off your customers.
I just hope your effors are BSD licensed so that businesses can use it. I'm normally a GPL person, but GPL isn't going to benefit businesses releasing ogg support.
At the moment any project I release ends up GPL simply because it's the most restrictive (genuine) public license. I should really use BSD-with-advertising because I don't actually mind businesses using my code, and it gives me a free advert too.
I have an iPod.. I know the cpus they use in these are pretty beefy compared to the other mp3 players -- does this one have the raw power to do tremor?
iPods are basically a dual core ARM7TDMI which is fast enough to decode about 2-3 MP3 streams simultaneously, but I'd guess they're clocked low enough to handle just the one and save a bit of battery. Vorbis (specifically Tremor) has roughly the same CPU requirement as MP3 (slightly more), but uses a lot more RAM. All that would mean is it'll eat battery quicker.
I'd say that so long as you have about 50 MIPS (at arithmetic) and 300KB of RAM, you should be able to fit it into that processor. Anything less and it should still fit but you'd have some work to do or maybe some quality tradeoffs. That means pretty much any of the MP3 players out there with general purpose CPUs or DSPs doing the decoding should handle it.
Re:Hopefully
on
Ogg Now An RFC
·
· Score: 5, Informative
Actually, Tremor, the integer codec, took care of that over a ago according to the changelog. And it's released under a bsd-like license.
Unfortunately Tremor isn't a one-size-fits-all. It's got nasty things like dynamic memory allocation all over the shop and still a rather large memory overhead. Actually, to be 100% compliant with the Vorbis 1.0 spec it's rather difficult to turn out a fast and small implementation (I've been trying).
At the moment I'm working on getting my own implementation working with an extremely small RAM overhead. It's by no means trivial getting it working on the DSPs you find in most MP3 players, and almost none of the source code to Tremor could be successfully ported to them either. I don't expect any of the source code I'm writing for my own implementation to be used as anything but a reference for writing a version to run on DSPs.
Of course, it would have been much more difficult even starting to write my own implementation were it not for freely available specs.
Slashdot Mirror
I had this problem but discovered it was because the display settings for my Ti4200 were at "performance" rather than "quality" (right click desktop, settings, advanced, directX, blah, blah). It's probably because fonts are treated just like textures and are reduced in resolution along with everything else. It seems to me there's no difference in speed between performance and quality settings, so it's no loss - and it looks way better anyway.
Hope that helps... it certainly had me puzzled for a while. I think they need to at least add this to the FAQ.
The conventional wisdom is "a production system doesn't have bugs so we don't need to protect against them". They obviously never use their own chip designs. It takes so much longer to ever get the damn system working, and when it works you still don't know if you're just being lucky with memory corruption. I'm really going to have to shoot the next manufacturer I see quoting that memory protection is unnecessary. Unfortunately, embedded chip manufacturers all seem to have forgotten that development time needs to be factored into cost.
First off, on a modern PowerPC processor, memory protection (that is, without virtual memory support) can be implemented very cheaply. If you can do it just with the IBAT/DBAT registers, it should be a constant-time overhead, which is good enough for hard-real time. Oddly enough, I can't find a single reference on the net that measures the cost of memory protection alone on a modern CPU. Anyone? Anyone?
I don't know about PowerPC, but a typical ARM MMU has a very small overhead, especially if you use large page sizes. From memory, there's 1 page directory (or large page) per 4MB of address space, which points to a page table containing 32 bit entries for each page (4KB or 64KB pages). There's something like 32 TLBs, and lookups are done in hardware straight from memory.
So, every time there's a TLB miss, there's an additional latency of two 32 bit SDRAM reads. You can put the tables in internal SRAM (if you have it), which means it only takes a few extra clocks on a TLB miss. TLB misses generally aren't an overhead in my experience - you're going to be dwarfed by the cache miss cost anyway.
Basically, anyone telling you an MMU has overhead is talking out of the wrong orifice. There are very, very few things which would ever need better latency than a couple of cache misses and TLB misses. If you need that kind of low latency, it should be done in hardware.
10-50mA would suddenly turn into 50-250mA. So, "x"mA is kind of a misleading ter
No, I meant 10-50mA at 5v. The PXA255 is absolutely shockingly efficient. It really is better than pretty much any other low-power-high-perfomance CPU. I know this from experience - as in trying it on an actual board and sticking it on an accurate meter :)
The reason he's got 200mA is really most likely because of the combination of incorrect setups (no low power SDRAM mode) and bad components selection. 200mA is way, way off anything I've ever seen on any platform comparable to the gumstix one.
I'm a little surprised by that figure, but it's probably either because it doesn't use low power flash and SDRAM parts, or simply because it's not configured correctly. For example, there's a well hidden bit in the SDRAM controller on a PXA255 which enables a low power mode (it goes unclocked except for refresh when idle), which shaves off a ton of power.
I would expect something more like 10-50mA at 5v with a PXA255, flash and SDRAM.
They are constantly in a trial. The broadband-over-powerline lobby are attemping a "proof by exhaustive irrelevance" much like the UWB lobby. It's a inherently flawed technology - no, wait that's far too polite for these idiots - it's an inherently incredibly stupid idea that a few people with lots of money and lots of influence are attempting to push through to consumers.
None of these trials have worked. Nearly every trial has ended abruptly because either they interfered with TV reception next door, or blocked something more essential like police radio. All have proved it won't work. The only reason this is still being proposed is because a few people have a lot of money invested in it. There is an overwhelming amount of evidence already accumulated to show that it's as flawed as the theory it works by.
The thing which irritates me most is that despite every trial showing that it will definitely interfere with other services, they will probably be allowed to roll out. Just like UWB. Probably they'll just keep having trials until we get bored and give in.
Unlimited storage (on the server PC). Some folks have more than 20GB of music (legitimately purchased even)
The Rio Receiver is exactly the same class of product as the Squeezebox - it's a diskless thin client that streams music stored on a server. The only space limit is the size of the hard disk(s) in your PC.
Ability to stream MP3s to multiple Squeezeboxes from a single server, centralizing your music collection.
Multiple Rio Receivers can stream from a single server. You're pretty much limited only by ethernet bandwidth, which is pretty huge compared to the 16KB/sec or so MP3 takes up. If you do stream many (like, 16+) then you might end up chewing a bit of your PC's CPU time up. We had a setup in a hotel in Ibiza supplying every room that way.
The only thing which I think sets aside the Squeezebox is the built in 802.11b, because quite frankly most people end up sticking an ethernet-to-802.11 dongle on their Rio Receivers.
That's just it - the broadband-over-power-lines brigade have been attempting a "proof by exhaustive irrelevance". They hold a new trial every few months in another remote place and end up with the same results: it usually interferes with TV reception, and in some cases interferes with an emergency band so badly they abort the trial.
This is very much like the UWB brigade, who are attempting to circumvent normal acceptance procedures by building themselves up for a massive failure - thereby claiming that it's all unfair and would destroy their business. At the end of the day they're both just inherently flawed technologies pushed forward by people who only really care about the potential returns.
An unfair deal is still an unfair deal even if you accept it. The logic of "people buy it therefore it's ok" is unfortunately the same logic people are using to say that DRM wrapped online music sales works. BBspot has some fun things to say about that. At the end of the day iTunes is still giving you less than you deserve, and there is absolutely no reason to be an apologist for the monumental amount of screwing that's going on here.
NO! One major factor in embedded systems is cost - memory and CPU are always sacrificed first. I suggest that MS should learn to accept that they cannot write bloated operating systems and expect embedded systems to bend over a barrel for them.
Already handheld devices are at the performance level of desktops of the early-to-mid 1990s, albeit without rotating mass storage. But SD-Flash is in the multi-gigabyte range, which is more storage than we had on desktops in those days.
Disproof:
- Multi-gigabyte SD cards are hideously expensive.
- The most you should expect from a PDA these days is about 400MHz of XScale, 32MB SDRAM, and 256MB flash. That's state-of-the-art.
- The current state-of-the-art PDA will NOT run (acceptably) the current state-of-the-art Microsoft desktop OS.
- If you put a faster processor in, more RAM, and larger flash, you would have a hideously expensive PDA that sucked for battery life.
An interesting thing is that while the power of portable devices has increased about 10x in recent years - the efficiency hasn't got better by more than about 2-3x. That's yet another thing to add to the list of "things people don't get about embedded systems": inefficient code leads to short battery life. Anyone who's programming an embedded system and doesn't understand that needs to be shot. Repeatedly.MS still don't seem to understand the fundamental problems faced with making embedded applications. You can't just "get rid of a bit of functionality" - you either should have started with slimness in mind, or you've got to redesign a lot of code. I've worked on many a platform where some piece of Microsoft code had to be integrated. Usually it ends up being the make-or-break of whether everything fits or not. Usually it's a tight squeeze. Usually we need to ditch some of our functionality to fit it :)
Quite frankly Microsoft are stuck with the misfortune of designing only for x86 PC desktops. You end up assuming memory and CPU are infinite - both of which are in short supply in embedded systems. A laughably short supply in some cases: how about 64KB of RAM and 30MHz to fit an API into? How about not having a dynamic memory allocator? Yeah, no mallocs allowed! How about if your endian isn't little, your chars aren't signed, your shorts aren't short, and your ints won't work unaligned? Practically every piece of "portable" code I've used from a commercial entity completely ignored these problems.
The thing is - you can have your cake and eat it! It is entirely possibly to write compact APIs which don't lose anything when used on desktop system. They usually benefit from a thoughtful design. I hate to use Linux as an example (especially in the same context as Microsoft), but it really is a good example of thoughtful API design - especially in the sense that "x86 != world". It's not in the same ball-park as some embedded OS's, but it's compact enough to use in devices with around 1MB of RAM (with a bit of tweaking, granted). A much better example is Redhat eCos, which is great for anything from an MMU-less device with less than 100KB, to a full blown "desktop class" PC running a single application.
The thing which makes me laugh most from your post...
SQL CE, Embedded Visual Basic or XML
Yep - you couldn't even fit the parser for any of those in a large class of embedded systems, let alone the back end :)
It's no wonder Microsoft never managed to break into the mobile phone market... they were too busy integrating buzzwords.
You're right, Motorola still make their own chips, just with ARM cores instead of their own. I suppose I could more accurately say that I find it funny Motorola favours other core designs to their own.
About the only core they have which is both high performance and low power is the 56k, which they use in that i250. But 56k is a pain to program and extremely inefficient at anything except DSP.
The XScale has an order of magnitude better performance per watt than PPC - we're talking fractions of a watt flat out at 400MHz (see the spec sheet). Also note that this is an Intel/DEC improved ARM core, and isn't x86 based in the slightest.
This particular XScale also has a large wedge of on-chip flash and a bunch of handy peripherals for mobile devices - which is unsurprising seeing as that's what it seems to have been made for.
It is funny that Motorola favour other manufacturer's chips for embedded low power devices, but the reason is simple: none of their stuff fits the bill. Even their own mobile phones seem to use ARM these days.
There is nothing Linux does fundamentally different to Windows with CDROM drives. Windows makes no attempt at spinning at less than maximum speed. In fact, a large portion of the drives I've tested don't even support speed setting. So, there is no reason why Linux would "shorten dramatically [your] cdrom lifecycle". I suspect you added that just to troll a bit.
I've personally had the displeasure of implementing CD ripping software for an embedded device, and dealing with the multitude of buggy-as-hell CDROM drives. It's a nightmare - every single drive I tested ended up requiring at least one workaround for a firmware bug. It's shocking how little testing has obviously gone into these devices. CDROM drives suck, basically.
Also something you don't understand is that CDROM drives are inherently not made just for windows. They all run (these days) to either the ATAPI or SCSI MMC spec (which are pretty much the same thing). There's nothing in those documents which refers to Windows, or Linux for that matter. CDROM drives are open hardware, in a sense.
Where it all goes wrong (and where it's gone wrong in LG's case) is when a manufacturer only tests their drive against one system, rather than against the spec, or multiple systems. That not only ensures that it's largely untested, but it also pisses off the software developers of the system they test against - they're stuck with not touching "untested" commands from then on! You end up with stupid whitelists or blacklists or just never supporting any enhanced feature set, for fear of destroying drives, or otherwise malfunctioning.
I'm actually not shocked that LG have the incompetence to create a firmware which can destroy itself. It's normally a very, very hard thing to do because flash chips have a "write protect" you normally turn on first thing, so software bugs can't accidentally kill it. But given the very obvious lack of technical skill of the people involved in writing CDROM drive firmware these days, nothing surprises me.
I can foresee killing somebody by cramming 20 twinkies down their throat. Should we hold the manufacturer reponsible?
Really, I was almost tempted to not bother sending this because it's so obvious. Quite frankly there are too many people using that weak argument to make lots of money out of frivolous lawsuits. That's basically the reasoning being used to sue games developers, i.e GTA3.
No, I live outside the US and I'm constantly baffled by peoples' willingness to keep using confusing units. That's the point - powers of 10 are confusing and pretty useless when talking about storage which more naturally works in powers of 2. The "new units" are an unnecessary and ugly hack by SI who have absolutely no right to talk about computer standards. The most telling thing is that they didn't even bother with units you can pronounce.
What irritates me most of all is the viral history rewriting that hard disk manufacturers started. There was never any confusion over what a kilobyte, megabyte or gigabyte was until some bright spark decided they could cheaply one-up on their competition just by redefining the units. And slowly people started buying the argument that "everyone knows M is a million, you're just wrong if you think otherwise." Suddenly people (including you apparently) have the nerve to claim some kind of superior knowledge on this matter. You've been lied to, cheated and now you're repeating the same lie to everyone else.
Go back in time a bit. Everybody knows that when you talk about storage or processors a byte is 8 bits, a kilobyte is 1024 bytes, a megabyte is 1024 kilobytes, a gigabyte is 1024 megabytes, etc. Everybody knows that when you talk about communications a bit is the basic unit of transfer, a kilobit is 1000 bits, a megabit is 1000 kilobits, and gigabit is 1000 megabits, etc. Whenever you talk about both, you indicate which you mean. Nobody is confused, and everyone uses the same standard. I find it insulting that anyone can claim to me that history is other than I remember.
Hard disk and flash manufacturers have a point that their storage is no longer based on powers of 2. But that's all I'll give them. It's obvious they're trying to be deceptive with their numbers. Here's an example - flash manufacturers can pick any old number of bytes to cram into their flash device, but they decide to pick 64 million. Why 64 million? It's obvious - it implies a power of 2. They could have picked any number, but powers of 2 imply you're getting slightly more than 64 million.
I wouldn't be surprised if a lot of focus in the lawsuit is on the transition between when manufacturers all used powers of 2, to the gradual shift to powers of 10, and why some still use powers of 2 for the major part of the size, when they could have picked any size.
This is history rewriting. Everybody's been using powers-of-2 when it comes to KB, MB, GB, etc for decades. SI come along thinking there's some confusion - which there isn't, it's only the hard drive manufacturers who are causing confusion - and slap down a horrible "standard".
Let me guess, you've only been using computers for a past 5 years?
The trick is they have is a single issue RISC core (1 instruction per clock) running in parallel with a 4 issue VLIW DSP core (4 instructions per clock). Assuming it's all running at peak rate (which it hopefully will be for the majority of time) that's about 60 MIPS of processing going on there for a 64kbit Vorbis stream. Compare that to an ARM7TDMI (which a lot of players are based on), which requires (ball park) 30-50MHz for the same stream. The figure they state of 74MHz is nonsense - that's the general class of processor you require, not the actual MHz. You'll find higher bit rates requiring most of that 74MHz, though.
If they can come up with a real piece of hardware or a simulation that says it takes less than 100-200mW in an actual system, then I'll be impressed. That's about how much your average MP3 player takes. (Power = Battery mAh * Battery Voltage / Time in hours, work out how much yours takes). Just having a low clock speed is as incomplete a power consumption picture as Intel's use of high clock speeds alone is to performance.
That's the thing - it's not free depending on your definition. By my own definition, you're giving them valuable information, and they get to keep it and use it as they will, including spamming if they feel like it (or spam from any company which buys them out, they sell it to if they're feeling bankrupt, etc). It's practically misadvertising of a service, but it's accepted now, so everyone gets away with it.
If it really were free, why would you need to register in the first place?
Since when is any unsolicited email legitimate? This is what I find most disgusting about the proposal - it diverts away from the real issue. Spam is just plain wrong.
Those trying to claim the high road of "we are just marketers" will have to comply and get filtered, or risk jail. Those that don't are branded as law breakers. This law could put every American based spammer out of buisness eventually.
How about this - they all comply and tag everything with "ADV:". And because it's all "legitimate" now, they'll send more spam, to more people, and all the other businesses who previously considered spam wrong will also join in. We'll soon have the vast majority of email traffic as spam, as opposed to the slight majority we currently have at some ISPs. Everyone who knows how to filter will still be receiving all that bandwidth, and all the fibres and routers in the world will still be passing them on. I currently receive up to 50 megabytes of spam a month - and that's a single IP on a 512kbit DSL account. So I'm supposed to just put up with the bulk of spam and filter stuff out at my end?
Quite frankly either the anti-spam people behind this proposal don't understand the issues, or the spam people behind this proposal know them very well. Perhaps both.
Don't believe the hype - it's just another opt-out proposal. Opt-out is a flawed scheme only ever pushed by people who are naive to both the technical and practical issues. It's an enormous waste of resources (bandwidth, energy, people's time), and at the end of the day it's only partially solved just one of the issues at the expense of ensuring that we'll never solve any of the others. This really is a case of "the slippery slope exists and it will happen".
Like all the other opt-out schemes, all you have to do is opt-out of those 50 million emails you're about to receive. Legitimately. Enjoy your day.
It is, dare I say, ironic that Microsoft hasn't engaged in that activity, but there are plenty of other big companies that have and still are trying to shut down open source projects using patent laws. I'm not even going to bother quoting any, there's so many instances.
The claim that "with patent law allowed, the floodgates would be opened and Linux distributors swamped and bankrupted by court claims - with Microsoft leading the charge." is baseless.
You neatly chopped off the start of that quote, "The fear is that with patent law allowed...". They're not claiming anything, they're just giving a likely scenario. The aggressive anti-Linux retoric of the heads of Microsoft and their dubious involvement in the SCO vs Linux nonsense is enough to give weight to that outcome being likely.
Software is relatively cheap. I would raise an eyebrow at any company which said it has invested millions of dollars in researching a new software "technology". It's not like you have to buy lasers, or break apart pieces of DNA to aid that research.
This is all irrelevant anyway. The real theft in my opinion is the patent system. I find it offensive that I can independently come up with a software idea only to find that somebody has "done it first", and therefore they own all rights to the use of it. This isn't even a rare occurrance - there are an enormous number of trivial and even complex software patents out there which any number of people could have come up with independently, with or without research. I personally have thought up countless algorithms indendently which all turned out to have been already patented (including natural order spreadsheet recalculation, parts of LZW, some specifics of voxel rendering). There are an enormous number of people out there who can and probably have also. It is absolutely fucking ridiculous that my efforts at furthering the art are in fact being constantly restricted by the very process that was setup to encourage it.
Even worse, the original inventor will go out of business because the thiefs don't have the development expenses, so that they can offer the products much more cheaply. And patents are there to prevent such stuff.
The software patent system has always been and still is used solely for the purposes of protecting against other people invoking patent law. This is recursive, and boils down to being pointless. Products which are protected by patents inevitably end up being more expensive to the consumer, simply because the company has been granted a monopoly. Worse, a company granted a patent doesn't even have to sell anything. They can just sit back and collect taxes from anyone crossing over their piece of land grab.
Many people fear that stuff like Amazon's one-click patent and other trivial patents will come out. But I don't think this is a real problem. Such trivial patents are cause by a fucked legal system.
I don't think the triviality of a patent is relevant at all. I don't think I can identify any piece of software which at the very least hundreds of other developers around the world could also have come up with. This does lend a certain amount of uniqueness to the situation with software patents. The legal system problems are not the cause here, they're the symptoms of the wrong model and wrong premise being used to solve a problem that doesn't exist.
Why the choice between these two absurd cases? Why does it logically follow that cheap products don't work on 10 year old players, or that ones which can be pirated are more expensive?
It doesn't logically follow, though many in the industry would rather it were the case. Making a product require DRM uses up lots of valuable developer time, and tends to increase your hardware requirements just to handle encryption and secure handling of keys and other crap. It just makes it more expensive at the end of the day, and only serves to piss off your customers.
At the moment any project I release ends up GPL simply because it's the most restrictive (genuine) public license. I should really use BSD-with-advertising because I don't actually mind businesses using my code, and it gives me a free advert too.
I have an iPod.. I know the cpus they use in these are pretty beefy compared to the other mp3 players -- does this one have the raw power to do tremor?
iPods are basically a dual core ARM7TDMI which is fast enough to decode about 2-3 MP3 streams simultaneously, but I'd guess they're clocked low enough to handle just the one and save a bit of battery. Vorbis (specifically Tremor) has roughly the same CPU requirement as MP3 (slightly more), but uses a lot more RAM. All that would mean is it'll eat battery quicker.
I'd say that so long as you have about 50 MIPS (at arithmetic) and 300KB of RAM, you should be able to fit it into that processor. Anything less and it should still fit but you'd have some work to do or maybe some quality tradeoffs. That means pretty much any of the MP3 players out there with general purpose CPUs or DSPs doing the decoding should handle it.
Unfortunately Tremor isn't a one-size-fits-all. It's got nasty things like dynamic memory allocation all over the shop and still a rather large memory overhead. Actually, to be 100% compliant with the Vorbis 1.0 spec it's rather difficult to turn out a fast and small implementation (I've been trying).
At the moment I'm working on getting my own implementation working with an extremely small RAM overhead. It's by no means trivial getting it working on the DSPs you find in most MP3 players, and almost none of the source code to Tremor could be successfully ported to them either. I don't expect any of the source code I'm writing for my own implementation to be used as anything but a reference for writing a version to run on DSPs.
Of course, it would have been much more difficult even starting to write my own implementation were it not for freely available specs.