LisaList2

Sigh. One of these days I'm going to stop making such fundamental errors... sigma7's LisaAutoSwitch profile is working perfectly. I had been fiddling with the older profiles and, after correctly selecting LisaAutoSwitch, did not need to adjust much of anything after all.

I have two different RGBtoHDMI hardware units (slightly different configurations) and the profile works across both of them with minimal tweaks, i.e. adjusting Sampling > Pixel H Offset from 0 to 4 between units. No further changes needed. I think the Lisa 2/10 3A configuration is now solved.

Getting close!

thanks!

Quote from: Lisa2 on February 10, 2026, 12:13:22 PM

Quote from: bmwcyclist on February 09, 2026, 09:07:32 AMI was excited to order one until I saw the price.

Every member will have a different tolerance for pricing. 

I would prefer that we do not make judgements on prices here on LisaList2.

We should encourage any Lisa related project, regardless of price.

I can't believe that it is 2026 and new Lisa projects keep happening, it's amazing.

Rick

All good.

I am excited about these projects even if they don't directly apply to me.

I guess I should not expect folks to read the sig line, I have a 2/10 so this mouse IIRC would not be 'correct' for my LISA. I believe (again IIRC) that all of the 2/10s came with a Mac 128k style mouse.

This would be a VERY cool mouse to have, no matter what, but if it were correct for my LISA, I would unquestionably be saving up for this new reproduction mouse.

Quote from: Eschaton on February 15, 2026, 08:56:35 PMIt's also a pretty interesting algorithm: It's likely that some statistical analysis could produce a rather good 256-element compression table, given the regularity of the Pascal compiler's (relatively unsophisticated) code generation and the regularity of the 68K instruction set.

Ha, I've actually thought about doing this a couple of times! The only reason I haven't (aside from being busy with the LisaFPGA project) is because then the new packtable would be incompatible with all existing installations of LOS; you'd have to repack everything in order to use it. I know that might be a bit of a dumb objection since the kinds of people who would know how to copy over a new packtable would also know how to repack the OS files, but it just bugs me that you wouldn't be able to overwrite an existing SYSTEM.UNPACK without repacking things.

I wonder how they came up with the packtable that shipped with LOS? I'm guesing they analyzed earlier versions of the OS (or maybe the Monitor) and just threw the most commonly-occurring words in there?

Oh, yeah—sorry, it was very clear from your source that packing goes forward, it's just done in a way where unpacking has to go backward. Thanks for confirming my understanding! Eventually my hope is that hacking on some of the things we don't have source for will be feasible and fun, and the first step towards that is easier disassembly.

It's also a pretty interesting algorithm: It's likely that some statistical analysis could produce a rather good 256-element compression table, given the regularity of the Pascal compiler's (relatively unsophisticated) code generation and the regularity of the 68K instruction set.

Yep, I think that sounds about right overall, except that we actually work forwards instead of backwards. During unpacking, you work backwards (as you might be able to see in SOURCE/UNPACK.TEXT), but during packing we go forwards.

Part 8 is live.

https://www.youtube.com/watch?v=NjUuLkkr95g

Forget all you know about running a Lisa as well? I wonder if Jim used a demo machine, took brief notes, and then waited a week before writing the article:



Interesting to see mention of the Epson QX-10: this Z80-based computer had a much more text-oriented office suite called Valdocs, which at least in earlier versions was substantially written in Forth. It was said to be very buggy.

The successor machine in the US market was the QX-16, one of those combo Z80 and 8088 machines that let you boot either CP/M or MS-DOS. I'm not certain just how PC-compatible it was, but I suspect not totally.

@AlexTheCat123, if you have a moment, can you write up the packing algorithm? I'd like to write an unpacker in C to extract and examine packed code easily, and it'd probably be easier with a description than either trying to figure it out from the assembly unpacker or from your Pascal packing code.

Actually, let me take a crack at it so you can correct me:

The meat of the  algorithm is to work backwards through the input and output buffers. You read a flag byte and step through its bits from LSB to MSB: Every 1 says to read the next byte from the input and output the word in the pack table at that index, while every 0 says to read a literal word from the input and output that word. The first flag byte (at the end of the input buffer) may be special because there may also need to be a slack byte present to pad to to word alignment.

Is that about correct?