LisaList2

And after all, Lisa is supposed to stand for "Local Integrated Software Architecture". Now even though Apple probably spent no more than two minutes contriving that silly backronym, we can still try to integrate the software... (locally, I guess).

Quote from: bmwcyclist on October 30, 2026, 08:43:36 PMOk, you have me convinced to give it a try...

It's not at the top on the list but it is on the list now!

Excellent! Give it a go. I hope Alex will be OK with letting the result come out.

The parallel port is a pretty speedy channel for Lisa data I/O, second only to an expansion card. The nice thing about this concept you're working on is, as you say, most people already have an ESProFile, which is a relatively capable computer connected to the back of your Lisa. Demonstrating a driver that adds to existing ProFile functionality will open a very fast option for using these computers for other things.

One thing you might want to consider (or want Claude to consider) in your design is modularity.

A stock ESProFile is like a ProFile with an additional hard drive image management feature. The "magic blocks" mechanism described in this protocol document offers a way to add these "plus" features in a modular way: you can just stack them on, allocating more magic blocks to each new feature. They don't have to interfere with each other: each feature uses different blocks to other features. It's similar to how installing one piece of software on a computer (usually) doesn't keep you from adding or using another unrelated piece of software.

When you create your FujiNet driver, you'll use some more "magic blocks" on the ESProFile side of things --- no problems there. But the driver on the Lisa OS side will have to play nice with the existing ProFile driver for disk I/O. I am pretty confident that Claude will figure out a good way for it to do that, and anyway we have no choice about it: replacing the ProFile driver is probably not a reasonable thing to expect users to do.

What you may want to tell Claude to do, though, is to come up with a design that allows for the same kind of modularity that the magic blocks mechanism has on the ESProFile side. That is, make sure that Claude writes your driver so that it doesn't close the door on other people being able to write drivers for their own ESProFile extensions. If you do this, then if someone new comes along with a great idea for additional ESProFile functionality, they can choose their own new magic blocks (which leaves your FujiNet blocks untouched) and they can ship their own driver that doesn't interfere with your driver. People can have this new functionality and FujiNet working at the same time; they don't have to choose one or the other. That's the win of modularity.

