It is very much a broken design, and it certainly isn't common. Even the ARM720 (which they could have used) is 0 wait state.
true, it's uncommon for arm processors, which are usually feature-packed compared to other embedded processors. have a look at some of the stripped down mips chips available, and most DSPs, and you'll see it. whether it was done intentionally by portalplayer, or a silicon bug, i have no idea.
Vorbis runs easily real time on most ARM720 based CPUs out of SDRAM
i'm not sure what your idea of "easily" is, but in my experience, the low accuracy vorbis decoder eats up almost all available cycles on a 70 mhz arm7 when playing high-bitrate files. this is about twice that of mp3 or wma (although these have been optimized for that chip).
So unless you're just another ignorant Apple fanboy, refute the guy's arguments.
okay, i will refute the guy's arguments. i am an embedded systems developer, and often deal with swapping code in from dram/flash to sram for quick execution just such as this. the guy's arguments are, well...
The 5002 has a "broken" cache (1 wait state per access for program or data, meaning you effectively have half the effective clock rate when running code from external memory). This means that running code that doesn't fit in the internal 96kbyte SRAM of the player is very inefficient, both in terms of CPU cycles and power. MP3 and AAC just about squeeze into the internal memory (one at a time, obviously!), but anything that didn't would result in a big power hit - my guess is 30-40%+. This would be a bad user experience, considering the already short gen3 battery life.
first, the cache is not broken. this is a common design limitation of embedded processors. running code or accessing data from external ram can be VERY slow (1 cycle delay is pretty good). however, his argument is bullshit. the support code for the codec is usually run from dram (like the "open a file, parse a bitstream part"). the core decoder loop, on the other hand, is loaded into sram for fast execution (code and data). if the ogg vorbis decoder can be squeezed into whatever apple has left of the 96kb depends mostly on the efficiency of apple's memory allocation. but i have no doubt that they could do it (they may need to optimize some tables out by computing them at runtime, and other such tricks).
having said that... adding a complex codec into such a system such as the ipod firmware is a major pain in the ass. they may want to enable vorbis support, but it is a large amount of work, and probably hard for apple engineers to justify. if someone could find a good excuse for apple marketing to justify it, i'm sure engineering could figure it out.
Who is this network and server you speak of? I really can't sort out what you are trying to say here.
i decide to attack slashdot.org. i log into your network and become a supernode. now i make about a billion file requests, all to the ip of slashdot.org. slashdot.org is now eating spoofed udp packets, and has no way to indicate to the well-meaning network clients to stop sending these files (since it didn't request them and knows nothing about this filesharing network). now your network is my own personal floodnet.
Or in OpenSSL itself, which I hardly think is their fault, if it was that buggy noone would use it.
you're new to openssl, right? if you know of another library that replaces it, i would love to switch to it. the reason everyone uses it is because there is no substitute.
actually, there is something new here: i, as an embedded developer, will never take green hills software seriously again. when considering an embedded rtos, my choice has just become easier. thanks, green hills, for letting me know that your products can't compete on features, and you must resort to fud. i'll be sure to let my coworkers know.
This doesn't explain why you'd buy it with a brand new Dell though
on the contrary, it does explain it.
1) and most obvious, freedos is SMALL, and takes them about a second to image it onto every drive. big time savings in their assembly pipeline.
2) dell assumes that you're probably going to install windows. if linux was installed, the hdd would probably be ext3 or other linux fs, and you would need to spend your time reformatting (yes, i know you can run linux on fat, but then you'd be bitching about that). with freedos, the the hdd is already formatted and ready for you to install win9x. if you're going to install an nt series of windows, you would have had to reformat anyway (since no other os runs on ntfs).
3) if you're installing linux, you're probably smart enough to deal with drive partitions and formatting. for a windows install, it's less likely.
i dunno about you guys (and girls), but i personally cannot stand any more corporate-programmed media. for the same reason i don't watch tv anymore, i also listen to shoutcast and my own mp3's instead of commercial radio.
so, how do we get that in the car? i'm drooling over the phatnoise car audio system. _________________________________________ _________
Do You Yahoo!?
and where exactly are you gonna store the 10 terabytes of object files that get generated when you try to compile this puppy?
pchan-
no one can be open minded and hold beliefs different than your own.
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. ___________________________________________ _______
Do You Yahoo!?
this could be done within the existing system
on
Pirate DNS?
·
· Score: 2
why a different port? why different resolvers? why not use the existing dns system (including the root servers)?
say i set up dns.org (i'm sure that's taken, but let's pretend). on top of that, i build com.dns.org, net.dns.org, sex.dns.org, sucks.dns.org, and so fourth.
now, if you all change your dns search order to look at the.dns.org network first, you can all resolve company.com (really company.com.dns.org). if you want the real "company.com" just try to resolve company.com. (trailing dot).
and the best part: this is entirely outside nsi's jurisdiction. they have no authority on subdomains, and neither do the courts.
It is very much a broken design, and it certainly isn't common. Even the ARM720 (which they could have used) is 0 wait state.
true, it's uncommon for arm processors, which are usually feature-packed compared to other embedded processors. have a look at some of the stripped down mips chips available, and most DSPs, and you'll see it. whether it was done intentionally by portalplayer, or a silicon bug, i have no idea.
Vorbis runs easily real time on most ARM720 based CPUs out of SDRAM
i'm not sure what your idea of "easily" is, but in my experience, the low accuracy vorbis decoder eats up almost all available cycles on a 70 mhz arm7 when playing high-bitrate files. this is about twice that of mp3 or wma (although these have been optimized for that chip).
okay, i will refute the guy's arguments. i am an embedded systems developer, and often deal with swapping code in from dram/flash to sram for quick execution just such as this. the guy's arguments are, well...
first, the cache is not broken. this is a common design limitation of embedded processors. running code or accessing data from external ram can be VERY slow (1 cycle delay is pretty good). however, his argument is bullshit. the support code for the codec is usually run from dram (like the "open a file, parse a bitstream part"). the core decoder loop, on the other hand, is loaded into sram for fast execution (code and data). if the ogg vorbis decoder can be squeezed into whatever apple has left of the 96kb depends mostly on the efficiency of apple's memory allocation. but i have no doubt that they could do it (they may need to optimize some tables out by computing them at runtime, and other such tricks).
having said that... adding a complex codec into such a system such as the ipod firmware is a major pain in the ass. they may want to enable vorbis support, but it is a large amount of work, and probably hard for apple engineers to justify. if someone could find a good excuse for apple marketing to justify it, i'm sure engineering could figure it out.
Who is this network and server you speak of? I really can't sort out what you are trying to say here.
i decide to attack slashdot.org. i log into your network and become a supernode. now i make about a billion file requests, all to the ip of slashdot.org. slashdot.org is now eating spoofed udp packets, and has no way to indicate to the well-meaning network clients to stop sending these files (since it didn't request them and knows nothing about this filesharing network). now your network is my own personal floodnet.
You can't use 1 word for two different meanings in science.
what about "splice"? it has two (opposite) meanings.
Or in OpenSSL itself, which I hardly think is their fault, if it was that buggy noone would use it.
you're new to openssl, right? if you know of another library that replaces it, i would love to switch to it. the reason everyone uses it is because there is no substitute.
actually, there is something new here:
i, as an embedded developer, will never take green hills software seriously again. when considering an embedded rtos, my choice has just become easier. thanks, green hills, for letting me know that your products can't compete on features, and you must resort to fud. i'll be sure to let my coworkers know.
i look forward to seeing the documentation for these devices, so they can be fully supported by [insert any os besides windows].
oh wait, did you say nvidia? nevermind. buggy binary drivers, no support for advanced features, drm, and linux only (no bsd allowed).
This doesn't explain why you'd buy it with a brand new Dell though
on the contrary, it does explain it.
1) and most obvious, freedos is SMALL, and takes them about a second to image it onto every drive. big time savings in their assembly pipeline.
2) dell assumes that you're probably going to install windows. if linux was installed, the hdd would probably be ext3 or other linux fs, and you would need to spend your time reformatting (yes, i know you can run linux on fat, but then you'd be bitching about that). with freedos, the the hdd is already formatted and ready for you to install win9x. if you're going to install an nt series of windows, you would have had to reformat anyway (since no other os runs on ntfs).
3) if you're installing linux, you're probably smart enough to deal with drive partitions and formatting. for a windows install, it's less likely.
But does it support OGG?
sooner than you think.
the phatbox and kenwood music keg already support ogg.
volkswagen and audi sell these as dealer installed options. and they are compatible with a wide range of car stereos.
here's how to play ogg files on it!
Hey... I still like Ranma 1/2
i dunno about you guys (and girls), but i personally cannot stand any more corporate-programmed media. for the same reason i don't watch tv anymore, i also listen to shoutcast and my own mp3's instead of commercial radio.
so, how do we get that in the car? i'm drooling over the phatnoise car audio system._ _________
________________________________________
Do You Yahoo!?
and where exactly are you gonna store the 10 terabytes of object files that get generated when you try to compile this puppy?
pchan-_ _ _______
no one can be open minded and hold beliefs different than your own.
_________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
__________________________________________
Do You Yahoo!?
why a different port?
.dns.org network first, you can all resolve company.com (really company.com.dns.org).
why different resolvers?
why not use the existing dns system (including the root servers)?
say i set up dns.org (i'm sure that's taken, but let's pretend). on top of that, i build com.dns.org, net.dns.org, sex.dns.org, sucks.dns.org, and so fourth.
now, if you all change your dns search order to look at the
if you want the real "company.com" just try to resolve company.com. (trailing dot).
and the best part: this is entirely outside nsi's jurisdiction. they have no authority on subdomains, and neither do the courts.
my 2bits,
pchan
sublimate the masses!