LisaList2

Thank you again for the detailed analysis! I checked my motherboard and it is indeed a 620-0108-E which only has an external parallel port.
I seem to have a stock lite adapter with no modifications at all

The weird part is that my floppy drive was working just fine with floppyemu before the esprofile incident. I was able to load up Lisa 2 diagnostics, macworks 2 and boot to macos just fine.
I plan to replace the 8T97 first to see if that will make a difference as it seem to hang with error 23 after the initial 57 on boot. (only with floppy emu)

Felt arrived today. I am pleased to report that I did not break anything (as far as I can tell). It's F1 industrial felt with adhesive backing. Using the leather punch it became clear that 4.5mm diameter is the correct size. James' tip about un-clipping the alien from the underside makes it very easy to do.

A few pictures of the dirty old head pressure pads and the newly-made replacements below. The original head pads are not quite as tall, a bit more compressed in their appearance. But I'm certain that the replacement pads will settle down to an almost indistinguishable height after they've had some pressure applied for a while.

Re-installed the drive and it works! Thoroughly cleaned the heads "while I was in there." 

Can someone be more specific about what not to do here? Obviously Alex isn't saying 'don't run the make/all' script, but ultimately isn't it installing "on top of the Workshop"?

eg. is the risk purely regarding packed files, or is there a risk that make/all failing in some particularly inconvenient spot will have deleted some required file before successfully building a new one, breaking the system (either to the point that it crashes, or to the point that the next attempt to make will aggravate the problem causing the crash)?

There isn't anything you really need to worry about here! I'm just saying that you should never try to install LOS over the top of a Workshop installation from the LOS install diskettes because the LOS installer will overwrite the unpacked Workshop versions of the libraries with the packed LOS versions of them. But in terms of the compilation process, you don't need to be concerned about anything. The build scripts will overwrite the original unpacked libraries with new unpacked ones; the script only goes to pack them when they get copied over to an LOS install diskette.

There shouldn't be any point (at least that I can think of) where the scripts delete a critical file before generating its replacement, so I'm guessing that your issue is related to something else. Hopefully starting fresh with all the new stuff will fix everything!

Has anyone seen RS-232 errors...

I've encountered one error 643 in transferring prolly 1.5 times the whole set of files (the set as recommended by Alex); it was not accompanied by the level 7 interrupt.

Since the problem you've experienced is only semi-repeatable (AFAICT), I wonder if it is an interference issue rather than a configuration or data pattern issue.

I'm using quite long cables, maybe 30' overall composed of a couple long ones strung together, a re-wired 3" null-modem adapter, and a DB25-DE9 adapter; not much for 80's RS-232, but for a USB adapter, perhaps not typical usage.

All the shields are connected, and I have all the equipment power connected to a common ground, as well.

If you have a voltmeter, you might disconnect the serial cable and check the AC voltage between the shields, and/or the grounds (pin 7 of the DB25) to see if the two ends of the link are fighting a ground differential.

So far I've not made it through the entire make-all process; somewhere around the make/fullos stage something happens (I presume some newly built obj file comes into use), the Lisa crashes, and won't start up again due to an invalid OS system error.

I'm starting over with the Aug 14 disk image & scripts and a fresh source unzip, so hopefully whatever I screwed up is gone now, but so I don't make the same mistake again:

when you install LOS, it copies over packed copies of all the intrinsic libraries .... But then, when you go to install the Workshop, it replaces them all with unpacked versions so that you can link properly.
...
Make sure not to install LOS back on top of the Workshop, or else it'll replace all of them with the packed versions again!

Can someone be more specific about what not to do here? Obviously Alex isn't saying 'don't run the make/all' script, but ultimately isn't it installing "on top of the Workshop"?

eg. is the risk purely regarding packed files, or is there a risk that make/all failing in some particularly inconvenient spot will have deleted some required file before successfully building a new one, breaking the system (either to the point that it crashes, or to the point that the next attempt to make will aggravate the problem causing the crash)?

Okay, it's all done and up on Github! The new LOS Compilation Base.image comes with the updated versions of all the scripts and the PACKSEG executable, but if you've already transferred all the source files over and want to update your existing LOS Compilation Base.image, then you just need to copy over the following files:

