LisaList2

643 is "Unexpected RS-232 interrupt", not to be confused with 647 a.k.a. "Unexpected RS-232 timer interrupt". I wonder if the sending computer or the serial adaptor is doing something funny with e.g. hardware handshaking lines.

So it looks like you're getting an error 643 when trying to read some data from the serial port. I haven't been able to figure out what 643 means exactly, but I do know that the 640 range is reserved for serial port errors, so clearly something's going wrong with the port. And then the failed read is causing something (array index or variable value, not sure) to go out of bounds, leading to the CHK RANGE ERROR.

So we just need to figure out what's causing this read error on your serial port. Have you tried the transfer multiple times, and if so, does it give the error every time? Does it always occur when transferring the first file, or are you sometimes able to make some progress before it errors out?

Hello,

I'm currently trying to transfer the LisaOS source files to my Apple Lisa using the serial transfer script from this GitHub repo:
https://github.com/alexthecat123/LisaSourceCompilation/blob/main/scripts/lisa_serial_transfer.py

The machine is a Lisa 2/5 with 1MB of RAM.

However, during the transfer, the Lisa crashes with a Level 7 Interrupt and a CHK RANGE ERROR. I've attached a photo of the screen at the time of the crash (see below).


I'm wondering if anyone here has seen a similar issue or can help me interpret the crash and register dump. It seems to be failing during a MOVE.W instruction involving A5, possibly trying to read an invalid address.

Any insight or suggestions would be greatly appreciated!

Thanks, Ales

Is it the case that some source code was using the filenames with the '.' intact, and other source code was using the filenames with '/' substituted for '.', so you had to choose one convention or the other to unify?

Yeah, that's exactly how it was. The LisaWrite stuff was clearly substituting the '.' for the '/', but the Field Editor code (LIBFE) and maybe one other thing that I'm forgetting decided to actually use the dots as part of the filename. So instead of coming up with a complicated set of file naming rules (replace all '.' with '/' except in the special cases of...), I just decided to standardize it and replace all the dots with slashes.

The rule with file naming is that you should replace all '-' with '/' and also all '.' with '/', other than the '.' at the start of the .TEXT extension.

As far as I can see, changing '-' to '/' is required to make the filenames match the source code, so it is a straightforward 'fix'.

However, it looks like changing '.' to '/' requires changing both source code and filenames, so not a 'fix' so much as a change of convention/style... not a big issue, but if further source code appears then it may be an ongoing one.

Is it the case that some source code was using the filenames with the '.' intact, and other source code was using the filenames with '/' substituted for '.', so you had to choose one convention or the other to unify?

Ultimately, given the huge challenge (and accomplishment) of getting all this to work at all (thank you!), I'll be satisfied to hear 'that was the easiest way to get it working', but still wondering if the problem is more complex.

I happened to notice some oddities in the screenshots from Byte Magazine's 1983 Lisa article.
(https://guidebookgallery.org/articles/thelisacomputersystem)

First is an icon with a scissors on it labeled "tray." Naturally a scissors on an irregularly shaped piece of paper represents the action of cutting, and the clipboard window defaults to a position at the bottom of the screen, so it makes sense that the clipboard's final incarnation evolved from the trays seen in Bill Atkinson's Polaroids. I actually think this icon is pretty clever.

The other oddity is that the wastebasket isn't labeled. Perhaps they thought it didn't need one.

Seeing near-final prototypes in Apple ads and magazine articles is nothing new. But it got me wondering... how many prerelease builds of LOS ever made it out of Apple, if any? I don't think I've ever seen footage of one, but my own experience isn't exactly all-encompassing. And if someone ever found one, what are the chances it would it be runnable on a Lisa 1?

The rule with file naming is that you should replace all '-' with '/' and also all '.' with '/', other than the '.' at the start of the .TEXT extension.

The Python transfer script will automatically handle this for you, so I think the problem just stems from using some other transfer method that doesn't automatically do the renaming.

What issues were you having with installing pyserial? You should just be able to create a virtual environment, do 'pip3 install pyserial', and have it install properly, but it would be great to be able to update the readme with some additional instructions if there's any confusion!

I see now that this is not a unique hiccup.

After building some libraries I see there is further confusion (for me at least) in file naming when there is a period in some names, such as LIBFE/FLD.main.text

In an earlier version of Alex's build scripts, the names were used as provided in the source download and in the more recent scripts the python patch script changes the references in the sources to replace the period with a /, eg. LIBFE/FLD/main.text, and so the files need to be renamed to suit as well as the references to them.

This may be a 'me' problem, as I was able to use the python patch script, but failed to get the pyserial module installed, so uploaded the files in another way. The method I used only replaced '-' with '/' but I suppose the python uploader also changes some '.' to '/', maybe there are no issues if you can go that route.

YMMV

Hopefully Alex can describe the rule for fixing the filenames...

With tremendous thanks due to Alex, I'm making progress going through the build processes with very few hiccups so far, this is one of the few.

In the folder of the Lisa source files for LisaWrite "Lisa_Source/APPS/APLW/", there is an anomaly in the naming convention that trips up the build process with a "file not found" error.

The anomaly is 3 files with names starting with "APLW." (case insensitive) instead of the usual convention "APLW-" (which are converted to APLW/ upon upload to the Workshop)

To fix this so LisaWrite would build successfully, in the Workshop I went to the File Manager, Selected R for rename, for the original files entered "APLW.=" and for the destination files "APLW/=" (that's assuming the default prefix that points to the hard drive, and don't type the quotation marks)

This should rename
APLW.T1ALERT.TEXT
APLW.D1BOX.TEXT
APLW.T1MENUS.TEXT

to
APLW/T1ALERT.TEXT
APLW/T1BOX.TEXT
APLW/T1MENUS.TEXT

Obviously this would require hardware work as well, but an SD card driver would be extremely nice to have. I think if you're using the card in SPI mode it actually shouldn't be so difficult.

EDIT:

Also, restoring the buildable LisaWrite's spellcheck functionality with a public domain (and modernized) dictionary!