Speeding up my floppy disc drives by modifying the disc controller ROM code was a delicate balance of adjusting the delays in the code so that wasted delays were removed without affecting the drives ability to function.

Not realizing one of my development diskettes were still in the drive, I sped the drives write speed up to 2ms. I executed a DIR command and in 2ms my file allocation table was completely wiped out!

It took 30 hours to learn how a file allocation table was designed and rebuild it.

On the upside I learned that 4ms was a much safer speed for the drive to operate at.

Approximate Date: 1983-1985                    Computer: TRS-80 32K Color Computer (6809E CPU) .5 – 1 MHz

Tools & Technologies that didn’t exist: Internet/Intranet, PC level relational databases, Visual development tools, Data management tools, User management tools, Consumer hard drives, SSDs, Thumb drives.

Historical remarks: Networking was limited to expensive RS-232 networks or PC to PC - RS-232 telephone connections. The concept of multiple personal computers connected at once was cutting edge. IBM PC’s were in their infancy and were just beginning to appear in business but were still largely unknown even in business. Radio Shack, Commodore & Apple PCs dominated the home market while the $10,000 Macintosh Lisa was the “upwardly mobile” business machine. Hard drives were mostly inaccessible to the masses and most personal machines featured memory capacities of 32k to 64K.

BBS Basic
In the early 80’s I was a “Hacker”, a term that referred to someone who explored the capabilities of a machine to extremes. One of the biggest challenges for Hackers of the day was the construction of a Bulletin Board System, also known as a BBS, was very similar to what we now call forums and occasionally featured other services in addition to forums. Since the internet didn’t exist the only users who could access a BBS were users with modems, usually in the 300 baud range.
Most BBS’s consisted of such internal systems as user management and access control systems, huge data management & manipulation systems and intrusion detection systems. These systems were built in BASIC. The BBS communications drivers were another story and that’s where BBS Basic came in.

BBS communications relied completely on the ability to bring data from the RS-232 port of the computer, where the modem was connected, directly into the computer’s normal operating environment so that any key pressed on the remote user’s keyboard would appear on the host computer as though it was typed on the host keyboard. This was the job of the BBS communications driver which was also referred to as an RS-232 communications driver at the time. BBS drivers came with security risks if the remote user gained access to the language level prompt which could happen if the code error’d out. There was no “On Error” functionality in most of the languages back then so you had to build bulletproof code or have some other mechanism in place for security. There were also tasks in BBS communications that fell outside the realm of simple keyboard transposition such as uploading, downloading and a host of other features that I wanted to support so I opted to go beyond the simple BBS communications driver and build an entire language extension.

BBS Basic was written entirely in 6809E Assembler. It extended the BASIC programming language by adding 25 brand new commands and 12 functions to the core language, all of which were about improving the job of building a BBS.  Some of these features included;

The result was a BBS that could communicate natively with any other computer that used an 8 bit character set and it could do it so seamlessly that you would argue you were communicating with the same machine as yours. It had a much higher success rate at uploading and downloading files than many other BBS’s of its day, had far greater speed and disc capacity than BBSs of its day and if you could manage to break in to system prompt level where you could cause some trouble, you got disconnected and the system would go into lockdown!

BBS Basic was deployed in a BBS I named, “The Exchange” in reference to the BBS’s ability to bring dissimilar technologies together. Although a TRS-80 “CoCo” BBS, it became very popular with the Atari community, many of which swore I was lying about it being a TRS-80 computer. This because unlike most other forms of ASCII, ATASCII featured cursor movement commands in its control characters. The BBS could process those ATASCII commands and the forums would store them in the forum posts for playback to other ATARI users. In addition to the forums, the system featured a live chat function with the operator (ME), 3 full text based adventure games people could play while online and a full upload/download system.

The access application system featured the first incarnation of what I called, “The Brain file” which was a file. Access to the system was by online application and information about users that were rejected or kicked from the system was added to the brain file to facilitate auto rejection of any future attempts to gain access approval which was a common event. Every time a user tried to fool the application system and failed, all of their details would be added to the brain file. Since approval required at least one piece of verifiable data, eventually the system would have collected all of your verifiable data items. The more you tried to deceive it, the more it learned about you.

Copy Protection code
In preparation for marketing the languages extension as a product, I designed copy protection mechanism comprised of a scrambler, loader and decoy loader self-destruct all written in raw assembler.

The scrambler was a simple tool that wrote the parts of the file to random locations throughout the disk and then wrote a custom encoded file loading order table in a hidden location on disk. Since the file allocation table of the disk was never written to, the disk appeared empty.

The loader program was designed to locate the hidden file loader table, decode it, load the modules into memory and execute the program but the loader program was booby-trapped to self-destruct if tampered with using a special feature of the 1793 controller chip in TRS-80 Color computer. The Western Digital 1793 disc controller chip, still in use on many controllers today, utilized a vectoring process whereby an execution address could be fed to the 1793 controller registers and after allowing 1 instruction for processing, the controller would force the new address onto the Instruction Pointer causing the CPU to jump to that address for processing. That’s what would happen internally, but from an Assembler instruction perspective, it would appear as nothing more than a value being stored in a memory location, nothing more. The instructions following the storage commands were disc self-destruct instructions. If the code proceeded unmodified, the 1793 controller would force the execution away from the self-destruct but if the code had been traced and modified to bypass security checks, the 1793 controller’s vector wouldn’t happen and the disc would be destroyed.

ResearchDisc Controller ROM Assembler code
This work involved the analysis of all of the Assembler code in the ROM for the TRS-80 Color Computer. This was the only way to find the areas of the disc ROM that had been DE-optimized to account for poorly aligned drives and to locate the sector limiter.

The manipulation of the 1793 controller chip involved ordering the data sheet for the controller chip directly from Western Digital and analyzing how the CPU interacted with the controller.

© John J Goodwin, 2013
You can contact me at http://ca.linkedin.com/in/developergoodwin/