Slashdot Mirror
Handspring Hides Flash ROM in Handspring Treo
miradu writes: "TreoCentral has just posted an intriguing article about how the Handspring Treo has Flash ROM - something that Handspring claims it doesn't. They've worked with Brayder Technology to create applications to utilize this newly discovered feature. It brings up the question, Why do developers lie about features in a device - especially if they are features that are wanted? Does anyone know any other examples?" Strange -- hardware manufacturers don't often underestimate their products' capabilities, do they?
It allows them to remove the Flash at some point in the future and replace it with a cheaper ROM. If they don't tell you that they have a Flash, then you won't complain when it is removed. I would expect the next version to be missing the Flash.
The dogcow says "Moof!"
Users of the Samsung i300 for the longest time were told that there was no flash rom, and that the operating sytem was not upgradable.
Then FlashPro came out and proved that there was flash in the i300.
Upgrading the OS is still not an option, considering that there are lots of propreitary extensions to the OS.
However, the flash capabilities of the devices were hidden for quite a while.
Jake
PhysicsGenius is absolutely right. See this research paper for more information on why they don't want you to know the facts.
Yes, the proper adjective would have been "unrhetorical".
The educational system in America sucks balls.
The developers of the hardware usually aren't the ones who are lying.
Agreed! I've seen that happen more than a few times. Thought it might be useful to add another possible reason why some features are hidden.
My expertise is with software (20+ years in QA), not hardware, but I've seen the hiding of features happen several times. In my experience, the develpment cycle starts off with marketing making its pitch for what needs to be in the product release, and development pushes back with what is feasible in the time frame, as well as what they would like to do. There's some negotiation, and then development goes off to "do their thing". And all is happy and good.
Then QA appears and does its thing. Sometimes QA is called in right from the start; other times the product is almost ready for release and someone thinks it might be good to have QA look at it before it is shipped tomorrow. I actually have seen a few projects released on time, under budget, and with the promised capabilities. But, that is sadly the exception rather than the rule. Even with an early participation by QA, there are often far more developers at work than QA people. The number of possibilities goes up exponentially, and there's just not enough time to test everything as it is developed. Design errors and implementation errors are found. Rework is required. Deadlines loom. All is not as happy and good as it once seemed. And then it happens.
Maybe it's a nasty memory leak that builds up over time. Maybe there's a variable that gets corrupted, eventually. And there's not enough time to isolate it and fix it. So, instead of yanking out all the questionable code (which would introduce its own bevy of problems), the common approach is to just remove access to it (e.g. removing a choice from a pull-down menu) and, of course, removing all reference to it in the documentation.
So, there's quite possibly some hidden functionality in a program (or a piece of hardware), but it was hidden for a reason. If you're a bleeding-edge kind of person, go have fun. In light of your particular circumstances, it might well seem to work okay. But, if you need to be able to rely on the application or system, it might be a Really Good Idea(TM) to use only the documented features. You might miss out on some helpful features, but you might also save your butt.
Mainframes would ship with various disabled features. Remember these were room-size devices (well, multiple large cabinets which would fill up a big room). When the customer wanted an upgrade, an IBM technician would be sent out, he would rearrange some jumpers, enabling a feature, and the customer would receive a bill for e.g. $100,000 for a memory upgrade.
IBM made no apology for this: you were charged for the functionality you received, and the fact that the "upgrades" already existed inside the boxes in your computer room was irrelevant.
So perhaps one can blame IBM for having started the ball rolling on the idea of strong control of "intellectual property" by the vendor... I wonder if anyone back then "hacked" their own mainframes?
When a product is designed, especially when the product is part of an evolving line of similar products, the product may contain bits of technology that are there to test various design points or manufacturing methods. While these are part of the product, if the features these technology pieces provide are not advertised, then the manufacturer has no duty to provide support for them.
Support is one of the most costly items in a products lifecycle. I remember a statistic (I can't quote the source) that 50% of the cost of software is in the support and maintainance of it after release. I would venture that Handspring has looked at what it would take to support this feature and decided that there is not enough margin in the product to support it even if the capability is provided in the hardware.
A final thought, they may have discovered some sort of performance or reliability problem with the flash ROM and instead of correcting the problem (potentially quite costly), they removed the feature so they did not have to support it.
-tpg.
Late 70's/Early 80's Techtronics used to ship
the 4014 Storage Tube Terminal. To convert it
to a 4015 you paid some big bucks to Techtronics
and a technician came out and clipped a couple
of wires to enable the additional features.
TI's TI-58/59 calculators had undocumented
instructions that were useful in getting
programs smaller (Direct access to processor
stack). (1977?)
Undocumented/Denied features have been going
on for years. Why be surprised ?
The worse case I came accross was a printer from IBM. They had two models. One printed at 60 cps the other at 120 cps. The only difference between the two was a soldered in short. You could pay IBM to upgrade your slower printer. The engineer would show up and snip the solder. You now had doubled your speed. The engineer had no fear of showing me this, because he knew my employer would never let us perform this simple operation ourself.
THE EARLIEST EXAMPLE that springs to mind is on Radio Shack's TRS-80 Color Computers. There was some story about doubling the RAM by bending two pins on a socketted IC chip. The story was that the onboard capacity was crippled for the sake of easy in-store upgrades.
Hmm. If this is what I think you're referring to, that's not quite true. (You may be referring to soemthing I hadn't heard about, of course.)
What Tandy did do with the early CoCo 2 series was to take 64K memory chips that had tested with one or two bad bits, grab a set of them that were all bad in the same half of memory, then sell the result as a cheap 32K machine. Because of the way the Microsoft BASIC ROMs were mapped into memory, you couldn't use more than 32K of RAM under BASIC anyway.
Side note: because of the way dynamic RAM is arranged with row and column addresses, DRAM chips will always have an even number of address bits. So nobody ever made 32K chips (which would require 15 address bits).
Soon enough 64K chips became dirt cheap anyway, so there was no point in using bad ones; it was still cheaper to use 64K chips than twice as many 16K ones for a 32K computer. And besides, the CoCo 2 motherboard didn't have enough memory sockets to use 16K chips. The 'extra' 32K was only useful if you were running something like Flex09 or OS-9; OS-9 being a real-time multi-tasking operating system written for the 6809 processor, and available for the CoCo back in the early to mid eighties.
So it wasn't a matter of 'easy in-store upgrades'; it was a matter of it being a lot cheaper to build that way.
-- Bryan Feir