The "T" Stands for Tony!
by Guy Cousineau
TDOS has a long story. This article outlines the steps which led to the development of this operating system. Although it may be of limited use to some people, it can serve to show just what you can do when you set your mind to it.
Several years back (I have no memory for dates), COLECO introduced the ADAM computer. At the time, it was one of the great buys in the home computer arena. Some of the early software that was available for it was CP/M 2.2. Unfortunately, when working with tape drives, CP/M was at best unfriendly. I had a look at it and said "what can I do with this?" and shelved it.
Several months later, Tony Morehen, a long time friend, bought an ADAM and became interested in CP/M. He worked on it from tape for a while; in the meantime, I was still working in BASIC. Once disk drives became available, Tony pursued his interest in CP/M and started work in improving the operating system, especially the BIOS which was not flexible enough to handle all the devices that were, by then, becoming available for the ADAM.
A patch for the BIOS was developed to provide support for a parallel printer. Then a patch to support single sided and double sided disk drives. A few more patches corrected bugs in the allocation vector sizes for the expansion RAM which was used as a virtual disk. A patch was also developed to provide support for 80 column video cards; previously, we used a 32 column TV screen. My interest in CP/M was growing, and I had acquired knowledge of Z-80 code through the total DISASSEMBLY and fixing of the BASIC that came with our machine. Modem programs became available for CP/M and we started acquiring CP/M software for the ADAM. One of the more useful one was a Z-80 assembler.
Re-writing the CCP
Tony embarked on a project which I thought at the time was a futile endeavour. He decided to re-write the CCP. As he worked on it, I helped him debug, re-write, and compress some of the routines. Finally, we came up with a 2K CCP which included a sorted directory function, a built-in copy command which supported 'du', direct drive/user change, and a few more items.
After having such success with that project, we decided to work on the BDOS. Tony looked at P2DOS, SUPER BDOS, etc. He found merits in all those but we thought we could do better. BAsing ourselves on these fine systems, we developed a BDOS much similar to these two but dispensed, at the time, with keyboard scanning (which killed typeahead) and time stamping. Automatic disk logging in was one of the main features we wanted. That first crack at the BDOS was relatively easy and we installed the new BDOS and CCP on our system... now we were playing with power.
We were then ready for the big task... the BIOS. We worked on a combination 32 column /80 column system and re-wrote the entire BIOS, speeding up disk drivers, making support for 4 different disk formats which were now available. Now that we had the entire system in source code we were finally able to get away from the SYSGEN - SAVE - DDT - LOAD -GO sequence which made patch installations very tedious. We could now append a SYSGEN function to the code which would install the entire system in one pass. By that time, we had discovered that the Video Display Processor was capable of handling a 40 column display. I started to work on patching that support code in... eventually, we dropped the 32 column mode altogether.
An Installation Program
Development did not stop there. Tony wrote an installation program which would ask you about disk drive sizes, serial port settings, default colours, macro key configurations, I/O byte settings, etc. prior to installing the system. Now the user did not need to install patches at all. When system configuration changed, they only needed to re-install the system.
SUBMIT was another thorn in our side. IT WAS SLOW! We worked on a new type of submit which worked like BAT files in MS-DOS. File date stamping was introduced. Support for 32 users became a necessity when we developed the software for a hard drive controller card. Finally, the installation program was made smarter by scanning the network and configuring the system based on the devices which it found. We added named directories which came in very handy on a hard drive.
We ran into incompatibility problems: different disk drive specifications, different hard drive interfaces, different clock chips, different 80 column installations, etc. TDOS is now available in several configurations to handle 80 or 40 columns, version 1 or 2 of the hard drive interfaces, hard drives with 4 or 5 partitions, etc.
Terminal installation also became a problem. Inexperienced users were having difficulty installing programs for 10 or so different 80 column terminals. We developed a standard header for ALL TDOS programs. Each user requires one terminal overlay which he can MLOAD to all our programs. We extended this approach to our generic CP/M development. This has made it quite easy for the average person to install and use our programs.
The Complete TDOS
TDOS now comes with a complete set of utilities:
These utilities along with the TDOS system replace all the utilities which came with CP/M 2.2. We have also written several other utilities to help get the most productivity out of CP/M. Some of latest TDOS development include ZCPR. A few people use it but I find that with what we have in TDOS right now, we don't need to go to ZCPR unless we want to use some of the advanced features of that system. Our next project is to go to CP/M 3.x emulation by introducing bank switching and the other advanced features.
TDOS: Yours to Share In
The nice thing about TDOS is that is is FREE. We would have done it just for ourselves anyway, so why not share it. Its development has taught me a great deal about machine language programming. I am also becoming an expert on writing FAST and COMPACT code. Now that I have the CP/M bug, I don't know why I would ever warn to change operating systems.