I had lost my null-modem cable and could only find a mirrored 9-pin cable with M-F connectors (what is that for anyway?). The proper null modem cables were still sold at Clas Ohlson in Helsinki. Thanks, Clas Ohlson!
Serial is quite fast for sending a few megabytes or less, which is enough as Falcon files are not that huge.
Obviously, the ports have to be set for the same speed. 115200 proved to be too much, so I went for 57600, which gave a healthy ~5500 bytes per second. (2026 edit: Using an USB-COM adapter I had to work with 38400)
First, I need to set the serial port parameters using the Control Panel. This requires the Control Panel accessory (XCONTROL.ACC) in the boot drive folder and the serial control panel extension (SERIAL.CPX) on the system, at C:\CPX\ for example.
DRVIN.PRG needs to be at the AUTO folder to gain these high speed connections for "Modem 2", otherwise you'll be stuck with the 9600. Edit: It seems the SCC.PRG should be there too. Not sure which of them or both?
 |
| If DRVIN is not there, the ACC is likely to bomb if you try to fiddle with the modem 2 parameters. |
XYZ on a command line shell at Atari end
To receive files using the ZMODEM protocol, you need XYZ.TTP.
Although the xyz can be run from the desktop, I prefer to use these TTP (TOS-Takes-Parameters) programs from inside a command line shell. It's neater that way and I get to see the program results and recent actions better. Moving files around the system becomes quicker too.
 |
| Still testing at 9600, hence the slow speed... |
I added the following line inside the Okami "profile" file, so the shell will execute it on running. This way I can run the xyz from wherever I happen to be:
xyz=c:/xyz202b/xyz.ttp
Afterwards, using
$xyz
the xyz.ttp will run and wait for a file to be sent. Yes that $ is not exactly as effective as an alias or a proper PATH but it's still far better than working every time from within that folder.
As an aside, editing that profile file is a chore as there are very few choices of a shell-run text editor. I'd hate to jump between a GEM editor and the command line shell now that it's in place. I ended up using something called pro_edit for now, which is rather poor and assumes the display height is 400. ST video modes to the rescue.
But if it's only a matter of adding one line to the profile, then appending that line with echo xyz=c:/xyz202b/xyz.ttp>>profile will work.
Obviously, after the file transfer is in place text files could be transferred from the Linux... But as the point is to toy around with the Falcon, why move over all the tasks to some other computer?
sz at Linux
Unlike Atari, Linux doesn't have an abundance of strange 'terminal emulator' programs, possibly because the terminal is so integral to the system.
There's minicom, but practically minicom (or anything else) uses rz and sz for file transfer protocols, so it's better to use these from the Linux terminal command line directly.
These need to be installed first. If there is a permission problem with the serial port then the user has to be added to the dialout group.
I followed a suggestion of calling sz from a tiny script (named zsend in the example) which ensures the serial port speed is correct:
#!/bin/sh
DEV=/dev/ttyS0
stty -F $DEV 57600
sz $1 > $DEV < $DEV
The ttyS0 is the device for the serial port, in my case it's already a part of the motherboard. An USB->RS232 port is often called ttyUSB0. dmesg | grep tty reveals the device names.
Saving this script as zsend, it can be made into an executable with chmod +x zsend, after which ./zsend filename should start the transfer. If Atari is running the xyz.ttp and waiting, then the file should transfer.
A version for receiving files from the PC end, use rz instead of sz.
At TOS, xyz -u filename will upload a file, defaulting to ZMODEM.
I also tried batch uploading with *.* and although everything went fine for a file, the XYZ.TTP at Atari end complained about too many handles or something after about 16-17 files. So, for moving a lot of files it's better to zip things at that end first, no matter how slow it is.
Strangely, uploading from Atari was a slower, some times less than 4000 bps on average. File permissions may need altering on the Linux end and the filenames tend to be uppercase which can be a bit annoying at Linux. -LL option on zip ought to force filenames to lowercase, though.
Backing up AUTO folder and your essential system files with this method is a good idea I think!
At Atari again
Transferring zip files is much more handy than trying to send files with a folder structure, and they are obviously compacted too.
Working with the Okami shell, for added comfort I also added the zip unpacker to the Okami profile:
zip=c:/packers/stzip/zipjr.ttp
...for example. The zipjr.ttp comes out of the stzip.tos self-extracting archive, found here.
$zip -xr file.zip
In Okami, this then becomes the equivalent of running zip from its folder. It appears the zip version I have it likes explicit -xr parameters for extracting and preserving the folder structure.
Lharc (lzh) is another often seen archive format, and jaymsa18 may be used for recovering files out of .msa and .st disk images on the Atari end, if the disks play nice with file structure that is.
After all this, I can finally look at Llamazap, an apparently unfinished game by Jeff Minter that can't even be started without a very specific controller. Oh, well.