ALEX/ASM/LIBHW.TEXT
ALEX/ASM/LIBPL.TEXT
ALEX/MAKE/ALL.TEXT
ALEX/MAKE/APCL.TEXT
ALEX/MAKE/APHP.TEXT
ALEX/MAKE/APIM.TEXT
ALEX/MAKE/APIMDISK.TEXT
ALEX/MAKE/APPW.TEXT
ALEX/MAKE/DISK1.TEXT
ALEX/MAKE/DISK2.TEXT
ALEX/MAKE/DISK3.TEXT
ALEX/MAKE/DISK4.TEXT
ALEX/MAKE/DISK5.TEXT
ALEX/MAKE/DISKS.TEXT
ALEX/PACKSEG.TEXT
BUILD/PACKSEG.TEXT
ALEX/MAKE/ALL_NODISKS.TEXT
ALEX/MAKE/PACKSEG.TEXT
ALEX/PACK/OFFICE.TEXT

I've also updated lisa_serial_transfer.py to fix a minor bug, as well as patch_files.py to adjust its behavior on the Calculator, Clock, and Preferences now that we're making install disks. So if you've already copied the source code over to your Lisa, run patch_files on a fresh copy of the code and transfer the APHP, APCL, and APPW directories to replace whatever's currently on your Lisa!

Note that ALEX/MAKE/ALL_NODISKS.TEXT replaces ALEX/MAKE/ALL_NOFLOP.TEXT for the sake of increased clarity in the filenames. But now that we have PACKSEG, you can also run ALEX/MAKE/ALL.TEXT to build everything complete with install and LisaGuide disks!

Once you've built everything, you can make a set of all 5 install disks at any time by running ALEX/MAKE/DISKS.TEXT (or ALEX/MAKE/INSTALLER.TEXT if you want to rebuild the installer too). Individual disks can be made using ALEX/MAKE/DISKn.TEXT, where n is the disk number from 1 to 5.

To make a new LisaGuide disk, just run ALEX/MAKE/APIMDISK.TEXT.

Enjoy, and let me know if you encounter any problems!

A 'real' drop-in solution would be a new accelerator design that incorporates a fast version of the MMU. Although that's been suggested, Alex hasn't finished it yet.

And given that I'm about to start grad school, it may be quite a while (if ever) before I get around to starting on something like that!

Perhaps LisaEm is ultimately the best solution?

LisaEm works pretty darn well and can build everything in about 10 minutes when clocked at 512MHz. The only issue is that it crashes a lot, which can be pretty infuriating and will often corrupt your disk image.

The thought of leaving my Lisa on for hours on end compiling code at 5MHz gives me a bit of a shiver.

Sure, it's about 9 hours the first time around, but just remember that you'll really only need to do that once. After that, you'll just be rebuilding whichever components you're making changes to, which will be significantly quicker. For instance, the OS itself only takes 45 minutes, and each of the applications is 45 minutes or less. Many of the libraries are quicker than that, at about 10-15 minutes each.

And for what it's worth, I've left my Lisa on for at least 1000 hours throughout this project, and it's handled everything flawlessly! Not to say that your experience will be the same, but I've been impressed by the reliability of everything.

Is there anything stopping us from running the Workshop with say, an XLerator or something like it?

Yes, there is a compatibility problem:

To obtain fast access to memory, the XLerators don't use the Lisa's MMU, so the Workshop and LOS that make heavy use of the MMU aren't compatible with the XLerators. (At least, not for now, and maybe never)

I suspect there isn't an alternative 68000 accelerator board that would show much improvement, as the best it could do while using the CPU board MMU amounts to caching instructions/data (or so I speculate).

A 'real' drop-in solution would be a new accelerator design that incorporates a fast version of the MMU. Although that's been suggested, Alex hasn't finished it yet.

Perhaps LisaEm is ultimately the best solution?

This is likely a very stupid question but it just popped into my head now. Is there anything stopping us from running the Workshop with say, an XLerator or something like it? The thought of leaving my Lisa on for hours on end compiling code at 5MHz gives me a bit of a shiver.

LMK if you're ever in the San Diego area. You'd be welcome to stop by.