Delivering files to the Z80-MBC2 and V20-MBC homebrew computers is an essential capability for bringing new software and data to these CP/M devices.
In particular I need a file upload capability, a way of transferring text files from the host system to the remote CP/M devices. Why just text? Because a text stream is the lowest common denominator. The simplest, most ubiquitous, and versatile communication channel.
Encoding binary files as text, such as the Intel HEX format for executables or uuencoding, enables moving arbitrary files over text streams.
The problem
I want to transfer files in the most practical way, i.e. via the serial USB connection from the host system, my Chromebox (where the terminal emulator for controlling the devices runs under Crostini Linux), to the remote devices. I could copy the files to the microSD cards the homebrew computers use to simulate storage devices like hard disks, but this would require additional steps.
An obvious solution would be a file transfer protocol like the XMODEM utility that comes with the Z80-MBC2. But XMODEM file upload to the Z80-MBC2 has issues and the V20-MBC doesn't have XMODEM or other file transfer software preinstalled.
My initial workaround, dumping a text file from the terminal into a CP/M text editor, does the job but creates friction. I wanted a minimal upload channel with less friction, that relies only on native CP/M features, and can work also on the V20-MBC.
The solution: a minimal file transfer channel
I came up with a similar but more streamlined solution.
Like in the workaround, on Linux the process consists in dumping a text file from the terminal emulator.
But on CP/M, instead of running the ed editor to collect the file and manually save it, PIP automatically receives and saves the file. An additional advantage is PIP can handle arbitrarily long files whereas ed is limited to available memory.
There's a reason the CP/M system utility PIP is called Peripheral Interchange Program — emphasis mine. In addition to copying, renaming, and combining files, PIP can transfer data to and from the console and other peripherals. The new transfer channel relies on this feature by receiving the text coming from the console associated with the terminal emulator, and saving it to a file.
The process
How does transfers over this channel work? I initiate file uploads on Linux from the Minicom terminal emulator.
First, to introduce a character trasmission delay I change Minicom's settings with the Ctrl-A T F command, Terminal settings > Character tx delay (ms). A value of 1 ms works well on both the Z80-MBC2 and the V20-MBC.
Why a delay? Although the homebrew computers are connected via a 115200 bps serial link, these 8-bit and 16-bit systems can't keep up with the full speed with which the 64-bit Intel i7 Chrombox can pump data. Hence the need for a transmission delay.
Next, at the CP/M prompt I launch PIP:
G>pip filename.txt=con:
Since the destination of the data before the = symbol preceeds the source, the command instructs PIP save to FILENAME.TXT the data coming from the logical device con:, the source. By default CON: is associated with the console, i.e. Minicom on Linux.
The above command makes PIP receive the text stream Minicom sends over the serial line as if typed by the user at the keyboard. How can Minicom type text virtually? The program's Ctrl-A Y Paste file command allows to select and dump a Linux file, which is the last step of the transfer.
Then, on CP/M, the incoming text is saved to a file and rapidly printed on the screen line by line. The transfer may take up to a few minutes depending on the file size.
When PIP terminates, the new file is ready. A caveat is CP/M expects text files to be encoded with specific line break and end of file control characters, i.e. ^M^J and ^Z, not ^J and ^D like on Linux. If the end of file is missing, PIP pauses until the ^Z keystroke is entered manually.
The procedure works well on both the Z80-MBC2 and the V20-MBC.
Next steps
Dumping text files over a serial line is slow and more involved than dedicated file transfer protocols such as XMODEM, and works only one file at a time.
But text streams are universal, easy to use, and reliable. More importantly, these streams are the only way of uploading binary files encoded as text, such as executable programs not already stored on the remote device. For example, neither XMODEM nor other file transfer utilities are preinstalled under CP/M-86 on the V20-MBC.
I'll leverage this text channel to upload to the V20-MBC the Kermit communication program, which implements the transfer protocol by the same name. I'll see if Kermit can upload from Linux to the V20-MBC, and then the Z80-MBC2.
#z80mbc2 #v20mbc #retrocomputing
Discuss...
Email | Reply @amoroso@fosstodon.org
