STEbus Z80 and FDC CP/M

The disk was labelled (presumably by someone at Arcom)

"BSCA-35 User 0 Normal Files User 1 Additional files for SGT1 driver"

The zip file contains 18 files, and grep returns no instance of the string "SGT1" in them.

I can see "SGT1" in the binary disk image, using ghex. So where did it go?

The directory area looks like this:

.db    $ff,"READ    ME ",            "___",$0c,$01,"_______________"
.db    $ff,"ATLAS   MAC",            $01,"__",$35,$02,$03,$04,$05,$06,$07,"__________"
.db    $ff,"ATLASV  MAC",            $01,"__",$56,$08,$09,$0a,$0b,$0c,$0d,$0e,"_________"
.db    $ff,"BOOT    ASM",            "___",$;21,$0f,$10,"______________"
.db    $ff,"CHARIO  ASM",            "___",$15,$11,"_______________"
.db    $ff,"CHARIOV ASM",            "___",$33,$12,$13,"______________"
.db    $ff,"COPY    M","A"+$80,"C",  "___",$45,$14,$15,$16,"_____________"
.db    $ff,"DISKCOPYM","A"+$80,"C",  "___",$64,$17,$18,$19,$1a,"____________"
.db    $ff,"DISKFORMMAC",            $01,"__",$2d,$1b,$1c,$1d,$1e,$1f," __________"
.db    $ff,"DRBIOS  MAC",            "___",$11,$21,"_______________"
.db    $ff,"DRVTBL  A","S"+$80,"M",  "___",$02,$22,"_______________"
.db    $ff,"FDPH    ASM",            "___",$18,$23,"_______________"
.db    $ff,"FLOPPY  MAC",            "___",$46,$24,$25,$26,"_____________"
.db    $ff,"LDRBIOS MAC",            "___","S",$27,$28,$29,"_____________"
.db    $ff,"MEMORY  MAC",            "___",$1b,$2a,"_______________"
.db    $ff,"SYSCOPY M","A"+$80,"C",  "___",$4D,$2b,$2c,$2d,"_____________"
.db    $ff,"TIME    ","A"+$80,"S"+$8,"M",    "___",$02,$2e,"_______________"
.db    $ff,"TIMES   A","S"+$8,"M",   "___",$16,$2f,"_______________"
.db    $01,"READ    BAK",            "___",$01,$30,"_______________"
.db    $01,"READ    ME ",            "___",$07,$31,"_______________"
.db    $e5,"ATLAS   REL",            "___",$14,$32,"_______________"
.db    $01,"ATLAS   COM",            "___",$11,$34,"_______________"
.db    $e5,"CH      ASM",            "___",$04,$31,"_______________"
.db    $e5,"ATLAS   COM",            "___",$11,$3b,"_______________"
.db    $e5,"ATLAS5  MAC",            "___",$05,$33,"_______________"
.db    $01,"ATLAS   MAC",            $01,"__",$3b,$3c,$;3d,$3e,$3f,$40,"A__________"
.db    $01,"CHARIO  ASM",            "___",$15,$42,"_______________"
.db    $e5,"CHARIO  BAK",            "___",$15,"C_______________"

where underscore represent $FF.

The entries starting with .db $ff match the 18 files we have.

The others are allowed to have duplicate file names if they have different starter bytes ($01 or $E5).

indicates that
$e5 is a free slot (entry has been erased?)
$00 belongs to user 0
$01 belongs to user 1

so that identifies the extra files that need retrieving. Steve managed to recover the two files that were recoverable.

The simplest boot ROM and BIOS uses a serial port as a user interface. This connects to a terminal or a terminal emulator.

There are source code files for generating software that uses either of the two text-based video boards, the MVS1 (48x16) and the MVS2 (80x20).

An operating system needs a real-time clock for time-stamping files. Without one, the user needs to enter the date and time at start-up. The Z80 processor boards did not have an RTC onboard, but there was a battery-backed CMOS RAM board with an RTC on it, called the SCRAM.

The source files include TIME.ASM (no clock) and TIMES.ASM (time from SCRAM board).

I shall make a project for the SCRAM board soon.

It had up to 48K of CMOS RAM (six 8K chips), a NiCAD battery and an MC146818 clock. This has a large DIP24 footprint, hence it often got left off designs.

These day designers have RTC chips in DIP8 packages. The BIOS might be modified to use such a device.

Hurdles:

• CP/M formats differ from MSDOS
• CP/M formats differ between CP/M machines
• Modern PCs no longer have floppy disc interfaces
• USB-based floppy drives use PC formats but no others

Steve has found a way to read the CP/M disks without a CP/M system, by using the Linux command 'dd'

He said:

"It was quite easy in the end, once duff floppy disks were eliminated from the equation. Once I discovered the Linux 'dd' command it all fell into place. Although I explored the Linux 'fdutils' (and they revealed some interesting stuff about how the FDD parameters are stored in the PC BIOS CMOS) it is only the 'dd' command that was needed. Details are here: https://www.linuxscrew.com/linux-dd-read-write-floppy-images
I used the command: 
sudo dd bs=512 count=1440 if=my-image.img of=/dev/fd0
to read a disk, and to write a disk: 
sudo dd bs=512 count=2880 if=my-image.img of=/dev/fd0
I also have disks with TurboPascal, Pascal MT+ and MIXC, so once we both have working systems there will be some options for software development!"

Having got the disk images, it is desirable to read the files. Ghex shows the sources files are mostly in contiguous blocks,  but some are fragmented. Steve reports:

"The tools that I downloaded didn't help so I used Ghex to examine the disk image.
The directory starts at offset 1200 (hex), each entry being 32 bytes in length.
Each entry has a list of the 4096 byte blocks used by the file (at directory entry address + 16).
From this I navigated to the first block and copied from there to the 'END' statement. job done!"

Looks like it would be fairly simple to write a small program to do this automatically.

You will need an old PC with a floppy drive. My PC, which was assembled in 2007 does not, so I need to find an even older machine in my junk pile and get it running Linux.

Right now, the disks are being read by Steve. I hope to be able to recreate them with Linux tools.

In the future, it would be convenient to have CP/M in ROM, and avoid the need to boot from floppy drives. This has been done for a Z180 board, so it is possible with a 512K ROM but that is only about half a disk. The OS and user program has to fit in a 64K memory space, but there is little point in having a disk operating system without any disks (real or virtual) to use.