Rescuing more Dick Smith software with a System 80, three drives and an HxC SD floppy disk drive emulator

Introduction

In the course of searching through a pile of System 80 books, I came across a set of original Dick Smith disks I'd forgotten I had. Someone had sent me three disks constituting an Accounts Receivable package (Figure 1). The disks were mouldy and in poor condition. I'd obviously laid them in this box, with a view to getting back to them later.

Figure 1. Dick Smith's Accounts Receivable - Hardly exciting but worth saving

"Later" had finally arrived. Recently I'd added new material to my System 80 site, so it was a topical find. The System 80 website has a Dick Smith software section and this package wasn't on it. Even products as boring as Accounts Receivable are worth saving from oblivion, given the Dick Smith System 80 is part of Australasian computer history, and Dick Smith himself had commissioned the work.

The disks being dirty, single density, in some unknown TRS-80 Model 1 format and possibly copy protected. Consequently I rated my chances at less than 50:50. However, what's life without its challenges!

Cleaning

I've found floppy disks don't seem to be harmed by a gentle clean in soapy water hence I did just that to remove all the loose media and fungi. Soon I had dry, clean disks to work with. To keep them that way. I put them in clean, blank sleeves. It's likely that the sleeves of the original disks contained as much gunk as I had washed off. I didn't want the freshly-washed disks recoated with this.

Checking and copying

I know from experience that although one of my old PCs with a 360k drive will read single-density disks, I cannot read or write TRS-80 Model 1 single-density media due to the Track 17 DMA 0xFA problem. This means I couldn't use David Keil's emulator to check or image the disks (in fact, I did try it). Time to haul the System 80 out! The old workhorse was unpacked and set up, initially with two single-sided, 40-track drives (Figure 2).

Figure 2. System 80 in full 2-drive configuration

I checked the disks out. As expected the first was self-booting. However, what was unexpected was that it required the second program disk in drive 1 and, during this initialisation phase, it tried to WRITE to that disk!! WHOA! I didn't want these original disks altered so I was thankful I'd covered all disks with a write-protect tab.

Wanting to preserve the original disks as "original", I felt it best to make working copies before I checked out the software any further. Checking with NEWDOS/80 V2 I could see a directory on all three disks. That made me hopeful that most if not all of the contents survived the washing process. Consequently I used a program called "Copycat" by Larry Nedry (great program BTW!) to make exact disk copies (Figure 3).

Figure 3. Copycat in action. So simple to use!

Copycat seemed to duplicate the disks without error! The originals were stored away, and I now just worked with two copies...one unaltered copy which I would image, and the other I'd explore the software with. Playing with the latter I found I could boot the package to completion, set up an user account, enter data, see menus and exit the program to a DOS prompt, which seemed to TRSDOS although the full version was not there (see "Final thoughts" at the end of this article).

Imaging adventures

So, having secured working copies, now came the problem of how to image them. The plan was to copy the real disk contents, sector by sector, into blank images using the HxC SD floppy drive emulator. To this end I disconnected the two physical drives and in their place added my HxC SD floppy disk drive emulator, and a bare drive I had configured to be drive 2 (i.e. the third drive) on the daisy chain (Figure 4).

Figure 4. HxC SD Floppy drive emulator (as drives 0 and 1) and one physical drive (as drive 2)
(Note the top SD reader is actually a FreHD!...not used in this project)

First attempt using TRSDOS 2.3

Using Matthew Reed's TRSTools I made three blank 35-track TRSDOS 2.3 images to hold the three disks. These images were converted to HFE format for the HxC emulator and copied to its SD Card. With the appropriately named blank disks mounted in the emulator's drive 1, I booted with TRSDOS 2.3 in HxC virtual drive 0 and the physical disk to be copied in drive 2. I then tried a whole disk copy from drive 2 to drive 1 using the BACKUP command.

Hmm.... That didn't work. BACKUP was unable to write to the blank image.

Second attempt using NEWDOS/80 V2

I tried again, but this time using NEWDOS/80 V2 formatted blank images. Although formatted, with NEWDOS, the PDRIVE specs were the same as standard TRS-DOS 2.3 parameters except 40 tracks were used not 35. After the images were ready I used NEWDOS's COPY command to copy the whole disk sector by sector. This appeared to work but in reality only for one disk. Let me explain...

The HxC SD unit came with software that allows a disk image in the HxC's native format (HFE) to be exported as a DMK or JV3 file, for use in TRS-80 Model 1/III/IV emulators. As the copies were now in HFE format, this conversion was the final step. The program disk for drive 0 converted just fine. I could see a directory in TRSTools and the disk would commence booting in the TRS32 emulator (see Figure 5) until the second disk was needed.

Figure 5. The first disk image part way through its boot sequence.

However, the other two exported images (Program disk for drive 1, and the data disk for drive 1) were faulty. TRSTools reported a unreadable format. I could see files in the HFE images using the HxC SD on the System 80, but those two disk images wouldn't export out to DMK or JV3 format despite numerous attempts.

Weird. Why was first one ok, but the second and third faulty, even though I'd copied and exported them in exactly the same way?

Work around

In the end, I solved the problem by copying file by file from those two errant disks into blank images, rather than sector by sector. HFE images produced this way successfully exported out to DMK.

I almost left it there, but decided on one last step. I noticed that the first DMK disk image (the one that was successfully copied with a NEWDOS sector-by-sector COPY command), was in LDOS/LS-DOS file format (at least according to TRSTools). However the second and third DMK images (where I'd copied into by file), were, understandably, in NEWDOS/80 format. Although probably not important to the operation of the software (which was entirely in BASIC), I figured it was good to be consistent and have all three images in the same underlying file system format. Consequently, I created two blank images using TRSTools, extracted the files from the NEWDOS formatted images and added them to the blank LS-DOS/LDOS ones.

So, the eventual result was three disk images in DMK format, readable by TRSTools and emulators like TRS32, and all using same file format. I spent some minutes trying out the menus (Figure 6). Everything seemed AOK.

Figure 6. Main menu in Dick Smith's Accounts Receivable

I could now add the package as a writeup and download, to my System 80 site. Now, if only someone could unearth the manual! (:

Final thoughts

Although an accounts receivable package generally doesn't stir up much nostalgic excitement, I was pleased to have rescued this old software from oblivion. It's important to note that due to the way the disks were imaged, the image files may not be EXACT byte by byte copies of the original disks. The disks were not copy protected however, and there appeared to be no "funny" sectors. All files seem present and accounted for. The underlying OS (which is never referenced) seems to be a minimalist version of TRSDOS. On <E>XIT, the accounts receivable package exits to a "DOS READY" prompt after telling the user to "Press Reset button to restart". However, although LIB and CLOCK work, most of the standard TRS-80 2.3 commands (including DIR) do not. The system reports that the file cannot be found. These behaviours are consistent whether or not it's the images or the physical disks being used.

It could be that the DOS is damaged due to degradation of the original disks. However I think it's more likely that it was simply a sub-set of TRSDOS...enough to make the accounts receivable package work, but not enough to risk a copyright suite. There is no mention of TRSDOS on the disk labels or anywhere on the screens. It's likely Dick Smith would be in trouble legally if a full version of TRSDOS was included.

Tez
14th January, 2018