Exchanging files between an SC130 CP/M board and a Linux system

Chip logo This article is one of my series Adventures with RC2014, Z80, and CP/M. I'm building a CP/M system based on an SC130, Z180-based single-board computer, and I need a way to copy CP/M applications to, and get data from, this system using Linux.

The SC130 uses the RomWBW BIOS, which structures storage in a particular way. The technique I describe for using cpmtools for data exchange will work with RomWBW systems that use compact flash cards, rather than SD cards, or even regular hard disks; but it probably won't work with other BIOS implementations. However, using protocols like XModem to pass file data through the console from a terminal emulator should work on any CP/M system that has the relevant software.

Using cpmtools to read/write the SD card

The SC130 uses an SD card for storage. RomWBW organizes this card into 'slices' of 8Mb, this being the maximum size of a CP/M hard disk. It's easy enough to take the SD card out of the SC130's card slot and put it in a modern card reader, but the data format is not something that a modern computer will natively understand.

The cpmtools utility is designed to handle data transfers between the host platform and CP/M-formatted disks. The tricky part is specifying the disk geometry correctly, when the 'disk' is actually a slice on some larger storage medium. The problem is exacerbated by the fact that the version of cpmtools available in most Linux repositories is broken. I've been told that the Mac OS/X implementations are similarly problematic.

So it will almost certainly be necessary to build cpmtools from source. The source is available on GitHub. For me, building was as simple as make; sudo make install.

The stock version of cpmtools does not have built-in support for RomWBW disk formats. However, a replacement disk definition file diskdefs is provided in the RomWBW source.

It is important to understand that each 'slice' of the RomWBW disk has its own entry in diskdefs. By default, drives A and B are generated internally by the BIOS; removable drives start at C. For the SD card, drive C is the entry wbw_hd512_0 in the diskdefs file, while drive F is wbw_hd512_3.

Note:
Because there can be more disk slices on an SD card than there are letters in the alphabet, the RomWBW version of CP/M has a utility assign to map slices onto drive letters. My examples assume that the defaults are still in effect.

I'm using a USB card reader to manipulate the SD card. It appears as Linux device /dev/sdb1 on my system although, of course, this assignment will depend on what other storage devices are connected.

Note:
It's important to be be sure about the device that represents the SD card reader, because running cpmtools against the wrong storage device will do colossal damage to it.

With these settings, copying a file test.com from my Linux system to drive F on the SD card amounts to: 

$ sudo cpmcp -f wdw_hd512_3 /dev/sdb test.com 0:

The 0: here is user area zero -- the default user area for files on CP/M.

There are comments in the RomWBW version of diskdefs that explain how to work out the various configuration parameters for slices after the first four (drives C-F).

Using XModem

The RomWBW version of CP/M has a built-in utility xm for doing XModem file transfers. Other CP/M utilities are available for more sophisticated transfer protocols like Kermit. An irritation with XModem is that the protocol does not carry the filename; so it's necessary to specify the filename at both ends of the communications channel. However, XModem is easy to use and widely supported.

Most terminal emulators support XModem, and many support other things as well. For my terminal emulator I use Minicom on Linux. This has main menu entries "Send files" and "Receive files". So the basic procedure to send a file from the Linux system to the CP/M system is:

1. On the CP/M system, run 

b:xm r {filename}

2. In Minicom, hit 'ctrl-A, Z' to raise the main menu, then 'S' to send files, then 'xmodem'. Then select the file to send.

3. Have a cup of tea, if the file is substantial -- XModem is not particularly fast.

It's worth pointing out that any file transfer method from a modern computer to a CP/M system will requires functioning flow control, or the transfer baud rate will have to be set to a very slow value.

Using a floppy disk

Of course, the 'authentic', 1985-vintage method for passing data from one computer to another is by floppy disk. At the time of this writing, I do not have a working floppy disk drive in my CP/M system, but I'm working on it.