To accomplish this, Claude may need to work out some kind of prioritisation or locking scheme that prevents two drivers from trying to use the ESProFile at the same time. (It may not be necessary given how the Lisa OS uses cooperative multitasking, but maybe it's still desirable in case someone does implement a Lisa OS with preemptive multitasking someday.)

If Claude does come up with a modular driver design, then because there may be other projects that want to add and use new ESProFile features, Claude should publish the technical details of this design online so that everyone can use this flexible new system. This is the same spirit behind that protocol document: it's all about coming up with designs, capabilities, and parts that other people can also take advantage of in order to make projects of their own, and getting them all to work together.

--- (philosophical digression) ---

This same idea (making bits that other people can use) is why when I made the Selector, I wrote a low-level I/O library that I released separately. (I'll be updating this library when I do my square-pixel fix in December.) Anyone can use this code in their own projects --- and some people have! When the GEM source code for Lisa was discovered, the code for reading and writing to the disk was missing. My ProFile I/O module was ready to go, and GEM was revived on the Lisa. Nowadays you would tell the AI to write that particular item from scratch, but it still pays in general to think about making designs that let multiple people share and benefit from the same resources. Modularity is one of best weapons in the software engineering arsenal for that.

(And now you can see the engineering philosophy behind my feature request to @TorZidan to break his filesystem library into separate modules. There's so much useful stuff in there that lots of projects could benefit from!)

Quote from: stepleton on October 30, 2026, 05:41:39 PMFor your consideration...

One thing though. Alex gave me the green light for this project but he might want to keep a driver project for his own.

.

Quote from: stepleton on October 30, 2026, 05:41:39 PMSo a lot of the research may be done, and perhaps you could even point Claude at this thread to ask it to give the project a shot. It might get very far indeed, it would be good experience (putting drivers on the menu can unlock some cool opportunities), and from an design standpoint I think it would be a superior solution.

For your consideration...

Ok, you have me convinced to give it a try...

It's not at the top on the list but it is on the list now!

Quote from: TorZidan on October 30, 2026, 05:14:43 PMSo let's assume you have one RAM board in slot MEM1 (verify this!!!). The error is 8000 in Bank C on the board, which is the ram chip in column 8. So pull tooth C8.

I put in piggy back chips in C8 and D8 (both one at a time and together)

got
00000186 0000 8000 0000 0000 0000 0000 0000 0000

and
00000186 0000 0000 8000 0000 0000 0000 0000 0000

and even
00000186 0000 8000 8000 0000 0000 0000 0000 0000


AI said this

The Real Problem: Shared Logic Components

When multiple entirely separate blocks across two different boards fail on the exact same bit, it points directly to the logic gates handling that bit array line. You need to pull out the boards and inspect the Logic Multiplexers / Transceivers that drive Column 8.

Look at the logic chips at the bottom or sides of the memory board PCBs (typically 74-series logic). Specifically, look for:

1. 74LS244 or 74LS245 Octal Buffers/Transceivers: These handle the data bus lines coming off the RAM columns to send them back to the Lisa motherboard. A single failed gate inside a 74LS244 handling Data Line 15 will cause every single row block in Column 8 to fail simultaneously on that board.

2. 74LS153 or 74LS257 Multiplexers: These route the address strobe lines (RAS/CAS) across the row selections.

Not sure where 74LS244 is but I did examine and touch each chip RAM card still looks OK, and when I boot into Mac XL is shows 908K with a known good 512RAM card and my failing 512RAM.  But it doesn't load with just the 512RAM card (but it was in slot 2, with slot 1 empty).

Quote from: bmwcyclist on October 30, 2026, 02:24:35 PMWriting a driver is more than I want to take on right now but... maybe someday.

It's probably not as hard as you think --- the Lisa device drivers manual is here:
https://www.applefritter.com/content/lisa-device-drivers-manual

Even better, here is a Lisa program that uses a device driver strategy that you could direct Claude to copy:
https://pappadf.github.io/lisa-share/
https://github.com/pappadf/lisa-share
https://tinkerdifferent.com/threads/c-development-environment-for-apple-lisa-and-an-lisapaint-example-app.5674/#post-50529

You would also give Claude access to the Lisa OS source, although I expect you may already be doing this.

(I'm burying the lede a little bit because this is actually quite an impressive bit of software on its own: LocalTalk/AppleShare file sharing for the Lisa Office System. The software is written in C, using a compiler that the author also vibe-adapted to the Lisa platform, running on an emulator that the author also vibe-coded, but I don't think Claude would have any trouble converting to Pascal or your language of choice. The gimmick of using copy/paste to move files is really interesting too. One thing I like about this software is that it also really seems to match the style and usage patterns of other Lisa software, which is nice.)

So a lot of the research may be done, and perhaps you could even point Claude at this thread to ask it to give the project a shot. It might get very far indeed, it would be good experience (putting drivers on the menu can unlock some cool opportunities), and from an design standpoint I think it would be a superior solution.

For your consideration...

Quote from: berskyboy on October 30, 2026, 03:24:57 PM

Quote from: berskyboy on October 29, 2026, 09:22:28 AMI tried the Piggyback method still getting
00000186 0000 8000 0000 0000 0000 0000 0000 0000

00000186  0000 8000 0000 0000 0000 0000 0000 0000
https://www.dropbox.com/scl/fi/kvfsgapov3rf3fizzh8ik/IMG_4151.jpeg?rlkey=ke4waclbeexuouu5rm4jqhzee&st=e0t9slf7&dl=0

every time I ask AI to tell which chip it says different chips.  Is there a lookup document? 
I tried this website but it's down

https://lisafaq.sunder.net/single.html#lisafaq-hw-mem_error

Here is a copy/paste from my records:

Each memory board has 4 banks (of 16 chips each), named "A,B,C,D".
Each "word" (4-digits in your post) corresponds to a memory board + "bank".
Look above for banks that show non-0000: they have faulty ram chip(s).
If there is one memory board in slot MEM 1, then the 8 words are for the following banks:
  B C D E  x x x x          (x means "unused")
If there is one memory board in slot MEM 2, then the 8 words are for the following banks:
  E D C B  x x x x
If there are two memory boards installed, then the 8 words are for the following banks:
  MEM 2    MEM 1
  E D C B  B C D E

Now that we determined the board and bank(s) that have bad ram chipss, we need to determine the ram chip column number in each bank:
Word  Bit#= Column Number
  0001  0  =  22
  0002  1  =  21
  0004  2  =  20
  0008  3  =  19
  0010  4  =  18
  0020  5  =  17
  0040  6  =  16
  0080  7  =  15
  0100  8  =  1
  0200  9  =  2
  0400  10  =  3
  0800  11  =  4
  1000  12  =  5
  2000  13  =  6
  4000  14  =  7
  8000  15  =  8
If there is more than one bad chip in a given bank, there will be more than one bit set and you'd get a word different that the ones above.
In this case, proceed to identifying the bad chip similarly to how it's done  on a Macintosh 128k.


So let's assume you have one RAM board in slot MEM1 (verify this!!!). The error is 8000 in Bank C on the board, which is the ram chip in column 8. So pull tooth C8.

Quote from: sigma7 on October 28, 2026, 01:55:27 PMThere is an adapter design to use an EPROM in lieu of the one-time-programmable 20 pin bipolar PROM, but I've not tried it.

Note that the Video PROM contains the Lisa's Serial Number, so there are numerous variants of the programmed contents of this part (containing different serial numbers).

I believe you are in Canada with me, so I may be able to provide these; contact me privately to discuss.

sure thing, I did drop you an Message.

Quote from: ried on October 29, 2026, 04:36:31 PMYours is part number 341-0348, which is for Macintosh XL computers that boot only Mac OS. If you want to boot LOS, you'll need to remove that PROM and replace it with 371-0072, and disconnect the transformer between the Lisa's Video Board and the CRT - thereby enabling Lisa Office System's native resolution.

This is what shows up in Mac XL with the black borders on each side, and when I put the CRT P1 and P2 it went directly into the Lisa Video Card, so maybe it's still stock CRT?

https://www.dropbox.com/scl/fi/bour2rbj1jygmhpvmg7fd/IMG_4174.jpeg?rlkey=ecybjape2jj2gg65qdu3mzf0l&st=2fpr9klf&dl=0