This was a thing with the Amiga 500 computer too. I worked at a company which had a corporate field deployment of over a thousand Amiga 500 systems and some of these computers would start crashing intermittently due to the A500's "Fat Agnus" becoming unseated in its square socket, especially during shipping and thermal expansion/contraction. The chip got its nickname because it was a square packaged upgrade version of the earlier rectangular Agnus chip in the Amiga 1000.
These 1,000+ Amiga 500s were leased as complete systems including a 13" monochrome composite video monitor and an Okidata 182 dot matrix printer. All these Amigas only ever ran a single, highly complex and extremely valuable custom software application which auto-booted from the internal 880k floppy, was never publicly released and has remained unknown to this day.
This program was protected from being pirated with hardware in the form of a custom-designed and manufactured 1MB RAM + Real-Time Clock expansion board pre-installed in the A500's "trap door" slot on the bottom. This unique board added the same functionality as the standard Commodore A501 board but was customized by swapping the real-time clock data lines around, which the software checked to confirm it was running on an officially leased A500. The software application was written in C by myself and two other devs and we also doubled as the support, service, training, installation and shipping staff for this fleet.
Since we shipped them to each field location and they tended to be in locations which weren't well thermally controlled after hours, we got a fair number of these errors. Since the vast majority of our users were older female office workers who'd never touched a computer before, any error would trigger a support call. It wasn't easy to convince these nice ladies on the phone to lift the computer 6 inches and then drop it! But it did always fix the problem. We called it a "technical drop" :-)
As a very early Amiga 1000 owner and enthusiast, I'm the one who primarily convinced this small company that the newly announced A500 was the best low-cost option to run field deployments of their niche application and, aside from this occasional error problem, the huge fleet of Amigas performed admirably for many years. Especially considering the machines were individually shipped to each field location and these tended to be pretty hostile environments like temporary mobile offices, sometimes powered only by gasoline-powered generators subject to constant surges and brown-outs (think construction trailers).
I'm proud my unorthodox recommendation ended up working out so well since, despite my obvious bias, the A500 really was the perfect fit for this unique application in early 1987. The software app itself was related to real estate financing, so it had to have a 10-key and the entire system had to fit on a small side desk used by constantly rotating staff in a crowded temporary office. It had to be self-booting, self-maintaining and dirt simple, since almost none of the users had ever touched any computer before. It also had to be reliable because they frequently got moved around in the field between desks and buildings entirely by these novice users. So being all-in-one really helped since every extra wire and component was another thing to lose and/or break. I learned the hard way that talking to a nice lady on the phone who'd never seen a computer in person through reconnecting this "newfangled contraption" which someone else had disconnected, moved and left on the floor in a random pile the day before, was a rapid education on how to communicate physical instructions clearly! I always just pictured them as my sweet elderly aunt which helped keep my cool :-). Finally, the system had to be super cheap because they got stolen fairly often (no security after hours in these isolated remote offices).
Although entirely unknown at the time or after (since there was no reason for this small company serving a narrow niche market to do any PR) this was, as far as I know, the largest ever corporate deployment of Amiga computers.
One interesting note: the application was written to only use the keyboard, mostly just the arrow and Enter keys plus a few function keys we labeled with custom color-coded stickers for navigation such as Go, Back, Menu and Print. Usually we never even supplied the Amiga mouse with the systems, however I was optimistic we could show the users how to operate the mouse so they could run other apps if they wanted to. I conceded defeat after trying to teach the first half dozen users I did installs for how to use the "Bonus Mouse". I thought some would eventually get it but the necessary eye-hand coordination completely eluded these nice ladies circa 1987.
> Where in the world did you deploy 1000 Amiga 500s?
Good question! It was a small niche business called "Computer For Tracts" which leased a complete turnkey solution to new home construction sales offices. You'd find these in new growth areas where home builders have bought a large land parcel to create a new development by building a couple hundred suburban homes (as well as the local streets, parks, etc). Basically, they'd first clear the land and complete four or five homes to show as models of each floor plan. They'd usually turn the garage of one of the models into an onsite sales office which would be staffed by an employee realtor who could discuss all the various options (flooring, paint), lot selection and write up a sales contract. These little makeshift sales offices would operate for 3 or 4 years until the development was sold out, at which time the models would be converted into the last homes sold and the builder would start a new development elsewhere.
The company was started in the early 80s in Southern California by a realtor who'd spent his career in new construction residential sales and knew the biz inside out. New construction residential sales has distinct needs different from residential resales. So he wrote a software program in the ROM BASIC of a Radio Shack Color Computer to do exactly what a new construction sales person needs to do. This involves calculating the financing options including the down payment, monthly payments, taxes and insurance for all the various loan options available, like 30-yr fixed, 15-yr adjustable rate and then sending prospective buyers home with a customized printout showing their options based on their particulars including down payment, rate, credit score, etc.
It was really quite complex under the hood, yet it made all this easy for a sales agent to present clearly to even novice home buyers. It turns out that doing this is well is key to selling the builder's growing inventory of homes and, obviously, there's a lot of money tied up in such a development. His early versions of the program loaded from an external audio cassette tape player by having the user manually press Play, Stop and Rewind. But this was a major problem because new home construction companies aren't IT savvy and the vast majority of realtors (especially in the early 1980s) had never even seen a computer in person before. So, he learned how to burn his custom BASIC program on EPROMs he installed into blank game cartridges inserted into the Color Computer's game cartridge port.
He was then able to offer a self-booting system that his novice users could learn to operate. He marketed it as a complete solution on a monthly lease (including computer, software cartridge, monitor, printer, cables, installation, training, service and support). Since these Radio Shack computers where just a few hundred dollars and his system was extremely valuable to such construction companies, his little garage business grew like wildfire. I think I was the third non-family employee and we were still working out of the garage and back bedrooms of his house before later moving to an office. Eventually, the software became so complex that it wouldn't fit in a ROM cartridge any more, even after I wrote a pretty neat assembly language hack that lived in the game cartridge ROM and took control on every boot to add new commands to the computer's built-in BASIC interpreter before returning control back to the BASIC program. These new BASIC commands allowed programs to swap between four and eventually eight banks each containing an 8K segment of BASIC code and even pass control to a specific BASIC line number in another bank of EPROM-based BASIC code. It was quite a deep hack into the undocumented system but it worked perfectly and is a testament to the benefits of having an all-hardware system where nothing ever persists between boots. When the capabilities of the program eventually expanded so it couldn't fit in 64K or even 128K of dedicated EPROM (in addition to the computer's 64K of RAM), even with lots of very clever byte-counting optimization and compression tricks, we started looking to move off the 8-bit Radio Shack Color Computer to a 16-bit platform with more memory and disk storage - and I started suggesting the just announced (but not yet shipping) Amiga 500 would be ideal (which it was)!
Over the early years of constant iteration and daily customer feedback, the program had evolved to become really perfect for doing this one, extremely valuable yet highly specialized thing and the little company grew fast and was highly profitable. He could charge quite a bit for the monthly lease because no salesperson who'd used it ever wanted to sell without it. It was really that good. In fact, the lease required the first two and last two months payments up front, and this was enough to basically pay for the computer, monitor, printer, power strip, etc. So after that, the rest of the lease contract was all profit (although, service, support and ongoing training had to be available 10 hours a day, seven days a week, including weekend onsite system replacement if necessary (which could involve driving over four or five hours round-trip on a Sunday if you were on-call that weekend)) so the customers definitely got value for their money. And supporting this highly specialized, extremely deep application took at least a full year for a new person to learn (if they were sharp) which is why in the early days we three software coders were also the support, training and field service staff). While strange in today's world, that's probably why this software became so damn polished to perfection for this use case.
For example, after selecting a home model, to update the main financing screen showing all the different loan options, all the agent had to do was punch a different interest rate, monthly payment, or down payment on the 10-key and it would recalculate all the loans with the new parameter. They didn't even have to select an input field because the program dynamically figured out based on the value typed and the sales price if the entered value should be interpreted as a rate, monthly payment or down payment.
In an era before spreadsheets, without this program, it took these agents at least three minutes to change one parameter for one loan on a manual TI paper-tape adding machine. But our program recalced a dozen loans in two seconds (including every possible option from full amortization tables to rate buy-downs). This made providing full, clear and detailed answers to every customer question trivial (like "How much more do I need to put down to reduce the monthly payment by $500?"). To these sales people this seemed like literal voodoo magic ("How does it know that what I typed in was the desired monthly payment?") :-)
Last I heard the company had transitioned the program to Windows PCs sometime in the mid-90s and was still around in some form post-2000.
BASIC on the early 8, and more generally 16 bit machines was quite a bit more empowering than pop media tends to speak to.
My uncle Bob (seriously, I have the generic uncle "Bob"), developed real estate contracts using a combination of C64 BASIC and some word processor that allowed for conditional and parametric document assembly, almost Word Perfect style!
He built up quite a business with those efforts!
A bit later a friend wrote an entire trucking business on the PC running GWBASIC.
I myself started out on a beat up Atari 400 with the Atari BASIC cartridge and the cassette storage peripheral I struggle to recall the name of right now.... 410! That was it.
I wrote TV test and alignment programs. Learned all that working at a TV repair shop as a kid. The Atari had just a couple capabilities that made a huge difference too!
One of those was at least 8 grey shades. I know GTIA could deliver 16 and I ended up using them once I made enough to get a newer 800 XL machine.
Another feature was full overscan graphics. 48 bytes per line instead of 40. That made it possible to draw the full frame patterns and properly identify the safe area for viewers wanting the factory setup, and expand viewing for others without showing blank non raster regions on their screen.
Side bar:
Older sets would often under scan by quite a bit! Correcting that often meant a lot to those viewers.
End Side bar
Another feature was enough colors to calibrate a TV for good color more than close enough. I could get purity tests, set color delay phase and some other items pretty well!
Last feature was 320 pixels in the safe area NTSC. That is two pixels per color clock cycle. When set to monochrome, those pixels were just right for focus, convergence, linearity and the whole test pattern.
All this was some percent off the pro gear, but I found out most people do not care. And I mostly didn't either.
As a famous YouTube I love says, "Good enough for the girls I go out with" (AvE)
BASIC with a few PEEK and POKE commands and the occasional bit of machine language was enough to do a lot!
COMPUTE! Published a nice assembler and disassembler too. For some work, a guy could get setup well enough to produce good programs.
Getting back to XP...
I wrote the above for perspective. Of course XP can make sense. So can DOS, an Amiga, and Windows 3.11, just ask Southwest airlines.
Fact is many of us here can probably work magic with whatever gets put into our hands. I can.
And all these skills couple with microcontrollers too.
Perhaps that warrants discussion here too one day. The skills are a great match and when one can build hardware feature matched to the use case?
Unfortunately, very little of this article is accurate.
The Apple III's RAM is located on a separate board mounted above the motherboard using a custom connector. The initial RAM connector had a design flaw that wasn't caught during testing and ended up shipping. The flaw caused the machine to intermittently lose connection to its RAM, and without RAM the machine obviously doesn't run. Jostling things around restores the connection to RAM and get things working again.
Apple redesigned the RAM connector and then recalled all of the initial machines through their authorized dealer network. Every motherboard was replaced, regardless of whether it exhibited problems or not. Apple continued to sell the Apple III for four years using the same aluminum heat sink for its entire run. During that run it was as reliable as any other machine on the market.
The Apple III never had an overheating problem. It did not contain chips that were magically able to unseat and reseat themselves. These were all just theories that people invented to try to explain the behavior they were seeing. The theories were complete fiction, and are laughably preposterous in retrospect. And yet, the theories continue to be repeated as fact 40+ years later.
The Apple III was an important chapter in Apple's history not because it was a dud, but because of the way it developed an untrue reputation for poor reliability that it was never able to shake in the four years it was manufactured and sold.
The "Drop Three Inches" podcast is a great listen if you want to more about the Apple III. http://drop-iii-inches.com
Wendell Sanders — Apple III engineer — is on record saying this was due to corrosion on the memory board connectors, not to heat. Dropping or moving the computer with force would cause the contacts to rub together and clear the corrosion temporarily. The problem went away when they upgraded the connectors.
These 1,000+ Amiga 500s were leased as complete systems including a 13" monochrome composite video monitor and an Okidata 182 dot matrix printer. All these Amigas only ever ran a single, highly complex and extremely valuable custom software application which auto-booted from the internal 880k floppy, was never publicly released and has remained unknown to this day.
This program was protected from being pirated with hardware in the form of a custom-designed and manufactured 1MB RAM + Real-Time Clock expansion board pre-installed in the A500's "trap door" slot on the bottom. This unique board added the same functionality as the standard Commodore A501 board but was customized by swapping the real-time clock data lines around, which the software checked to confirm it was running on an officially leased A500. The software application was written in C by myself and two other devs and we also doubled as the support, service, training, installation and shipping staff for this fleet.
Since we shipped them to each field location and they tended to be in locations which weren't well thermally controlled after hours, we got a fair number of these errors. Since the vast majority of our users were older female office workers who'd never touched a computer before, any error would trigger a support call. It wasn't easy to convince these nice ladies on the phone to lift the computer 6 inches and then drop it! But it did always fix the problem. We called it a "technical drop" :-)
As a very early Amiga 1000 owner and enthusiast, I'm the one who primarily convinced this small company that the newly announced A500 was the best low-cost option to run field deployments of their niche application and, aside from this occasional error problem, the huge fleet of Amigas performed admirably for many years. Especially considering the machines were individually shipped to each field location and these tended to be pretty hostile environments like temporary mobile offices, sometimes powered only by gasoline-powered generators subject to constant surges and brown-outs (think construction trailers).
I'm proud my unorthodox recommendation ended up working out so well since, despite my obvious bias, the A500 really was the perfect fit for this unique application in early 1987. The software app itself was related to real estate financing, so it had to have a 10-key and the entire system had to fit on a small side desk used by constantly rotating staff in a crowded temporary office. It had to be self-booting, self-maintaining and dirt simple, since almost none of the users had ever touched any computer before. It also had to be reliable because they frequently got moved around in the field between desks and buildings entirely by these novice users. So being all-in-one really helped since every extra wire and component was another thing to lose and/or break. I learned the hard way that talking to a nice lady on the phone who'd never seen a computer in person through reconnecting this "newfangled contraption" which someone else had disconnected, moved and left on the floor in a random pile the day before, was a rapid education on how to communicate physical instructions clearly! I always just pictured them as my sweet elderly aunt which helped keep my cool :-). Finally, the system had to be super cheap because they got stolen fairly often (no security after hours in these isolated remote offices).
Although entirely unknown at the time or after (since there was no reason for this small company serving a narrow niche market to do any PR) this was, as far as I know, the largest ever corporate deployment of Amiga computers.
One interesting note: the application was written to only use the keyboard, mostly just the arrow and Enter keys plus a few function keys we labeled with custom color-coded stickers for navigation such as Go, Back, Menu and Print. Usually we never even supplied the Amiga mouse with the systems, however I was optimistic we could show the users how to operate the mouse so they could run other apps if they wanted to. I conceded defeat after trying to teach the first half dozen users I did installs for how to use the "Bonus Mouse". I thought some would eventually get it but the necessary eye-hand coordination completely eluded these nice ladies circa 1987.
Good question! It was a small niche business called "Computer For Tracts" which leased a complete turnkey solution to new home construction sales offices. You'd find these in new growth areas where home builders have bought a large land parcel to create a new development by building a couple hundred suburban homes (as well as the local streets, parks, etc). Basically, they'd first clear the land and complete four or five homes to show as models of each floor plan. They'd usually turn the garage of one of the models into an onsite sales office which would be staffed by an employee realtor who could discuss all the various options (flooring, paint), lot selection and write up a sales contract. These little makeshift sales offices would operate for 3 or 4 years until the development was sold out, at which time the models would be converted into the last homes sold and the builder would start a new development elsewhere.
The company was started in the early 80s in Southern California by a realtor who'd spent his career in new construction residential sales and knew the biz inside out. New construction residential sales has distinct needs different from residential resales. So he wrote a software program in the ROM BASIC of a Radio Shack Color Computer to do exactly what a new construction sales person needs to do. This involves calculating the financing options including the down payment, monthly payments, taxes and insurance for all the various loan options available, like 30-yr fixed, 15-yr adjustable rate and then sending prospective buyers home with a customized printout showing their options based on their particulars including down payment, rate, credit score, etc.
It was really quite complex under the hood, yet it made all this easy for a sales agent to present clearly to even novice home buyers. It turns out that doing this is well is key to selling the builder's growing inventory of homes and, obviously, there's a lot of money tied up in such a development. His early versions of the program loaded from an external audio cassette tape player by having the user manually press Play, Stop and Rewind. But this was a major problem because new home construction companies aren't IT savvy and the vast majority of realtors (especially in the early 1980s) had never even seen a computer in person before. So, he learned how to burn his custom BASIC program on EPROMs he installed into blank game cartridges inserted into the Color Computer's game cartridge port.
He was then able to offer a self-booting system that his novice users could learn to operate. He marketed it as a complete solution on a monthly lease (including computer, software cartridge, monitor, printer, cables, installation, training, service and support). Since these Radio Shack computers where just a few hundred dollars and his system was extremely valuable to such construction companies, his little garage business grew like wildfire. I think I was the third non-family employee and we were still working out of the garage and back bedrooms of his house before later moving to an office. Eventually, the software became so complex that it wouldn't fit in a ROM cartridge any more, even after I wrote a pretty neat assembly language hack that lived in the game cartridge ROM and took control on every boot to add new commands to the computer's built-in BASIC interpreter before returning control back to the BASIC program. These new BASIC commands allowed programs to swap between four and eventually eight banks each containing an 8K segment of BASIC code and even pass control to a specific BASIC line number in another bank of EPROM-based BASIC code. It was quite a deep hack into the undocumented system but it worked perfectly and is a testament to the benefits of having an all-hardware system where nothing ever persists between boots. When the capabilities of the program eventually expanded so it couldn't fit in 64K or even 128K of dedicated EPROM (in addition to the computer's 64K of RAM), even with lots of very clever byte-counting optimization and compression tricks, we started looking to move off the 8-bit Radio Shack Color Computer to a 16-bit platform with more memory and disk storage - and I started suggesting the just announced (but not yet shipping) Amiga 500 would be ideal (which it was)!
Over the early years of constant iteration and daily customer feedback, the program had evolved to become really perfect for doing this one, extremely valuable yet highly specialized thing and the little company grew fast and was highly profitable. He could charge quite a bit for the monthly lease because no salesperson who'd used it ever wanted to sell without it. It was really that good. In fact, the lease required the first two and last two months payments up front, and this was enough to basically pay for the computer, monitor, printer, power strip, etc. So after that, the rest of the lease contract was all profit (although, service, support and ongoing training had to be available 10 hours a day, seven days a week, including weekend onsite system replacement if necessary (which could involve driving over four or five hours round-trip on a Sunday if you were on-call that weekend)) so the customers definitely got value for their money. And supporting this highly specialized, extremely deep application took at least a full year for a new person to learn (if they were sharp) which is why in the early days we three software coders were also the support, training and field service staff). While strange in today's world, that's probably why this software became so damn polished to perfection for this use case.
For example, after selecting a home model, to update the main financing screen showing all the different loan options, all the agent had to do was punch a different interest rate, monthly payment, or down payment on the 10-key and it would recalculate all the loans with the new parameter. They didn't even have to select an input field because the program dynamically figured out based on the value typed and the sales price if the entered value should be interpreted as a rate, monthly payment or down payment.
In an era before spreadsheets, without this program, it took these agents at least three minutes to change one parameter for one loan on a manual TI paper-tape adding machine. But our program recalced a dozen loans in two seconds (including every possible option from full amortization tables to rate buy-downs). This made providing full, clear and detailed answers to every customer question trivial (like "How much more do I need to put down to reduce the monthly payment by $500?"). To these sales people this seemed like literal voodoo magic ("How does it know that what I typed in was the desired monthly payment?") :-)
Last I heard the company had transitioned the program to Windows PCs sometime in the mid-90s and was still around in some form post-2000.
My uncle Bob (seriously, I have the generic uncle "Bob"), developed real estate contracts using a combination of C64 BASIC and some word processor that allowed for conditional and parametric document assembly, almost Word Perfect style!
He built up quite a business with those efforts!
A bit later a friend wrote an entire trucking business on the PC running GWBASIC.
I myself started out on a beat up Atari 400 with the Atari BASIC cartridge and the cassette storage peripheral I struggle to recall the name of right now.... 410! That was it.
I wrote TV test and alignment programs. Learned all that working at a TV repair shop as a kid. The Atari had just a couple capabilities that made a huge difference too!
One of those was at least 8 grey shades. I know GTIA could deliver 16 and I ended up using them once I made enough to get a newer 800 XL machine.
Another feature was full overscan graphics. 48 bytes per line instead of 40. That made it possible to draw the full frame patterns and properly identify the safe area for viewers wanting the factory setup, and expand viewing for others without showing blank non raster regions on their screen.
Side bar:
Older sets would often under scan by quite a bit! Correcting that often meant a lot to those viewers.
End Side bar
Another feature was enough colors to calibrate a TV for good color more than close enough. I could get purity tests, set color delay phase and some other items pretty well!
Last feature was 320 pixels in the safe area NTSC. That is two pixels per color clock cycle. When set to monochrome, those pixels were just right for focus, convergence, linearity and the whole test pattern.
All this was some percent off the pro gear, but I found out most people do not care. And I mostly didn't either.
As a famous YouTube I love says, "Good enough for the girls I go out with" (AvE)
BASIC with a few PEEK and POKE commands and the occasional bit of machine language was enough to do a lot!
COMPUTE! Published a nice assembler and disassembler too. For some work, a guy could get setup well enough to produce good programs.
Getting back to XP...
I wrote the above for perspective. Of course XP can make sense. So can DOS, an Amiga, and Windows 3.11, just ask Southwest airlines.
Fact is many of us here can probably work magic with whatever gets put into our hands. I can.
And all these skills couple with microcontrollers too.
Perhaps that warrants discussion here too one day. The skills are a great match and when one can build hardware feature matched to the use case?
Boom goes the Dynamite!
The Apple III's RAM is located on a separate board mounted above the motherboard using a custom connector. The initial RAM connector had a design flaw that wasn't caught during testing and ended up shipping. The flaw caused the machine to intermittently lose connection to its RAM, and without RAM the machine obviously doesn't run. Jostling things around restores the connection to RAM and get things working again.
Apple redesigned the RAM connector and then recalled all of the initial machines through their authorized dealer network. Every motherboard was replaced, regardless of whether it exhibited problems or not. Apple continued to sell the Apple III for four years using the same aluminum heat sink for its entire run. During that run it was as reliable as any other machine on the market.
The Apple III never had an overheating problem. It did not contain chips that were magically able to unseat and reseat themselves. These were all just theories that people invented to try to explain the behavior they were seeing. The theories were complete fiction, and are laughably preposterous in retrospect. And yet, the theories continue to be repeated as fact 40+ years later.
The Apple III was an important chapter in Apple's history not because it was a dud, but because of the way it developed an untrue reputation for poor reliability that it was never able to shake in the four years it was manufactured and sold.
The "Drop Three Inches" podcast is a great listen if you want to more about the Apple III. http://drop-iii-inches.com