LisaList2

Assuming LOS development ever gets to a place where new features can be added, it would be interesting to think about useful improvements that could be made to the Office System. We have a thread for potential Lisa hardware projects, so this seems logical.

Now if there's actually a way to do this aside from copying the files from the original disks, I suppose I'll look like an idiot for starting the thread this way, but...

One of my biggest gripes is tools ought to have the ability to generate fresh, "default" stationery pads in case you delete all of yours. The desktop manager should likewise have the ability to generate an empty folders pad. The ability to create new directories shouldn't be a deletable feature, and if you want to remove the ability to make a certain type of file, that should be resolved by removing the tool, not the pad.

The simplest way to do this might be from a menu command in each tool file? And one in the desktop manager?

Just for grins, I'd like a version of LOS 3 that can run on the Lisa 1. There seem to be Twiggy drivers in the source tree, so it might be possible?

Quote from: stepleton on July 05, 2025, 05:11:35 AM
Just for grins, I'd like a version of LOS 3 that can run on the Lisa 1. There seem to be Twiggy drivers in the source tree, so it might be possible?

I didn't look into this much because I don't have a Lisa 1, but I think we're just one file short. We've got everything to build the Twiggy bootloader (system.bt_Twig) and build the OS itself (SYSTEM.OS) with Twiggy support, but we're missing what I believe is supposed to be an assembly source file for the Twiggy driver (system.cd_Twiggy).

Since there are DB-25 LocalTalk connector kits available (including one from Apple itself for use on the XL), I wonder how hard it would it would be to create a de minimus AppleTalk stack? Just putting out a node name, nothing complicated like printing...

Seeing no obvious way to terminate a Workshop Exec script via Command-. or mouse down or some such thing, I speculate there would be some utility (also for LOS) to having a privileged driver that can do things like Peek and Poke upon request.

Somewhere in the Workshop documentation there is advice about what to do if an exec script goes berserk. I don't remember where it is, and I don't remember it being super satisfying either; something along the lines of using Command-. or whatever to cancel the currently-running job and then continuing to mash Command-. while the interpreter is in between running commands.

In re peek and poke, I seem to remember a post years ago by Ray that claimed the discovery of some extremely trivial privilege exploit against the Lisa OS: my recollection is dim, but I seem to think it was as simple as putting the address of some code to call in A1 and then causing a trap, and the code will be called in supervisor mode. This mechanism might save you the trouble of writing a whole driver.

Ah, here it is: https://lisalist2.com/index.php?topic=113.0

Quote from: stepleton on August 04, 2025, 03:38:46 AM
in the Workshop documentation there is advice about what to do if an exec script goes berserk. I don't remember where it is, and I don't remember it being super satisfying either; something along the lines of using Command-. or whatever to cancel the currently-running job and then continuing to mash Command-. while the interpreter is in between running commands.

It reads something like "programs can't be interrupted by Command-. unless they have been written to explicitly check for it" and "most (Apple written) shell programs do check for Command-.". However, it warns that the exec interpreter does not. I think that means that while you might be able to terminate some sub-program your exec calls, you can't terminate the exec itself unless it is checking for an early exit condition (with no obvious means for doing so).

I agree Ray's finding is bound to turn out useful, thanks for recalling it!

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!

An SD driver would be useful; the OS 3.0 block driver model (which splits things into high-level and low-level drivers) could make it straightforward, and enable the use of large volumes—though they'd still be limited to 32761 files, since S-file IDs are 16-bit signed integers and 0-4 and 32767 are reserved.

Unless you were thinking of using a parallel port adapter, you might also be talking about building an SD I/O card. That would also be interesting as we now have enough information to not only write a proper "loader loader" for a new volume type, but also enough information to implement a boot ROM for a new card. And if one's talking about a new card anyway, one may as well stick an ESP32 or Pico between the Lisa and the SD interface to simplify everything further.

A SCSI driver, loader loader, and boot ROM would also be useful, of course, and also in theory shouldn't be too difficult. But the effort:reward ratio might be better for SD given that SCSI isn't exactly modern either.

One thing that stands out to me from reading some of the writeups is that getting files to and from Lisa is a pain. It seems like one possible option would be a Kermit implementation: The protocol is designed to be simple, robust, and work over variable-speed 7-bit half-duplex channels, with an open-ended feature set that can include things like directory listing and put/get functionality.

The HP-48SX used it for its computer interface to very good effect. This even allowed it to support an external 3.5in floppy drive with an RS-232 interface and Kermit support; it could list, read, write, and delete files on DOS floppies tht way.

A "Kermit service" on Lisa could even conceivably run as a background process to allow access to a Lisa's mounted filesystems via one of the serial ports. Then something like a FUSE module could be used to work with those files "transparently" in your favorite editor on a modern system, while still doing builds etc. on Lisa under Workshop.

(Note that I'm not suggesting a port of C-Kermit, which is a pretty large and complex project, but a Lisa-specific implementation focused on a couple high-level goals like fast-and-accurate transfers and providing filesystem access.)