LisaList2

[disclaimer: this is simply a collection of observations that suggest a pattern - YMMV]

The Lisa Bulletin Board community offers a wealth of knowledge, blending the perspectives of vintage enthusiasts and seasoned collectors so what a better place than to put that to a test. Based on my observations of Lisa memory boards, there appears to be distinct differences in production runs that might help determine manufacturing timelines. This short essay explores how variations in serialization, board masking, and component selection reflect the maturation of Apple's Lisa production workflows.

The Shift from Manual Quality Control to Revision Tracking
Early production boards are often identifiable by the absence of formal serial numbers; instead, they frequently feature hand-numbered markings in the top right corner. It would seem reasonable that were utilized for quality control and in-field monitoring during the initial stages of production. As hardware revisions became more standardized, these manual serial numbers began to disappear, replaced by formal PC board revision numbers.

My assumption is these transitions suggest a growing confidence in the manufacturing process and their suppliers. While the first several thousand boards may have required more scrutiny and logs, the later iterations featured a more established logic layout, making it simpler to identify and replace faulty chips or capacitors without the need for manual tracking of each individual board.  It was also part of that classic 80s field service replacement of entire boards.

Material Consistency and Manufacturing Maturity
The standard dark green boards featuring glass capacitors and uniform RAM and logic likely represent the peak of Lisa manufacturing. During this phase, Apple had successfully locked down vendors and supply chains, resulting in a legitimate, consistent production workflow where boards were wave-soldered. In contrast, early prototypes and transitional boards show more variance:

• Component Color Variations: Variations in the color of capacitors (such as the smaller blue types) and integrated circuits (blue, white, or off-blue) suggest a less mature purchasing flow or the use of multiple suppliers to manage inventory shortages.
• Board Masks: Differences in solder mask colors and component types likely indicate specific internal production stages before the process became fully proficient.
• and in CPU Packaging: A similar evolution is visible in the CPUs, moving from older ceramic-bodied versions to the later encapsulated plastic versions.

What it all means!
It is my belief that reviewing these component mixes and mask variations, we can begin to reverse-engineer a type of timeline for Lisa board manufacturing. By sharing this knowledge people can be better aware of period correct components, particularly as the market matures and prices inevitably rise due to their rarity.

As always, I enjoy sharing some of my personal observation outside of traditional meat and potato thinking. So I am curious to hear from others regarding this theory on the evolution of Lisa hardware and how these physical changes align with Apple's historical production shifts during the Lisa's heyday.

Quote

QuoteIn my opinion, the least-amount-of-friction is serial wire transfer, the way Alex transferred the LOS source files to a Lisa

I agree.

In case anyone's tallying votes, add my agreement to this method as well. :-)

Not many that I'm aware of. The best alternative source I know is https://lisa.sunder.net/books.html . I prefer the version of the Lisa Hardware Manual found there even though it's not OCR'd and therefore not searchable.

Does anyone know if David T. Craig's archive of saved materials is available anywhere these days?

Quote from: stepleton on August 04, 2026, 08:26:23 AMquick note: Here is the text file format description, on PDF pages 37 and 38 in this file:
https://www.bitsavers.org/pdf/apple/lisa/toolkit_3.0/Package_2_Examples/17_Lisa_Development_System_Internals_Documentation_Feb84.pdf

Are there any more manuals out there?

(other than what is is bitsavers/pdf/apple/lisa....)

I haven't tried it on my LisaFPGA yet; please report how it goes!

Hey! I just realized my FPGA can be a "Lisa 2/5" I can try this now!

Lisa Image Verification Tools — Manual

I have found that FloppyEMU disk images on MicroSD cards often get corrupted. There are various reasons such as incomplete shutdowns etc. These tools will help check and verify LOS 3.x disk images.

Companion diagnostics for lisafile.py.

These read Lisa DC42 floppy images on
the PC and answer one question before you spend a Lisa boot cycle: is this
image safe to inject into and copy from?

Covers: chaincheck.py 2B (the pre-flight verifier) and checklen.py

(catalog length inspector, occasional use).
Written August 2026, following the XFER_v8 failure investigation.

Tag-format ground truth from lisafsh-tool.c (arcanebyte/lisaem) and Tom Stepleton's
LisaList2 references, verified against Lisa-created files.

Fantastic information and thank you!

In retrospect, I suspect my developer friends made the remark tongue-in-cheek, as there is a bit of East Side/West Side between development and secops.

