Oddly enough, this was exactly the opposite of what Apple did in Apple DOS.  Apple published the APIs to read and write sectors (RWTS), but never published the “File Manager” APIs that allowed access to the file system through means other than passing commands through the character output vector (e.g., the BASIC statement PRINT CHR$(4);”OPEN FOO”).

I’ll mostly describe how things work in Model II TRSDOS 1.2, the earliest version I’ve been able to obtain.  I haven’t studied 2.0 nearly as much yet.  The TRSDOS 1.2 “kernel” consists of three parts, while later versions are more monolithic.

The Model II boot ROM loads all of drive 0 track 0 (single density, 26 sectors of 128 bytes) into memory starting at 0e00.  First it looks for the four characters “DIAG” at 1400 and “BOOT” at 1000.  If either are missing, it refuses to proceed.  It calls the code at 1404, which in TRSDOS is a simple hardware diagnostic.  When that returns, it jumps to the first stage boot loader code at 1004.  Some other operating systems don’t bother with a diagnostic, and just start their boot code at 1404, never returning to the ROM.

The first stage boot loader actually understands the TRSDOS filesystem enough to find the directory entries of files in TRSDOS load module format, and load them into memory.  In 1.2, it loads “IODVRS/SYS” and then “TRSDOS/SYS”, and jumps into the latter.  The Model II TRSDOS filesystem is similar in many regards to that of Model I TRSDOS, but not enough to actually be compatible. Unsurprisingly, it looks like an intermediate step in the evolution from Model I TRSDOS to Model III TRSDOS.  As in Model III TRSDOS, files can only have a single directory entry, with a limited number of extents.

IODVRS/SYS contains, as the name implies, the low level I/O drivers for the system, including the keyboard, display, printer, and floppy drives, the dispatching for system (SVC) calls, and a few utility SVCs.  However, it only contains the SVC handlers for services 0-28, the I/O functions and basic utility SVCs.  Note in particular that it contains no file system code.  IODVRS/SYS is conceptually similar to the CP/M BIOS, though lacking CP/Ms charming simplicity.  IODVRS/SYS provides several undocumented SVCs for internal use by TRSDOS, including floppy subsystem initialization (13), floppy sector read (14), and floppy sector write (16). Note that at the time IODVRS/SYS is loaded, no call is made into it to initialize it.

TRSDOS/SYS, however, is called after being loaded.  It basically performs the TRSDOS initialization that only has to happen at boot time.  It has another implementation of filesystem reading and load module format handling, very similar to what is present in the stage 1 boot, but now instead of talking to the FDC and DMAC directly, it uses the undocumented floppy SVCs described previously.  After various initialization, it loads SYSRES/SYS and jumps into it.

SYSRES/SYS contains the filesystem code and other relatively high-level TRSDOS infrastructure code.  It generally relies on SVC calls into IODVRS/SYS to perform all I/O, and has very little other dependence on IODVRS/SYS internals.  This is conceptually similar to the CP/M BDOS.  It loads system overlays to handle some SVCs and user commands.  Overlays SYS0/SYS through SYS9/SYS are small overlays, occupying one disk granule (five sectors) and loading into 2200-26ff.  Other overlays may be larger, and load at 2800 or higher.  Many of the overlays do depend on knowledge of the internals of SYSRES/SYS, directly accessing subroutines and data structures without the use of vector tables or the like.  This means that SYSRES/SYS and the overlays must have been built at the same time, and would generally not be interchangeable with earlier or later releases.

Anyhow, getting back to the paranoia part.  Someone apparently decided that simply not documenting the SVCs that provide sector-level access to the floppy was not sufficient to thwart those that might want to bypass the filesystem.  After TRSDOS/SYS uses those SVCs for its part in the boot process, it actually removes them from the SVC vector table, and sets up jumps to them at undocumented internal TRSDOS locations 1130 (read sector) and 1133 (write sector).

In TRSDOS 1.2, access to all of the system files, including overlays, is done through the file system.  The system files have normal file system entries. Unlike Model I TRSDOS, neither the system file directory entries nor the file contents need to be in any special location on the disk.

