LisaList2

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.

Another interesting fact: the Desktop Calendar is assigned to tool number 140. I wonder if this has any significance or if this was just a completely arbitrary choice by Videx?

And for anyone who's curious, it looks like the original copy was serialized to the Lisa with S/N 69942.

Okay, I just deserialized the image and removed the bytes that enable serialization to begin with, so just use the copy attached to this post and it should work great!

Trying it out for the first time, this version is definitely a lot more feature-rich than the other Desktop Calendar!

Thanks so much for uploading this!

So a while ago I asked if anyone had a copy of Videx Desktop Calendar archived as it was posted to LisaList1 way back when and then lost. Bitsavers does have a copy of something called "DESKTOP CALENDAR 9/9" that I thought was Videx Desktop Calendar.

Not long after that question, I found an original copy of Videx Desktop Calendar on eBay for cheap, so I picked it up because I thought it'd be a cool trophy piece to have an original copy, even though we already have a good dump of the disk from someone else - or so I thought.

Tonight, I started reformatting my Lisa because the attendees at VCF absolutely trashed my X/Profile's filesystem. Whoops. While reloading software I thought "Hey, let's pop in this Videx disk just to make sure my Sony drive is still OK." Then I noticed the icons on the disk were completely different to the icons in the "DESKTOP CALENDAR 9/9" disk image - the icons are wayyyyy more detailed. (Calendar Comparison.png: DESKTOP CALENDAR 9/9 is the top set, Videx is the bottom set.)

So of course I had to immediately stop what I was doing and grabbed my BLU CF card and started to dump the disk... and now I think my Zilog SCC is dead. It'll receive bytes no problem, but only spews out garbage on the transmit side. Oh well, I have a 603e Mac clone running 8.6 that still works great, so I just dumped the disk there instead.

Unfortunately while it appears the disk dumped okay the software was copy protected and LisaEm with the special Serial FF00 set won't get past it. Someone can get past it I'm sure but it's late and I'm tired now. Attached is a copy of the disk image for someone to try and bust!

Here's an old ad for Videx Desktop Calendar on Applefritter. It seems the Videx calendar is way more feature-rich than DESKTOP CALENDAR 9/9 is. It's like your Outlook calendar, but in 1984... https://www.applefritter.com/content/videx-lisa-desktop-calendar-ad