I'm a little dismayed that O3D had to introduce a fresh new API, and a high level one at that. This is right when everyone else is moving to simpler, smaller APIs - the big example being OpenGL ES 2. A handy example, because that's basically what WebGL is. I think O3D would have been better positioned as working alongside WebGL as a toolkit for higher level features, in much the same way GLU/GLUT work. As it stands, O3D requires a plugin download and install (even if it works today I still need to download and install it today), requires a learning another API that isn't a neutral standard (even if it is Google) and targets what looks like a very small market.
A huge advantage of WebGL is again that it's just OpenGL ES 2, but more specifically because this extends it to devices that aren't x86 desktops. Most of the latest "feature" handheld devices (including iPhone) support OpenGL ES 2 either natively or with some CPU-assist (the distinction is muddy on embedded devices anyway!) So they can support it today. Will O3D be as easy to cross-compile for ARM, bearing in mind it also bundles a V8 engine?
What the article actually shows is that all browsers, apart from Safari 4, are within a few percent of each other in energy usage. Even Safari isn't significantly far behind - 10% isn't going to make you choose another browser over it, considering you probably picked Safari for some other important feature in the first place.
So the real conclusions are not drawn in the article or in any comments I see here:
None of the major desktop browsers focus on energy efficiency.
There is too small a difference between browsers to choose one above another for power usage concerns.
You're likely seeing the strong correlation between low CPU usage and low power usage, but again - none of them really focus on power. There's a lot of tricks you can do to make that huge leap (hint: network/disk usage and fancy offloaded graphics are low CPU but huge power users). None do them. I suspect Safari is chewing more power by having those fancy Apple-style transitions and widgets being rendered, which if you can turn off, will yield a runtime similar to the other browsers.
This is where the real battle will occur: when long battery life form factors start to become very popular, and browser authors realise that efficiency is worth just as much as features.
There are lots of annoying little things with ARM. In the area of the instruction set itself, there is the whole issue of what happens when you load a 32-bit word that is unaligned. That depends on the mode you are in, but it usually does some crazy rotation, but that is actually useful to make use of. This also leads to strange alignment relative to everything else out there if you want the same code to be able to fill a structure say. Then there is the whole loading of constants using LDR which is not a real instruction, the assembler does what ever craziness it can manage to get a constant. If your code is PIC that basically means loading from memory, if it is noPIC then it might do crazy pc relative stuff. Oh and what about thumb mode, very non-orthogonal.
It's not ARM being different to everything else, it's x86 being different to everything else. Unaligned loads are unsupported by most architectures and for good reason - they complicate the pipeline. This is something you normally wouldn't encounter when hand-coding assembly, or if you would at least be expected to know about if you were. It's not a hard problem to work around, either. How is thumb mode very non-orthogonal? Are you looking at a different processor?
The "crazy constant loading" is a nice feature. When you go "ldr r0, =0x12345678" what you're actually telling the assembler to do is "ldr r0, [pc, #some_offset]" and putting that constant within 4KB of the current location. It's a short-hand you would, again, be expected to know if you're coding ARM assembly. It's not like it's doing something totally unexpected. The only funky one is "adr r0, some_location" where 'adr' translates into one or more instructions to load a pc-relative address, usually "add r0, pc, #offset". Again, hardly a surprising result, and one of very few examples of additional short-hand syntax.
Then ARM has the whole issues of all the differences. When they have TLBs and caches they tend to be alien (DACR ASID and PID) though the newest ARM cores are becoming more conventional. The same thing is there with regards to floating point. There have been lots of various ways that it was done.
These are system programming issues. You should see what x86 gets up to these days. Only WinCE 5 uses most of the weirder features (which Microsoft wanted adding for their own fucked up idea on how to do an OS) and nobody else does. Userland programmers do not see these issues. Floating point? Yes, there's many variants. The reason? It's not standard-issue on most ARMs, and if you're hand-coding floating point, then fucking hell you're probably hand-coding for an exact variant, so no surprises what you find.
Smaller batteries also means smaller devices, a fact that many manufacturers have been taking advantage of for a long time. For example, almost every mobile phone out there is ARM powered.
All instruction sets are like that. RISC or not makes no difference.
The key difference with ARM is it's almost beautiful to look at: it's (mostly) orthogonal, has a regular but very powerful syntax, and it's easy to see the data dependencies. I'd say hand-coding ARM assembly is easier than any other processor I've done it on (and that's lots).
I agree with his friend, and would go further to say anyone who's serious about programming should learn at least one assembly syntax to know what's going on under the hood, and ARM is the best to try.
You can decode H.264, MPEG4, WMV and most similar codecs at QVGA (320x240) in about 300MHz of ARM-9, purely in software. That's well within the reach of most mid and high-end smartphones. This isn't speculation, I've done the above.
It doesn't matter if there's no commodity hardware support for a codec - it'll run just fine in software anyway.
Cost is only half the issue here. Power consumption is the other half. Even the current Atom offerings are absurdly more power hungry than your average system-on-chip ARM, and by absurdly I mean 100-1000 times more at "near-idle" tasks.
I think you also need to factor in that most SoC ARM solutions are extremely integrated. I would be very surprised if you can find an Atom design that's cheaper.
With any luck one of the major manufacturers will get over their fears and just ship a modern ARM Linux based netbook and settle this matter at last.
I was so concerned about the lack of development of Vorbis I decided to write my own Vorbis codec from scratch. Well, mostly it was an academic exercise many years ago, but since then I've realised that it's a genuinely useful project. It validated the specification, and showed up many places where the design could be improved.
It still needs a lot more work, but it currently decodes all Vorbis streams correctly at reasonable speed. Well, it's about half the speed of the official codec, but I haven't concentrated much on speed and there's some really obvious places where there are large improvements to be had easily.
If anyone's interested, it's hosted on Google Code:
Blaming Microsoft for the fact that Apple doesn't support MTP is ridiculous. Apple locked down iTunes so that you can't really use it with other players, and they tried to lock down the iPod so that you can't use it with other music management applications.
You missed my point. They specified that you can only use MTP and no other protocol. You were not allowed to have a dual-protocol device, which was perfectly possible. Of course, they eventually settled for allowing this, but not before the damage was done - vendors implemented MTP instead of the ubiquitous Mass Storage (MSC) and when you've got limited resources to do things, you settle for one protocol. So a mass of MTP devices appeared, which neatly didn't work on Mac.
And, of course, just to let us know they're Microsoft, MTP wasn't supported unless you had Windows Media player 9 installed. And of course, WMP9 wasn't supported unless you had Windows XP installed. Very neat.
I was there when this all happened and it was as obvious as a 100ft tall pink elephant. They got away with all this crap simply because the US and EU were busy with the bigger fish of browsers, openness, protocol compatibility and all the other monopolistic practices. I don't see why you should give them the benefit of the doubt here - there's decades and hundreds of examples of Microsoft doing the same thing over and over. This is no different.
As for "screwing the entire non-Apple MP3 market", I think you give Microsoft too much credit; Microsoft has had virtually no impact either way. If you want an MP3 player, there are plenty of choices that cost almost nothing.
You are wrong. If you are a non-Apple MP3 manufacturer you must go with PlaysForSure. It's a tick-box. The mass market wants tick boxes, and customers wanted P4S. If you didn't have P4S, you didn't sell. It's sad and believe me it's true. Microsoft screwed the market by crippling all the non-Apple vendors with a shitty product.
MP3 players are dead anyway; like PDAs, they are just becoming part of phones.
That is patently untrue. There are so many factors which will ensure they'll be around for years. Form factor is one. Price is a fucking obvious one too.
Also notice that the phones which list music playback as a strength have all gone with their own implementations. Notice how big the companies are that had the guts to do it: e.g Nokia. Sadly we're left with a bunch of walled-garden solutions, iTunes included.
That means Microsoft have not only managed to damage to MP3 market to the extent that Apple "won", but now they're dropping out too. If I weren't convinced they were just short-term reactionary fools I would believe they had it planned all along.
What am I going on about? Well, you see, back in the days just after iPod, Microsoft introduced this thing called PlaysForSure. It was a system to provide a variety of DRM options - single track purchase, promotion with timeout, monthly fee all-you-can-eat, limited play count, and so on. This in itself would have provided a superset of the functionality iTunes provided.
(For the record, where I stand: DRM must die. Three times. Horribly. Preferably acid bath.)
Sounds great, at least from a technical and business standpoint, right? Unfortunately, just to remind us that they're Microsoft, in order to get a PlaysForSure badge on your product, and to be allowed to use the system whatsoever, you have to pass certain certification processes. That includes making sure you have a good startup time, good inter-track delay time, fast database indexing, and so on.
Still sounds great? Aha, but just to remind us they're Microsoft, they're the people that design the protocol, and they make damn sure it's near-impossible to actually implement a good player from it. The database updates and queries are so horribly defined you'd struggle to get good performance out of a proper SQL-like database running on a PC, let alone a tiny little device with 1MB RAM. The requirement to support PlaysForSure means you must use MTP protocol, which is another botched abortion of a protocol. It also requires that if you use MTP you cannot use Mass Storage, further annoying your customers and very neatly if "accidentally" meaning they don't work on Macs. And then there's the encryption itself which is so horribly over-the-top and poorly implemented (you MUST use Microsoft's libraries) that it badly impacts player performance and its battery life.
So Microsoft screw the entire non-Apple MP3 market for a couple of years. Then they bring out their own PlaysForSure player. Except it's not PlaysForSure. You can imagine the language used where I worked (and presumably other companies). They decided that it was too hard to implement their own spec, so they make a player which doesn't comply to it. It's not even in the set at all - it's totally incompatible.
After an electronics-generation of fucking up the non-Apple MP3 market, then screwing up their own solution, and now after (very likely) ditching Zune, they've basically done almost exactly the right set of steps to put Apple into a lead that will be hard to make a dent into.
I stick with my decade old opinion that you don't partner with Microsoft - you watch your back.
I bet they've managed to accidentally revoke or break its certificates. Microsoft "accidentally" did that to an MP3 player I worked on in the past (Rio Carbon).
The strange thing is that I've written drivers for many EEPROMs, and they all have a few hoops you have to jump through to enable writing. It's not something you can just accidentally do.
Usually it's something like 'Read address 0xaaaa then 0xdddd then write some magic byte then the address then write 128 bytes'.
Perhaps Intel thought they didn't need all that magic?
I seriously doubt they would try to enter the x86 market. Perhaps it's just this that people are mistaking it for. That's frankly a bigger market than anything x86 based.
I think hard drive manufacturers would have shockingly high return rates if removing power during a write had a high chance of destroying the entire drive.
It's not like it's an unlikely scenario, and they HAVE thought of it. Perhaps you can shed light on which manufacturer you used so we can all avoid buying their defective designs? All the drives I've used in making various consumer electronic devices have data that says they handle it fine. Perhaps you bought an IMB or Hatichi drive?
I don't think this has been true since... maybe 8-10 years now? Definitely since MR drives came on the market (ages ago).
Modern drives have:
A capacitor that stores enough charge to "emergency park" the heads.
Low voltage detection that kicks in, disables the head, and dumps the capacitor into the seek coil.
It does NOT go writing crap all over whatever's between your data and the parked position, unless the drive is a defective design. The emergency park is a fairly brutal affair, and you'll typically see the datasheet list a maximum number that's notably lower than the max power cycles.
It's also essential these days because:
The head should (of course) never touch the platter.
The drive can't actually spin up if the head is resting on the platter.
So the drive is designed with the assumption the head NEVER touches the platter in its lifetime.
Normally that holds true. I've seen some drives (1.0" and 1.8" miniature ones) which suffered from head-on-platter but that was due to misdesign in the power supply feeding it (e.g voltage rails going slightly negative, draining the cap early).
But anyway, the worst you'll get with the power going out is a partially written sector, which will then be marked bad, probably permanently. Or maybe a bunch of sectors. Or maybe bad in a different order to what the OS sent due due to caching.
If you had a drive and/or RAID fail due to power outage, you should get a refund. You might lose a tiny amount of data, not the whole lot.
Re:The decoder uses a Schmitt trigger
on
1200-Baud Archeology
·
· Score: 2, Insightful
That's nice but,
Which is why the decoder uses two comparators: one at 32768/DIVISOR and one at -32768/DIVISOR. In order to count a pair of transitions, the decoder has to see the waveform cross below the negative threshold and then above the positive threshold. This Schmitt trigger provides a bit of hysteresis that cleans up the signal. The value of this DIVISOR corresponds to the tape deck's volume control.
He doesn't do that.
Such noise is what the DIVISOR is supposed to filter out. I disassembled parts of the Apple II BIOS once, and it turned out that the original Apple I/II cassette interface also implemented period shift keying.
He doesn't do that
If there were more noise than the DIVISOR could reject, then wouldn't it fail to load on the original hardware too?
a 1ms pulse (if you mean rise, 1ms hold, fall) corresponds to 500hz - Pretty much smack dab in the middle of the human auditory range. Any encoder that filtered that out would most likely only appeal to bats and insects, who don't tend to write all that much audio processing code.
A 1ms pulse between two frequencies is below the threshold of what the human ear can resolve when the tones are that close together. MP3 takes advantage of that by treating the transitions as masked and quantizes it heavily. If encoders didn't use this masking trick, they wouldn't be anywhere near as effective.
It's probably half the reason why the signal looks incredibly distorted. What's good enough for human ears may look messed up if it was supposed to have been a data stream.
The author treated it as period shift keying, which is equivalent to frequency shift keying. What makes decoding an FSK signal in the period domain "the hard way"?
It's not quite equivalent. The recorded wave file is heavily bandlimited so you can't reliably use a comparator to convert it to a period shift signal. I suspect the MP3 conversion is a lot to do with that. If there were any noise around the zero-crossing point, it wouldn't work at all. He's lucky that method works.
a) The MP3 encoding process didn't totally mangle the signal. A decent encoder should have dropped all those 1ms duration waves due to masking. Must be a crappy encoder or a forced high bitrate:)
b) I get the distinct impression the author doesn't know what FSK is, or that it's the encoding for the signal. Yet he still manages to decode it. The HARD way.
Slashdot Mirror
I'm a little dismayed that O3D had to introduce a fresh new API, and a high level one at that. This is right when everyone else is moving to simpler, smaller APIs - the big example being OpenGL ES 2. A handy example, because that's basically what WebGL is. I think O3D would have been better positioned as working alongside WebGL as a toolkit for higher level features, in much the same way GLU/GLUT work. As it stands, O3D requires a plugin download and install (even if it works today I still need to download and install it today), requires a learning another API that isn't a neutral standard (even if it is Google) and targets what looks like a very small market.
A huge advantage of WebGL is again that it's just OpenGL ES 2, but more specifically because this extends it to devices that aren't x86 desktops. Most of the latest "feature" handheld devices (including iPhone) support OpenGL ES 2 either natively or with some CPU-assist (the distinction is muddy on embedded devices anyway!) So they can support it today. Will O3D be as easy to cross-compile for ARM, bearing in mind it also bundles a V8 engine?
What the article actually shows is that all browsers, apart from Safari 4, are within a few percent of each other in energy usage. Even Safari isn't significantly far behind - 10% isn't going to make you choose another browser over it, considering you probably picked Safari for some other important feature in the first place.
So the real conclusions are not drawn in the article or in any comments I see here:
You're likely seeing the strong correlation between low CPU usage and low power usage, but again - none of them really focus on power. There's a lot of tricks you can do to make that huge leap (hint: network/disk usage and fancy offloaded graphics are low CPU but huge power users). None do them. I suspect Safari is chewing more power by having those fancy Apple-style transitions and widgets being rendered, which if you can turn off, will yield a runtime similar to the other browsers.
This is where the real battle will occur: when long battery life form factors start to become very popular, and browser authors realise that efficiency is worth just as much as features.
These are extreme fringe complaints.
There are lots of annoying little things with ARM. In the area of the instruction set itself, there is the whole issue of what happens when you load a 32-bit word that is unaligned. That depends on the mode you are in, but it usually does some crazy rotation, but that is actually useful to make use of. This also leads to strange alignment relative to everything else out there if you want the same code to be able to fill a structure say. Then there is the whole loading of constants using LDR which is not a real instruction, the assembler does what ever craziness it can manage to get a constant. If your code is PIC that basically means loading from memory, if it is noPIC then it might do crazy pc relative stuff. Oh and what about thumb mode, very non-orthogonal.
It's not ARM being different to everything else, it's x86 being different to everything else. Unaligned loads are unsupported by most architectures and for good reason - they complicate the pipeline. This is something you normally wouldn't encounter when hand-coding assembly, or if you would at least be expected to know about if you were. It's not a hard problem to work around, either. How is thumb mode very non-orthogonal? Are you looking at a different processor?
The "crazy constant loading" is a nice feature. When you go "ldr r0, =0x12345678" what you're actually telling the assembler to do is "ldr r0, [pc, #some_offset]" and putting that constant within 4KB of the current location. It's a short-hand you would, again, be expected to know if you're coding ARM assembly. It's not like it's doing something totally unexpected. The only funky one is "adr r0, some_location" where 'adr' translates into one or more instructions to load a pc-relative address, usually "add r0, pc, #offset". Again, hardly a surprising result, and one of very few examples of additional short-hand syntax.
Then ARM has the whole issues of all the differences. When they have TLBs and caches they tend to be alien (DACR ASID and PID) though the newest ARM cores are becoming more conventional. The same thing is there with regards to floating point. There have been lots of various ways that it was done.
These are system programming issues. You should see what x86 gets up to these days. Only WinCE 5 uses most of the weirder features (which Microsoft wanted adding for their own fucked up idea on how to do an OS) and nobody else does. Userland programmers do not see these issues. Floating point? Yes, there's many variants. The reason? It's not standard-issue on most ARMs, and if you're hand-coding floating point, then fucking hell you're probably hand-coding for an exact variant, so no surprises what you find.
And Debian has been distributing an ARM version for over a decade, now. It worries me how that fact is missing from reporting.
Smaller batteries also means smaller devices, a fact that many manufacturers have been taking advantage of for a long time. For example, almost every mobile phone out there is ARM powered.
All instruction sets are like that. RISC or not makes no difference.
The key difference with ARM is it's almost beautiful to look at: it's (mostly) orthogonal, has a regular but very powerful syntax, and it's easy to see the data dependencies. I'd say hand-coding ARM assembly is easier than any other processor I've done it on (and that's lots).
I agree with his friend, and would go further to say anyone who's serious about programming should learn at least one assembly syntax to know what's going on under the hood, and ARM is the best to try.
It doesn't matter if there's no commodity hardware support for a codec - it'll run just fine in software anyway.
This is why the Daily Mail should have the corporate death penalty.
Cost is only half the issue here. Power consumption is the other half. Even the current Atom offerings are absurdly more power hungry than your average system-on-chip ARM, and by absurdly I mean 100-1000 times more at "near-idle" tasks.
I think you also need to factor in that most SoC ARM solutions are extremely integrated. I would be very surprised if you can find an Atom design that's cheaper.
With any luck one of the major manufacturers will get over their fears and just ship a modern ARM Linux based netbook and settle this matter at last.
Still 10 billion shipments behind ARM.
And 3 orders of magnitude short of ARM's power consumption.
I was so concerned about the lack of development of Vorbis I decided to write my own Vorbis codec from scratch. Well, mostly it was an academic exercise many years ago, but since then I've realised that it's a genuinely useful project. It validated the specification, and showed up many places where the design could be improved.
It still needs a lot more work, but it currently decodes all Vorbis streams correctly at reasonable speed. Well, it's about half the speed of the official codec, but I haven't concentrated much on speed and there's some really obvious places where there are large improvements to be had easily.
If anyone's interested, it's hosted on Google Code:
Om Codec
Blaming Microsoft for the fact that Apple doesn't support MTP is ridiculous. Apple locked down iTunes so that you can't really use it with other players, and they tried to lock down the iPod so that you can't use it with other music management applications.
You missed my point. They specified that you can only use MTP and no other protocol. You were not allowed to have a dual-protocol device, which was perfectly possible. Of course, they eventually settled for allowing this, but not before the damage was done - vendors implemented MTP instead of the ubiquitous Mass Storage (MSC) and when you've got limited resources to do things, you settle for one protocol. So a mass of MTP devices appeared, which neatly didn't work on Mac.
And, of course, just to let us know they're Microsoft, MTP wasn't supported unless you had Windows Media player 9 installed. And of course, WMP9 wasn't supported unless you had Windows XP installed. Very neat.
I was there when this all happened and it was as obvious as a 100ft tall pink elephant. They got away with all this crap simply because the US and EU were busy with the bigger fish of browsers, openness, protocol compatibility and all the other monopolistic practices. I don't see why you should give them the benefit of the doubt here - there's decades and hundreds of examples of Microsoft doing the same thing over and over. This is no different.
As for "screwing the entire non-Apple MP3 market", I think you give Microsoft too much credit; Microsoft has had virtually no impact either way. If you want an MP3 player, there are plenty of choices that cost almost nothing.
You are wrong. If you are a non-Apple MP3 manufacturer you must go with PlaysForSure. It's a tick-box. The mass market wants tick boxes, and customers wanted P4S. If you didn't have P4S, you didn't sell. It's sad and believe me it's true. Microsoft screwed the market by crippling all the non-Apple vendors with a shitty product.
MP3 players are dead anyway; like PDAs, they are just becoming part of phones.
That is patently untrue. There are so many factors which will ensure they'll be around for years. Form factor is one. Price is a fucking obvious one too.
Also notice that the phones which list music playback as a strength have all gone with their own implementations. Notice how big the companies are that had the guts to do it: e.g Nokia. Sadly we're left with a bunch of walled-garden solutions, iTunes included.
That means Microsoft have not only managed to damage to MP3 market to the extent that Apple "won", but now they're dropping out too. If I weren't convinced they were just short-term reactionary fools I would believe they had it planned all along.
What am I going on about? Well, you see, back in the days just after iPod, Microsoft introduced this thing called PlaysForSure. It was a system to provide a variety of DRM options - single track purchase, promotion with timeout, monthly fee all-you-can-eat, limited play count, and so on. This in itself would have provided a superset of the functionality iTunes provided.
(For the record, where I stand: DRM must die. Three times. Horribly. Preferably acid bath.)
Sounds great, at least from a technical and business standpoint, right? Unfortunately, just to remind us that they're Microsoft, in order to get a PlaysForSure badge on your product, and to be allowed to use the system whatsoever, you have to pass certain certification processes. That includes making sure you have a good startup time, good inter-track delay time, fast database indexing, and so on.
Still sounds great? Aha, but just to remind us they're Microsoft, they're the people that design the protocol, and they make damn sure it's near-impossible to actually implement a good player from it. The database updates and queries are so horribly defined you'd struggle to get good performance out of a proper SQL-like database running on a PC, let alone a tiny little device with 1MB RAM. The requirement to support PlaysForSure means you must use MTP protocol, which is another botched abortion of a protocol. It also requires that if you use MTP you cannot use Mass Storage, further annoying your customers and very neatly if "accidentally" meaning they don't work on Macs. And then there's the encryption itself which is so horribly over-the-top and poorly implemented (you MUST use Microsoft's libraries) that it badly impacts player performance and its battery life.
So Microsoft screw the entire non-Apple MP3 market for a couple of years. Then they bring out their own PlaysForSure player. Except it's not PlaysForSure. You can imagine the language used where I worked (and presumably other companies). They decided that it was too hard to implement their own spec, so they make a player which doesn't comply to it. It's not even in the set at all - it's totally incompatible.
After an electronics-generation of fucking up the non-Apple MP3 market, then screwing up their own solution, and now after (very likely) ditching Zune, they've basically done almost exactly the right set of steps to put Apple into a lead that will be hard to make a dent into.
I stick with my decade old opinion that you don't partner with Microsoft - you watch your back.
I bet they've managed to accidentally revoke or break its certificates. Microsoft "accidentally" did that to an MP3 player I worked on in the past (Rio Carbon).
This is why he says "in practice" and "commercial".
It's great research, but it's pretty silly to buy it.
Does your laptop have GPS?
The strange thing is that I've written drivers for many EEPROMs, and they all have a few hoops you have to jump through to enable writing. It's not something you can just accidentally do.
Usually it's something like 'Read address 0xaaaa then 0xdddd then write some magic byte then the address then write 128 bytes'.
Perhaps Intel thought they didn't need all that magic?
95% of customers are overpaying for their connections by 50%, due to their ISP selling them a service far beyond what they actually need.
I prefer that one, personally.
I seriously doubt they would try to enter the x86 market. Perhaps it's just this that people are mistaking it for. That's frankly a bigger market than anything x86 based.
I think hard drive manufacturers would have shockingly high return rates if removing power during a write had a high chance of destroying the entire drive.
It's not like it's an unlikely scenario, and they HAVE thought of it. Perhaps you can shed light on which manufacturer you used so we can all avoid buying their defective designs? All the drives I've used in making various consumer electronic devices have data that says they handle it fine. Perhaps you bought an IMB or Hatichi drive?
I don't think this has been true since... maybe 8-10 years now? Definitely since MR drives came on the market (ages ago).
Modern drives have:
It does NOT go writing crap all over whatever's between your data and the parked position, unless the drive is a defective design. The emergency park is a fairly brutal affair, and you'll typically see the datasheet list a maximum number that's notably lower than the max power cycles.
It's also essential these days because:
Normally that holds true. I've seen some drives (1.0" and 1.8" miniature ones) which suffered from head-on-platter but that was due to misdesign in the power supply feeding it (e.g voltage rails going slightly negative, draining the cap early).
But anyway, the worst you'll get with the power going out is a partially written sector, which will then be marked bad, probably permanently. Or maybe a bunch of sectors. Or maybe bad in a different order to what the OS sent due due to caching.
If you had a drive and/or RAID fail due to power outage, you should get a refund. You might lose a tiny amount of data, not the whole lot.
That's nice but,
Which is why the decoder uses two comparators: one at 32768/DIVISOR and one at -32768/DIVISOR. In order to count a pair of transitions, the decoder has to see the waveform cross below the negative threshold and then above the positive threshold. This Schmitt trigger provides a bit of hysteresis that cleans up the signal. The value of this DIVISOR corresponds to the tape deck's volume control.
He doesn't do that.
Such noise is what the DIVISOR is supposed to filter out. I disassembled parts of the Apple II BIOS once, and it turned out that the original Apple I/II cassette interface also implemented period shift keying.
He doesn't do that
If there were more noise than the DIVISOR could reject, then wouldn't it fail to load on the original hardware too?
Yes, he's lucky.
a 1ms pulse (if you mean rise, 1ms hold, fall) corresponds to 500hz - Pretty much smack dab in the middle of the human auditory range. Any encoder that filtered that out would most likely only appeal to bats and insects, who don't tend to write all that much audio processing code.
A 1ms pulse between two frequencies is below the threshold of what the human ear can resolve when the tones are that close together. MP3 takes advantage of that by treating the transitions as masked and quantizes it heavily. If encoders didn't use this masking trick, they wouldn't be anywhere near as effective.
It's probably half the reason why the signal looks incredibly distorted. What's good enough for human ears may look messed up if it was supposed to have been a data stream.
The author treated it as period shift keying, which is equivalent to frequency shift keying. What makes decoding an FSK signal in the period domain "the hard way"?
It's not quite equivalent. The recorded wave file is heavily bandlimited so you can't reliably use a comparator to convert it to a period shift signal. I suspect the MP3 conversion is a lot to do with that. If there were any noise around the zero-crossing point, it wouldn't work at all. He's lucky that method works.
The interesting thing about this article is:
This could have been done so much more easily :)