Sorry about my conflation of public domain and abandonware; I guess what I was trying to get at is I don't want anyone to expect me to continue supporting or updating anything I make.

I am very intrigued by the advice to have the AI take the time to explain the processes and alternatives, as you have suggested. I am looking forward to that, thank you!



 

There are a lot of people with a lot of opinions about vibe coding. I won't prescribe any particular point of view myself, but here are some facts that might be relevant:

First, github is full of partially and fully vibe-coded projects, and github for its part seems happy to encourage this. I see a "Try GitHub Copilot" button on github's frontpage. Alternative hosts like codeberg have a rule against vibe-coded projects, but those hosts are not github.

my actual developer friends tell me that is not even programming because I did not compile it...

OK, I was wrong, I will prescribe at least one point of view. Your "developer" friends are silly to make this distinction. There is no clear line to draw between programming and not-programming and peoples' opinions will vary on what counts, but "compilation" as the dividing line is not one that's entertained by anyone serious, nor (I suspect) is it one your friends could actually define with much precision. (Though part of me would love to hear their attempt.) I would not waste much time debating or even discussing this with them further.

Back to facts. Coding agents reduce the need to understand as much about the problem you're trying to solve and the methods being used to solve it. This allows for rapid progress but also sidesteps opportunities to learn and to make connections. In your case, you learned about relevant references and similar projects after the fact. This might be fine, but if nobody had spoken up, then you might still be in the dark about those things, they wouldn't have the chance to inspire or interest you (which is not to say that they did), and you wouldn't be able to pass on that knowledge to anyone else.

Doing your own study might give you the chance to make different choices than you would otherwise. For example, your tool works with the Lisa OS filesystem, but did you know there are at least three versions of the filesystem? The B-tree based catalogue is only used on version 3 of the filesystem: earlier versions had different underlying structures. Now that you know that your tool is only Workshop 3.0 compatible, what might you do differently? What might you have done differently if you had known this at the beginning, along with all the other background info we've discussed?

You can use coding agents as learning tools. For example, you may not know what a B-tree is or why someone might want to use this data structure as the basis for a file catalogue. (Plenty of people got advanced computer science degrees without ever having to learn this; I certainly never had it taught in my own schooling.) Claude will explain this to you with as much patience as you can afford. Repeated chats like this could unlock a lot of new knowledge for you and may ultimately help train a kind of "programmer's instinct" for thinking about programming in general --- and that will help you use coding agents better. But you can also get that same kind of knowledge by talking to programmers about programming (maybe look beyond your developer friends here though...) or by reading books, watching good youtube videos, etc.

So I will (oops!) venture a second opinion here: if you do choose to use coding agents, ask the agents to explain to you what they are doing. Ask follow-up questions. Ask them to speculate and explain how others might have done it differently, or even how an experienced person might have themselves prompted a coding agent to do the same job.

People have concerns about the social and environmental impacts of using coding agents or other large-scale AI systems. You may wish to research these concerns to determine whether you can use AI systems yourself in good conscience. You will find people with strong views on all sides of this debate.

One side remark: "Public domain" doesn't mean abandonware, it's just a statement about who owns something. Putting something into the public domain means relinquishing your ownership of that thing and declaring therefore that nobody owns it. You (or anyone) can still choose to maintain it, or not. SQLite is a public-domain software library that will be present in every modern computer or phone that you use and is very much maintained.

Quote from: TorZidan on August 04, 2026, 03:21:26 PMWith this approach, there are a lot of steps to "bring" the text file to your ProFile hard drive on the Lisa, including ejecting/inserting SD card, restarting the Lisa (which perhaps can be replaced with "eject the floppy disk in Workshop"), running commands on your PC and on the Lisa. And, in addition, it has a lot of limitations, as disclosed. And you must have a FloppyEmu (I don't have one).

In my opinion, the least-amount-of-friction is serial wire transfer, the way Alex transferred the LOS source files to a Lisa:
- On the Lisa side, in Workshop, you just run a macro that receives the file, compiles it, links it and runs the produced binary, all in one macro.
- On the PC side, you just run a command to send the file using a serial transfer program. The speed is acceptable.
- Once you figure it out (what kind of serial cable, what port on each side, etc), it works consistently well.

I agree. As you don't have a FloppyEMU, some don't have a serial cable, and I don't always have my PC near my LISA. So both are great tools; I think it will be a matter of equipment and preference.

I also found that once I go through the steps a few times, it seems pretty fast and easy. I am sure that is likely also true for the serial path.