LisaList2

I don't think uuencode/decode exists, unfortunately; I'll check when I'm back home this evening, but I think Lisa Xenix might predate these.

I've tried slowing the baud rate down to molasses-slow speeds (1200 is as low as I can get my USB/Serial converter and PuTTY to drop to; 600 just produces garbage and I dare not try anything below that, lol) and using a character/line delay then pasting into ed, but it still mangles the text buffer pretty badly. I may need to try something older running XP/98 with HyperTerminal and an actual physical serial port. I've got Linux boxes, but never used minicom/ascii-xfr - I'll absolutely take a look!

As for idea two, that's brilliant! It's probably also the lowest cost in terms of effort and time and, therefore, the most appealing, lol. I will absolutely give this a try tonight and update with the results. I really don't see why I couldn't wrap all my C files up in a tarball and make that the disk image itself.

Xenix does come with a C compiler, but it's K&R C and not ANSI, apparently; I suspect I'll have to tweak some things no matter what, but I wouldn't mind trying to get a version of one of those tools running on Xenix to simplify future file transfers.

Thank you for the recommendations!

I don't know how to use cu/uucp, but if they exist in Xenix, chances are that uuencode/uudecode do as well.

So, quick ideas before I run into work:

Copying a text file onto the Lisa: `cat > file.txt` on the Lisa and then rate-limited paste of the text data (hopefully the terminal program can do that? many can. If you have a Linux box and minicom, look into the program called `ascii-xfr`).

Copying a binary file onto the Lisa, idea 1: uuencode the file on the modern computer, `uudecode` on the Lisa, then rate-limited paste or raw upload of the uuencoded text data.

Copying a binary file onto the Lisa, idea 2: pad the binary file out to the size of a 400k diskette, convert this new "raw disk image" into a dc42 image, "burn" it to a real floppy (or use a floppy emu), then use dd on the Lisa to copy raw bytes off of the floppy and into a file. No need to worry about "format" or filesystems if you're copying raw bytes.

(Not sure if idea 2 will work effortlessly --- it may depend on what Xenix does with the disk's tag bytes.)

I forget whether xenix comes with a C compiler, but if it does, I'd look into using these methods to copy on an ancient version of Kermit (if you can find one somewhere) or some old implementation of xmodem and then compiling and using that.

So, I've been banging my head against my desk for a few days now trying to figure out the best way to get data on to a Xenix instance and I'm hitting some roadblocks. Vi doesn't seem to want to cooperate over a terminal connection for direct text input and my complete unfamiliarity with ed isn't helping either. Xenix obviously doesn't have xmodem or kermit as options, which leaves cu/uucp, but I am also completely unfamiliar with how cu on Lisa Xenix is supposed to work. The manual is less than clear about how cu connections over serial should work exactly; I'd have hoped it would have included an example but, eh. I've thought about going the floppy disk route, but I'm uncertain if that's even viable. If I formatted a floppy disk/image (via FloppyEmu), would it just be the standard SYSV format or did Lisa Xenix use some other format? I can't find any direct indication as to what it would format the disk as, so it's a mystery to me at the moment how Linux would even handle that. I've so far been unsuccessful at trying to get Linux to mount the ProFile image as a SYSV volume (which it should be able to do).

Does anyone have any proper experience working with serial connections in Lisa Xenix to more modern systems beyond a direct terminal connection or, alternatively, moving files via physical/virtual media? If anyone's got some practical experience with cu/uucp on the Lisa that could throw some pointers/advice my way, I'd be incredibly grateful. Or, like I said, if anyone's managed to use media to move data back and forth between Xenix and more modern systems that would be fantastic knowledge as well. Either way, I'd prefer not to have to type a rather large amount of C...

Edit - Also, had a RAM card go bad and cause a kernel panic while trying to get cu to work, so that was an interesting experience getting to see a KP happen in a 40 year old Unix distro, lol.

Hmm. I know I had little success with GUI terminal software on my Mac. In trying to use minicom, the installer didn't bring down the zmodem binaries... that took me hours to figure out what was going on.

-J

Linux ... xmodem transfer ... has the annoying habit of dealing with fatal errors not just by quitting but by deleting the file that it was receiving first!

... at the very end of the transfer ... The hard drive image you spent many minutes downloading (all while wondering if the drive itself will survive!) is deleted immediately ... frustrating!

Ouch! Congrats figuring out a work-around!

There is a BLU bug report (from Ray) indicating that he saw some Linux xmodem transfers that didn't terminate properly, but it doesn't seem to be a popular problem, and his report was years after release.

Looking for info, I found this (may or may not be related): https://www.mattkeeter.com/blog/2022-05-31-xmodem/, which mentions an issue with an FTDI USB-to-serial module driver interfering with the xmodem packet timing. Apparently the driver's latency is/was easy to adjust on Windows and Linux, but not MacOS -- his MacOS fix referenced at https://openbci.com/forum/index.php?p=/discussion/comment/17915/#Comment_17915.

Can anyone confirm that the BLU xmodem issue is specifically an issue with compatibility with the Linux implementation or perhaps there are anecdotes with changing serial dongles fixing an xmodem problem?

I'm a Linux person, and I don't have relevant things to say for Windows. But since we're talking about xmodem transfer, the standard Linux program that does xmodem, ymodem, and zmodem reception ("rx", "rb", and "rz", but deep down it's the same program) has the annoying habit of dealing with fatal errors not just by quitting but by deleting the file that it was receiving first!

While I forget whether this led to trouble with BLU, with UsbWidEx, there's a disagreement between the way rx does xmodem and the way UsbWidEx does it. This disagreement arises at the very end of the transfer, and rx has a tantrum and fatal-errors. The hard drive image you spent many minutes downloading (all while wondering if the drive itself will survive!) is deleted immediately. It's very frustrating!

The quick-and-dirty workaround is to go to another terminal window while the image is being transferred and make a hard link (plain `ln`, not `ln -s`) to the file being downloaded. rx will unlink the original filesystem entry for the image, but your second entry is just as good. The image itself will be fine no matter what rx thinks about it.

I always use TeraTerm.

The version of Hyperterminal that comes with Windows XP works fine with both BLU and UsbWidEx XMODEM transfers. This runs on the lab notebook I'm using with vintage computer hardware

any luck ... with HyperTerminal?

The BLU manual says:

NOTE: HyperTerminal won't work for bootstrapping as it mangles CR/LF combinations!

Which seems sufficiently specific that it might do an xmodem transfer ok, but it could also mean it was a non-starter and so wasn't considered worth testing -- sorry I don't recall.

Given no progress in either direction, I'd guess it is a handshaking issue.

In any case, trying an alternative may be informative.

Good luck!

edit:

This post from Ray implies that HyperTerminal could work, but doesn't confirm he tested it.

edit 2:

In a 2007-02-01 email exchange with Ray there is this comment:

HyperTerminal rejects the data UNLESS you wait until a couple of timeout failures pass; whence it switches from CRC to checksum; if you start sending then it works ok.

It may be that was before BLU understood CRC, but it seems worth trying.

Has anyone ever had any luck dumping diskettes and transferring them with HyperTerminal? I replaced my SCC today and while all the replacements I got all now work fine for simply bashing on the keyboard to make text pop out of either end, I cannot either end to see an Xmodem transfer.


For the curious: I suspect my original SCC is one of those infamous faulty chips sold as NOS - there's no evidence of sanding, but the legs were all suspiciously tinned. Oh well, I have a bunch of very pretty ceramic and gold SCCs now, so I'm happy.