In TRSDOS 2.0, things are much more monolithic.  The stage 1 boot code only loads and jumps into a single file, SYSRES/SYS.  The boot code does not care where this file is located, but other parts of the system do.  All of the overlays, small and large, are stored in a single file, SYSTEM/SYS, which is required to start on the track after the primary directory.  The first sector of SYSTEM/SYS contains a kind of overlay directory that gives the track and sector numbers at which each overlay starts.

There is perhaps some advantage to putting all of the overlays in a single file, since the number of directory entries on the diskette is limited to 96.  However, the need for a second, special directory mechanism for overlays is ugly, even if it is only a simple one.  Requiring the system files to be at fixed locations on the disk (at least relative to the primary directory) might be a reasonable requirement if it yielded some performance gain, but it generally doesn’t.  (With 1.2, the system files are set up when the disk is formatted, so even though they could be anywhere, in practice they are grouped together.)

TRSDOS 2.0 introduced changes to the disk organization, such that TRSDOS 1.2 and 2.0 diskettes are not interchangeable, except that the 2.0 XFERSYS utility can convert a 1.2 diskette to 2.0 format.  The disk organization changes are basically gratuitous, and don’t provide any benefit to the user, while obviously being a great inconvenience to users with TRSDOS 1.2.  They mashed the GAT (granule allocation table) and HIT (hash index table), which were sectors 1 and 2 of the directory track in 1.2, into just sector 1 in 2.0.  In 1.2, the directory occupied sectors 3-26, while in 2.0 it occupies sectors 2-25.  The only apparent rationale for doing this is to free up sector 26 on the directory track.  In TRSDOS 1.2, sector 26 was not used on any track but the directory track, for any purpose.  In TRSDOS 2.0, sector 26 of every track is used to store five bytes of unique disk ID, to better detect disk changes.  (it has been suggested that those bytes might also have been used for software copy protection.)  However, rather than mashing the GAT and HIT together, which made it impossible to support larger disks such as double-sided disks, they easily could have special cased the directory track(s) and stored the disk ID in either the GAT or HIT sector.

TRSDOS 4.0 introduced much larger changes to the disk organization, in order to support double-sided disks and hard disks.  I haven’t yet begun to dig into the 4.0 code.

ksim 0.2 is now released under the GPLv3 license.  While ksim may be minimally useful in its current form, it is primarily intended as a reference implementation. There is currently no documentation, and the code is not well-commented. Maximum performance was not a goal, so very little optimization has been done. Interrupts are not implemented, though they would be easy to add. There is crude console I/O, and extremely crude disk I/O. It works just barely well enough that I’ve successfully run CP/M.

There was a bug in “POP PSW” setting the parity flag wrong, which screwed up all of the CRCs.

I had the polarity of the AF flag wrong for the subtract, compare, and decrement instructions.

In the DAA instruction, to determine whether to correct the high nibble, at one point in the logic I was using AF when I should have been using CY.

While it remains possible that the simulator could contain some errors not caught by the exerciser, at this point I’m fairly confident that it is working correctly. W00t!

It’s easy to find an electrical replacement, but difficult to find one that is the same physical size as the original.  There has been so much advancement in capacitor technology since 1976 that the modern ones are less than a third the volume.

The purpose of getting it running on the Sol-20 isn’t that I think there’s anything wrong with my Sol-20, but rather that the 8080 simulator doesn’t generate the same hashes, so I probably don’t have the condition code computations correct. Once I’ve verified that it works and produces the correct hashes on the Sol-20, I’ll further modify it to output the bytes being hashed into the CRC, and compare those with the simulator.

I hooked up the serial port of the Sol-20 to a null modem adapter and USB-to-serial adapter plugged into my laptop. The first thing I discovered is that the Sol wouldn’t accept the Solos “SET I=1″ or “SET O=1″ commands to set the input or output to use the serial port. It didn’t seem to accept any SET commands at all. Probably the personality module has a modified version of Solos with a disk bootstrap.

I have five simple personality modules: two PM-5204, two PM-2708, and one from Golemics with two 2708 EPROMs.  I also have a dual personality module from Micro Complex, which has a switch to select between two sockets, which, provided that the Sol has a modification installed, result in one selection being mapped at C000, and the other at F000. The modification moves the Sol’s video RAM and scratch RAM in that block also, so in the F000 position, it provides for 60K of contiguous usable RAM. The F000 ROM may also be modified to support the Micro Complex 80×24 display daughterboard. Jim Battle’s excellent Sol20.org has a PDF of the manual for the dual personality module, as well as the source code and hexadecimal image of the Micro Complex ROM.

