[ The following comes from two emails Bill sent, three and a half years apart! He has given me permission to share them. ]
Poulter and his group took the interpreted-BASIC language from the HP 2000 series timesharing machines, widely used in schools, and extended it so that it was really useful for business apps. For instance, I had to write time-consuming double-floating-precision routines to manage big sums - the 32-bit FP on the HP machines was precise to only 6 decimal digits. BTI added 4-function decimal arithmetic, which made it all simple. BTI added many other fixes and extensions. Our HP 2000E starter system limited a program to 4 open files of less than 10 KB apiece! Making a DBMS work in this environment was quite a chore. I never would have bought the HP system if I had known about the BTI 3000, their first edition.
The BTI 4000 used the HP 21MX CPU with the troublesome switcher. The 5000 featured a BTI CPU that emulated the 21MX, and a inefficient but reliable linear regulator. That's where they stopped with the small systems, alas. BTI also microcoded major sections of the interpreter which got instruction execution from the low millisecond to the 200+ microsecond range, quite an improvement.
With the speed-up microcode, our 4000 handled 6+ business users with acceptable keyboard response time.
Our first 4000 , with a 10 MB disk and tape cart backup cost about $35k. I added performance over the 10 year period by buying used systems for their parts. I ended up buying old 21MX processors just to get their power supplies - this was cheaper than fixing the blown ones.
Incidentally, those 10 MB disks were made by Control Data, and to save money, had a brush-type pancake motor. They would run from 3 to 6 months before the brushes failed. Replacing them was a messy business, because the motor had to be disassembled and all the carbon dust cleaned out. The brushes had a particular formulation and I believe I bought them from PMI, the motor manufacturer. BTI would fix the motors, but you had to ship the entire drive back. BTI wasn't used to customers doing their own maintenance. The spindle bearings would go about 3 years, and you had to order the super-precise ones from a jobber, and chill the baseplate casting to extract the old bearings and insert the new ones. Disk platters and heads had to be replaced occasionally. When drives cost $500 per megabyte, you did this. Now you just toss the bad one, or salvage the magnets for your oil pan.
About 1972, doing an online data system for an airfreight company, I would have acquired a BTI 3000 instead of the rented HP 2000E that I bent to my purpose, had I known that BTI existed. I recall I had to write, in HP Basic, 4-function calculations using 2 32 bit floating point mantissas to handle dollars and cents into the millions, and had to handle a megabyte database file with a horrendously crippled HP file system that limited each physical disk file to 11.9 KB, with only 4 files open in a program. Without chaining and common data this would have been impossible.
It still amazes me that HP so crippled an otherwise useful and cost-effective online system. Maybe all the guys with the right ideas went to BTI.
In 1976, on my own, I bought a BTI 10 MB model 4000 and went into the timesharing business, which grew to prosperity until affordable PCs with hard drives were available. I was fortunate to see the inevitable and achieved a soft and lossless landing 10 years later.
Having the hardware skills, I did my own maintenance, right down to replacing crashed heads and platters, and spindle bearings. When BTI refused to tell me what the numeric disk error codes meant, I hacked their system, locked them out of @005, and made some useful OS changes, like patching out the scramble code used in 9-track tape backups, which halved the running time of these daily transfers, a large saving over the years.
Apparently I had at least one sympathizer at the factory, for one day there arrived a large package that contained an assembly listing of the BTI OS. The only thing better would have been the companion Internal Maintenance Specification (IMS).
All this was useful and welcome, although I was not in the habit of trying to fix things that weren't broken, so my patches were mostly minor convenience issues.
We weren't completely divorced; BTI sold me the microcode upgrade that significantly improved 4000 performance.
To support my clients, I wrote a flat-file ISAM DBMS including a RPG-style report generator that provided a high-level language to deal with printouts and complex database manipulation. Some other BTI customer had a database system available, and I got the impression that BTI put more energy into promoting this one. BTI did bring me one client from an Indonesian govt agency, who bought my DBMS and one or more 4000s or 5000s. As far as I know, all this is still sitting unused in some Indonesian warehouse, for I never heard another word from them. Their check was good.
I recall one trip to the BTI factory I was a guest in the home of (forget the fellow's name), whose family pet was a python. When I asked where it was, my attention was directed to a window across the living room, where, sure enough, there was a python draped over the curtain rod. Recently fed, the snake wasn't interested in the guest. You might refresh my memory on the name, and where he ended up.
Overall, the 4000 was reliable and bug-free, requiring hardware attention maybe once a month, with disk failures, HP switching power supply failures, and the occasional memory chip being the primary items. I wrote a little binary memory diagnostic that would finger the bad chip. The system ran 24-7 in a cool basement, and didn't see much dirt, heat or excitement.
One exception was when I had system down for some hours and upon powering up, the system drive, one of those Control Data 10 Meg fixed disks, crashed. Upon disassembly, I found the cause was a spider suicide - the little bastard had crawled in there and got blindsided by a head. No prob - I stocked both platters and heads.
I caught all the fan failures in time, before BTI sent replacement ball bearing fans. The original sleeve bearing fans failed quietly, eventually cooking the cooled item(s), but the ball bearings could be heard on the next block when they started to go bad. I found that a few drops of Mobil 1 good insurance against fan failure of either type.
Even though I had all programs and data on an Ampex 49 MB drive, I continued to use the CDC 10 MB drive for OS and swap files, for performance reasons. This means that the motor brushes on the CDC wore out every few months and had to be replaced, a very dirty job, as some of the BTI hardware guys will recall. I toyed with the idea of adapting a brushless motor to the job, but never got the time. I did add another magnet, which made the motor more efficient and helped a bit with brush life. I bought brushes not from CDC, but directly from a brush manufacturer. They used a mix of carbon and silver, among things. Another item I had to deal with was the Ferranti Inductosyn position sensor and its custom driver chip. Scope mandatory for this.
Towards the end, I was buying surplus 4000s from end users for their parts, especially those HP power supplies, none of which lasted more than a year or two.
The 49 Mb Ampex drives were especially reliable, if you cleaned the platters and heads once a year. I don't recall a single failure in the one drive I put on the system, and ditto the 1/2" tape drive. The original cartridge tape drive was less than perfect, and carts didn't last very long, but it was the best I could afford initially.
In today's environment, with a swiss-cheese Windows connected to every hacker in the world, the BTI 16-bit systems are truly miraculous. Unless there's a backdoor that no one knows about, these systems were impossible to hack through their com ports, and even if someone guessed their way through the primary password, the system owner could install a secondary password of almost infinite complexity.
I think any one of us who have worked on multi-user operating systems stand agape at the monumental ignorance inherent in the design of Windows, once the WWW was in place. I recall several minis featuring a hardware fence between the applications and the operating system. Like the BTI systems, a user could only blow himself up, no one else.
Even with the performance penalty, I have found that the applications development time advantage of using an interpreted language trumps everything else. In the timesharing days, fully half of my revenue came from developing customer applications, not in BTI Basic, but in an interpreted RPG-like language appended to my DBMS system. Application development and debugging time was a fraction of what it would have been in Basic.
In recent years, I got a project to drive an animated LED display beneath a large Foucault pendulum, that had to be synchronized with the pendulum. One previous developer went bankrupt, and the next just quit the project. I chose one of the fastest Basic Stamp processors, with its interpreted BASIC and PC-linked development environment, and had the beast running in a month or so.
Parenthetical note: It appears that BTi's Tom Poulter, jr., was the son of Dr. Thomas C Poulter, who was with Adm. Byrd on two of his expeditions to Antarctica, the last in 1941. For the '41 expedition, Dr. Poulter designed and built the Antarctic Snow Cruiser, a 50-tom diesel electric powered wheeled monster that was supposed to carry a crew of 4 for thousands of miles of unsupported exploration of that snow, ice and crevasse covered continent. It was less than successful, even with a set of chains on the rear wheels, and was abandoned on the Ross ice Shelf when Byrd left. It floated out to sea on a calved iceberg in the 1960s, and is presently somewhere on the bottom of the Southern Ocean.
This would merely be a curiosity, except that quite by chance, I have spent the latter portion of my life working in Antarctica for the National Science Foundation and NASA. My deployment a year ago for NASA was number 15 for me.
While we use light trucks on dirt and ice roads cleared of snow, tracked vehicles are the answer for cross-country travel in Antarctica. Hovercraft were tried, but had their lift deflated when crossing crevasses, and were a handful in high winds.
That's enough trivia for the time being. Feel free to use pertinent bits on your BTI site.