Binary Dinosaurs Computer Museum
button1Museum History button2Museum Updates button3BinarySaurs on Twitter button4Adverts&Reviews button5Moan, Bitch, Gripe scroll1
button6Inhabitants button7Reviews button8WOW! button9Contact button10Recursion 2017 scroll2
button11Links button17Floppy Recreation button13BDonFacebook button14CGE-UK 2004 button15WROCC 2006 scroll2
button16DECBOX button12Retro2017 button18Floppy Recreation spaaaaace spaaaaace scroll3
base blank_textbox

Exidy Sorcerer Disk Imaging
Like the RML380Z before it it seems that restoring and preserving a 40 year old machine involves an awful lot of learning, late coding sessions, swearing and a hells of a lot of reading, forum postings and asking people questions. Then a dance when it all comes together :D
After the Retro Weekend In Sept 2018 it was obvious I needed to preserve the contents of my Sorcerer floppies, a task made all the more difficult by them being hard sectored which means the only thing that can read/write them is a Sorcerer. However, it being a CP/M machine (and like the 380Z) it should be possible to transfer things via the RS232 port to a PC.
From the Supervisor monitor it's possible to redirect input and output with SET I= and SET O= commands, this coupled with modifying the tape/serial port behaviour with SET T=2 (1200 baud RS232) meant that it was easy to dump RAM contents and transfer programs to/from a local PC with a serial port. However it's different from CP/M which has its own set of I/O routines and devices. Usually redirection is possible using logical names which map to different I/O ports, eg RDR: is a 'paper tape reader' while LST: is a 'printer'. In reality these are I/O ports on the Z80 CPU which map to physical interfaces. It took me a long while to realise the Lifeboat CP/M 2.2 I was trying to transfer things with didn't have any logical redirection at all - everything was mapped to the CON: (console) device.
Exidy CP/M 1.4 was different though, and the RDR: device was sufficient to transfer compiled HEX programs to the Sorcerer which could then be converted to running images with the LOAD command. I found a set of programs on Mike Douglas' site which he wrote for the Processor Technologies SOL-20, very similar to the Sorcerer in implementation and use of the Micropolis hard sectored S100 bus floppy drive controller originally designed for the Vector Graphics line of CP/M machines. This utility reads raw sectors from a floppy and transfers it over to a host PC using the venerable XMODEM protocol designed by Ward Christensen in the early 80s. There followed 3 weeks of experimentation, coding, reading, questioning, more reading, testing assemblers, simulation, emulation before I finally found a workflow that would let me fairly quickly make code modifications to Mike's flop2pc utility then assemble on a virtual Win7 machine in a CP/M emulator, FTP the resulting files to a central fileserver which I could then download to an XP machine that had a serial port. Finally I could transfer down to the Sorcerer using an application called RealTerm.
On the Sorcerer the sequence went:
(RESET to Monitor)
GO BC00 (to CP/M)
(transfer file over serial)
It takes an hour to transfer 330K's worth of disk data at 1200 baud :D
My remaining problem is the flop2pc utility creates raw images of the floppies in a format used by Vector Graphics so there's enough differences for them not to work in a Sorcerer emulator, but hopefully that's a fairly easy change to make.
The day after getting flop2pc working I discovered I'd had a firefox tab open on Dave Dunfield's file transfer utilities page. Dave is the excellent bloke behind the ImageDisk utility which has become the standard in archiving floppy media. One of the tools staring me in the face was CPT, a utility that consists of a tiny CP/M program that communicates with a server running on a host PC and can read or write disk images over RS232! After turning the air blue for a bit I quickly modified the stub program to use the Sorcerer's I/O routines and it worked first time. Grrr.
The perennial problem for older micros these days is the availability of floppy media. The Sorcerer needs 16 sector hard sectored* disks which are like hen's teeth these days. There are a couple of methods of getting around this. Chuck Guzis of Sydex Inc who's well known for authoring ANADISK and 22DISK back in the 80s for dealing with the multitude of different CP/M disk formats produced a hole punch for making 10 and 16 sector floppies out of DSDD soft sectored media. There aren't many of these punches left. Mike Douglas needed something to allow him to use soft sectored media so he came up with the Virtual Sector Generator which in his own words "sits between a 5.25" hard-sectored floppy controller and the drives to allow transparent and interchangeable use of soft or hard sectored media." Obviously I bought one ($40 for the kit, bargain) and put it to use after a brief period of wielding a soldering iron - it worked first time and after a lot of sampling managed to copy my Sorcerer CP/M 2.2 disk to a spare soft sectored floppy I had lying around. Clearly I need better soft sectored floppies too but at least they're more plentiful, and I'm hoping at some point I can use a Gotek floppy emulator.

