LisaList2

It definitely seems like they had lots of plans that were only ever partially realized and were also periodically derailed.

I've never seen that video, I'll have to check it out!

Lars Brinkhoff found an older version of the annotated assembly—and a description of the IUJSR, IUJMP, IULEA, and IUPEA instructions it's used to implement—in the Pascal internals manual on Bitsavers, so I've annotated my disassembly based on that and included a description of the instructions.

When I add disassembly to lisaobj (or write a separate lisadis), I'll be able to actually include these IUxxx instructions too.

I don't really understand what the A-trap dispatcher assembly code does, but I wonder is this code the same "aha" moment that Ray Arachelian talks about at https://youtu.be/o5bZBXqfeAU?si=miO4k4Bk6kBB4jKt&t=560 ? Understanding that assembly code allowed him to get LOS to finally work in LisaEm, after many years of try-and-fail.

Quote from: AlexTheCat123 on March 03, 2026, 12:29:50 AMYou'd think that they would've thought of this and added a check in the installer for it, but clearly not...

The more you read about the Office System, the more haphazard it all seems, and something of a miracle that it even came out at all...

Quote from: Eschaton on March 02, 2026, 11:56:03 PMIt's also amusing that the linker can't link against packed objects, so Workshop replaces the packed libraries with unpacked libraries... I guess unpacking at link time, or generating linkable stub libraries, or unpacking to linkable copies, or even just unpacking in-place during installation was too much work.

Yeah, this really shocked me when I first discovered it. I spent forever trying to figure out why my packed libraries were breaking the linker, thinking that something was wrong with my PACKSEG implementation, only to discover that it's not even supposed to work with them at all!

This also means that, if you want LOS and the Workshop installed alongside each other on the same disk, you MUST install LOS first and then the Workshop. If you do them the other way around, the LOS installer will overwrite the unpacked libraries that the Workshop just laid down and replace them with packed ones. You'd think that they would've thought of this and added a check in the installer for it, but clearly not...

That wouldn't surprise me. Perhaps they originally thought that this would help enable a dual-Twiggy Lisa to actually be useful without a hard disk, or something along those lines, since they could include an optimized packtable in each tool.

It's also amusing that the linker can't link against packed objects, so Workshop replaces the packed libraries with unpacked libraries... I guess unpacking at link time, or generating linkable stub libraries, or unpacking to linkable copies, or even just unpacking in-place during installation was too much work.

The Lisa OS sources don't include the sources to Lisa's A-trap dispatcher, instead it's just a CodeBlock that's copied forward from one copy of INTRINSIC.LIB to the next, and is set as the handler in source/LOAD.TEXT by Setup_IUInfo.

For that reason, I've used my tools to extract the code and have a disassembled version here:

https://gist.github.com/eschaton/2c9cdcddccd3dde177005872ddd6e946

This should help us figure out how to interpret A-traps located in Lisa code. I'm pretty sure they get inserted by the linker (rather than the compiler's code generator) for calls to intrinsic libraries, or something like that, since the 68000/8/10/12 only have 16-bit PC-relative branches.

From disassembling several different bits of Lisa code, it looks like the A-line instruction word and the following word contain some sort of index that's used to determine the destination of the call. Unfortunately, it's not immediately obvious how to interpret that destination.

Quote from: Eschaton on February 26, 2026, 05:53:02 PMIt also doesn't seem like it'd be very difficult at all to modify the binary loader to use a packtable found inside a file to unpack any packed code inside of it. There's no code to do that currently (unpacking always passes the system packtable) but it'd just be a matter of keeping track of the object during the initial scan through the file and then passing it to UNPACKCODE instead of the system packtable.

I might just be imagining things, but I think that I came across something during my LOS investigations indicating that this was something that they actually did at one point in time. Not sure when they switched away in favor of the current method, but I'm pretty sure that some older releases did indeed store the packtable within the file (or at least give that as an option).

If you just replace a Lisa's CPU itself, you'll see no difference since the 5ish MHz clock is still driving it; the CPU speed is a rating, the actual clocking of the CPU is external. (It wouldn't actually surprise me if "newer" Lisa actually used 8MHz part simply because the slower-rated models weren't on the market for very long.)

The other thing is that Lisa's 5MHz clock results from a bunch of different things share one clock domain, as was the style at the time. Something like XLerator has to implement separate clock domains for (say) video timing/RAM versus everything else. This is just a matter of engineering, and is made easier by the 68000's asynchronous bus, but it's not always trivial.

I think my implementations of unpacking (and now packing too) are correct, and the code looks right to me, but I'm not 100% certain yet. Random data and the packing table itself will round-trip through them with full fidelity but when I disassemble code that I've unpacked I still get some A-line instructions.

I think I recall Lisa will use A-line instructions to do cross-segment calls or something like that, but I haven't found any details on that yet, so I'm unsure whether what I'm seeing is an unpacking bug or something that needs to be accommodated in disassembly.