I’ve taken photos of the six personality modules.

The Micro Complex personality module appears to be the only one I have with a standard Solos image; it has the Processor Technology masked ROM in the C000 position. I’m currently using the Sol that does not have the 80×24 display daughterboard, nor the modification to relocate the C block to F, but using it with the C setting works and gives me the standard Solos, so I can use the SET I and O commands. Now I can download code into the Sol over the serial port from the laptop.

Two of the keyboards had foam pads with mylar disks on both sides, as I expected, and those foam pads remove easily. Unfortunately two of them had mylar disks on only the bottom side. As a result, when the foam deteriorates, it winds up stuck to the plunger, so those two keyboards will require a lot more effort to clean up.

I was somewhat surprised that even the keyboards with mylar on both sides of the foam still had some sticky keys after the pads were removed. I suspect this is due to dirt getting between the plunger and shaft. I probably need to take all four completely apart and clean all of the mechanical pieces thoroughly. I’ll have to test whether 97% isopropyl alcohol will damage the keycaps, stems, or frames.

One Sol-20 has now been reassembled with the repaired keyboard, and seems to be working fine, aside from the previously noted instability during the first few seconds after powerup. I need to look at the power supply output on a scope to see if it has a problem.

I’ve taken various photos of four Sol-20s in various stages of disassembly. One of them has some nice labels from Micromation on the top backplane connector giving designations of all of the S-100 signals. Another has two daughtercards from Micro Complex, one adding a 80×24 video mode, and one replacing the standard 8080 microprocessor with a Z80. That machine also has the Micro Complex dual personality module, and probably has the modification to allow relocating the ROM, video RAM, and scratch RAM from Cxxx to Fxxx.

One of the Sol-20s came with a Compupro RAM 17 64KB static CMOS RAM card.  I put it in the Sol-20 with the S-100 labels.  The video seems to be unstable for the first ten seconds of operation, but settles down.  It seems to basically work OK.  The only NTSC monitor I had at hand was a Sony KV-1380 Trinitron color TV. It works, but the monochrome bandwidth isn’t really satisfactory for 64-column text. I’ll have to dig a monochrome monitor out of storage.

Naturally the foam disks in all four capacitive keyboards have gone bad. Each keyboard has a few keys that work OK, a few that work sometimes, and many that don’t work at all. Only one had enough keys working to check that the Solos firmware works.

The newer two keyboards use Phillips screws, which are easily removed. The older two use a strange screw head I’ve never seen before, which is like a slotted, but with a round hole in the middle. The slot is too narrow for any of my normal screwdrivers. Jeweler’s screwdrivers will fit the slot, but are not wide enough to stay in the slot, rather than slipping into the hole in the middle.  I managed to remove 6 of 18 screws from one keyboard before giving up.

Tomorrow I’ll put the new foam disks into one of the keyboards.

In fact, FSK modulation is almost trivial, so I had the encoder written in less than an hour.

For decode, I decided to use the Goertzel algorithm, which is a simplified DFT that only looks for a single frequency.  I’ve used the Goertzel algorithm before on fixed-point DSP processors. There are app notes on using it for DTMF detection.  For FSK demodulation, I just use two Goertzels, one for the space frequency and one for the mark frequency.  The audio samples are dealt with in windows that are a fraction of a bit time, and the levels indicated by the two Goertzels are compared to decide which frequency predominates in that window.

Implementing the decoder program took a few hours last night and a few hours today.  It’s now basically working, at least for the perfectly sinusoidal waveforms generated by my encoder.  I still need to test it on some real tapes.

I’m currently using an 8 kHz sample rate for my audio files, although the encoder can be told to use a higher sample rate if desired, and the decoder will work with whatever sample rate the audio file uses.  Since the FSK frequencies are 1200 Hz and 2400 Hz, there should be no advantage to using a sample rate higher than 8 kHz.

I’m currently using libsndfile to read and write audio files.  I’d like to also use PortAudio to support direct access to the audio hardware, but I haven’t yet tried that.  While I’m doing the development on Linux, in principle the programs should work if compiled on Windows or MacOS.

I’ll release the programs under the GPLv3 license when I’ve verified that they work reasonably well.