(*the difference between hard- and soft-sectored disks is hard-sectored have 10 or 16 index holes in the disk to mark the beginning of each sector. Soft sectored is more complex and needs a whole different controller but only has a single index hole, this means a single controller can access several different floppy drive geometries.)
I happened across a page on replacing 8" floppy drives with 1.2MB 5.25" units and it explained in detail how the density select/speed select/ready/index signals worked and why 'normal' PC floppy drives couldn't work on older machines like my Sorcerer. This made me dig out my Bitscope (a portable 6-channel logic analyser/scope/measuring tool) so see which drives I had which could be jumpered to force things down to the way the Sorcerer+VSG would like them. With the Bitscope I could watch each signal to see what the Sorcerer was trying to make the drive do. Enter the Mitsubishi MF504C! With it added as the C: drive to the usual dual stack A: and B: Micropolis unit I got a successful format of a 48tpi DSDD soft-sectored disk using the hard-sectored controller in the Sorcerer's S100 expansion unit. It took some experimentation with the READY jumpers but I managed to copy my CP/M and utility disks too.

Also round about this time I hooked up with Mike Borthwick in Australia who was also pursuing making disk images of Sorcerer floppies along with Andrew Stuart and Terry Stewart (Tezza) in New Zealand. He had some extra file transfer utilities from the Austrialin Sorcerer Users' Group, the most promising of which was called STERM and was primarily used to send and receive files to bulletin boards. After receiving a zipfile of STERM I UNLOADed it in the CP/M emulator I'd been using on a virtual Win7 machine. This produced a HEX file which I could then transfer down to the Sorcerer and LOAD it like I'd been doing with flop2pc. We didn't know how STERM communicated with its host but given that XMODEM was pretty standard back then I sent a file from the Sorcerer to my serial PC with Hyperterm receiving in XMODEM mode and it worked first time! Receiving worked too. Suddenly both file transfer AND disk images were possible.
I also successfully rewrote a Lifeboat CP/M 2.2 disk onto soft sectored media using CPT and booted it.

Now that Sorcerer disk images seemed to be fully transportable it was time to decode the CPT image format and extract the actual image data so that cpmtools on Linux could examine them and add/remove files. The format is fully documented so while it would've been easy just to read past the header and pull out the image data I thought it would be a good programming exercise to document the image too. My Python was a bit rusty and my Mac is limited to 2.7 but I now have a utility that will show the image details and produce a disk image that is readable by cpmtools. Thanks to Larry Kraemer for spotting that my resulting image was one byte awry because I missed a flag byte in the header! First up was the Lifeboat CP/M 2.2 disk which is THE most important for my Sorcerer and the only one that started failing while I was coding. To check that the image was good I extracted SORCUSER.ASM and it listed OK.
For a proper test I also pulled out DUMP.COM and imported it into my CP/M emulator - it worked!
The required /usr/local/share/diskdefs is:
        # Sorcerer CPT image 5.25" SS DD 77T
        diskdef cpt1
        tracks 77
        seclen 256
        sectrk 16
        blocksize 2048
        maxdir 128
        skew 1
        boottrk 2
        os 2.2

All images and text © Adrian Graham 1999-2019 unless otherwise noted using words. Also on