LisaList2

I am sure I missed a few, let me know which ones. I know about the new Star Trek one but that is not LOS it runs from the workshop.

All of these are free Lisa Office System (LOS) apps. Where to get them:

- GitHub (source and downloads): github.com/GyroPilot (Minesweeper: github.com/alexthecat123/los_minesweeper)
- The Apple Lisa BBS: telnet theapplelisabbs.duckdns.org 1983, Images > Release floppy images
- GlobalTalk: zone LisaGaming, server "netatalk" or "lisa-mon1", volume "new mac and lisa releases" (Guest)
- LisaList2: lisalist2.com
- 68kMLA: 68kmla.org


You cannot view this attachment.

Quote from: AlexTheCat123 on November 01, 2026, 09:55:44 PMYeah, I'd go with the magic block approach for sure. It's got the downside of requiring that you write a driver of course, but that shouldn't be all that difficult when you have Claude to help. We already agreed via email that I'm not responsible for any issues with this fork of the code, so that should be taken care of!

Thank you!!!

I wanted to make sure.

.

Quote from: stepleton on October 31, 2026, 01:37:27 PMAs far as Alex goes: I can't speak for him, but it would seem to me that this magic blocks approach is accomplishing the same thing you negotiated earlier, using a safer and more conceptually dedicated method. I'll defer to his judgement but I would guess that he would like this approach about the same. The main thing I would expect him to care about is whether people are going to knock on his door if your system breaks --- since he didn't write it, he can't take responsibility for it. That situation is the same as what exists today, and it will not have changed if you switch to using a driver approach instead of a mailbox file. Of course, it would be best for Alex to confirm this.

Yeah, I'd go with the magic block approach for sure. It's got the downside of requiring that you write a driver of course, but that shouldn't be all that difficult when you have Claude to help. We already agreed via email that I'm not responsible for any issues with this fork of the code, so that should be taken care of!

Quote from: berskyboy on November 01, 2026, 09:00:42 AMI tried the piggyback method and it didn't fix my bad RAM card.

Please provide a link to the method you tried... is it Lisa specific?

Regardless, it doesn't always work as its success depends on the failure mode of the chip underneath (assuming the chip underneath is indeed the problem).

The lisafaq description of how to interpret the self-test error breadcrumbs in memory is, AFAIK, reliable. So unless those breadcrumbs are not giving consistent results, I'd suggest proceeding to remove the faulty chip, install a socket, and try a new chip. It is very difficult to desolder the power and ground pins, you may want to cut them and desolder them after desoldering the other pins and removing the chip. You may need two irons, one on each side of the board; that requires 4 hands of course.

Is there a longer test to run on the RAM other than Apple - S, option 1 and 186 20?  I tried the piggyback method and it didn't fix my bad RAM card.

PS: Regarding this:

Quote from: bmwcyclist on October 31, 2026, 10:56:06 AMI know that I am far (far) from the most qualified to take this on, so hopefully Alex or someone else will take on this open system you propose. I think what I could concoct would be very poor compared with what a more Lisa and development experienced person could accomplish.

The AI approach to writing software is very, very powerful, and it lets one person accomplish quite a lot all by themselves. In fact, I think it often makes people feel like they have to do things all by themselves. This is not the case!

Back before it was possible to vibe code so powerfully, even those of us who had experience would often ask questions and trade around ideas on forums like this one. We'd run into problems, puzzle over whether things were possible, think about the best way to do things, and ask people for feedback on ideas.

We can still do all of these things.

A project may seem like a big job even with Claude, but it doesn't have to be that big if we talk to each other. In this case, I'd expect that our conversation has made making a driver seem a lot easier than it might have seemed initially --- at least I hope it has! So there's still a use for us people after all: we can talk about things and combine our thoughts. We'll get the benefit of each others' ideas and perspectives and experience, we'll overcome individual shortcomings (e.g. not knowing how to write drivers), and we'll have the chance to learn from each other.

For all of the wonders of the AI age, the thing I like about it the least is that it seems to draw people away from the social element of software-making. Stack Overflow is the best example of this: its traffic has basically cratered (of course it had its own culture pros and cons). But it also happens in smaller spaces like ours, I think. It doesn't have to be that way: AI could add to what a community can do instead of substituting for it.

So the next time there's a good idea floating around out there --- let's talk about it! Maybe we can all make it happen together, and make something better than we could put together alone.

Thanks for asking your intern!

So far the only person I'm aware of who's written a driver has been the PappaDF person who made lisa-share. You would be the second. But I wouldn't be too worried about breaking new ground here. Writing a driver is complicated, but we have examples, documentation, and the underlying OS source code. If your driver is going to engage the Lisa OS's ProFile driver to read and write blocks in a normal way (which I am pretty sure is all you need), then as long as you are reading and writing to just your own magic blocks, I think the risk should be pretty low.

Your intern asked in question 4 how best to share the parallel port with the OS. I think its answer A is the best option if it's possible. If Claude concludes that it is not, then more thinking will be necessary.

To confirm low risk, what would also be good to ask Claude is this: suppose we are taking option A. Is using the existing ProFile driver going to change any of the internal state of that driver in a way that might make it give confusing or wrong responses to the OS when the OS uses the driver for its own needs? You might also ask if we need to worry about what could happen if your small FujiNet driver and the OS want to talk to the ESProFile at nearly the same time. If the answer to both of these questions is "no", then it's pretty likely that there won't be much of a problem.

As for choosing which magic blocks to use: there is no central authority. The ones we have so far are just ones that I have chosen for my Cameo/Aphid hard drive emulator, which Alex reused when he made the ESProFile. It's much like the Office System tool serial number situation, though with our block mechanism it makes sense for the blocks to be way up at the top of the address space. Right now the lowest used block is $FFFEFC, and there's nobody else working on a project to make new ones. So, if Claude only needs to reserve one block as a kind of channel for talking to the FujiNet functionality that you've added to ESProFile, why not use $FFFEFB? If two, $FFFEFA and $FFFEFB? And so on.

---

Now, one easy thing you can do to experiment with this driver concept is this --- and here you don't need a modified ESProFile. Ask Claude to create an "Option A" driver that uses the existing magic blocks mechanisms in the protocol document to do either of two things: either use the $FFFEFE magic block to get a listing of the image files on the ESProFile, or use the $FFFEFD mechanism to get the emulator status information.

The first thing is a more interesting thing to do, but it may be harder for the "Option A" driver mechanism since it requires your driver to be able to use a specific "sparing threshold" and "retry count" when talking to the drive. It doesn't matter what those parameters are, but if you are curious you can read more here just below Table 1. But if you can do that, then the objective should be to write an Office System tool that loads this driver and displays the list of images on an ESProFile, which would be pretty nifty!

If the first thing can't be done, then the second one is still worth trying. A driver for retrieving the emulator status doesn't have to use custom sparing and retry parameters, it just has to read block $FFFEFD. The information it gets back is the information that displays at the bottom of the Selector, which is more meaningful on my Cameo/Aphid emulator than it is on an ESProFile. Still, all we need is to show that it works, not make it do something interesting. If you can make an Office System tool that loads a driver and uses it to access and display the emulator status, then you've done it.

Either little demonstration would probably be pretty safe since it's not writing to the drive, only reading it. And if you can get any of them to work, then you've basically won. That's the hard part. Writing the rest of the driver should be fairly automatic from there: Claude can basically take what it reads and writes to MAILBOX.DATA and read and write it through a driver instead. Networks are not as reliable as hard drives, so Claude should take care to handle that gracefully so as not to lock up the machine with the driver, but so long as the driver itself is written sensibly it should not be an issue. (For example, reads corresponding to network requests should probably not wait until the data is available but should instead return immediately; either there might be an interrupt facility that the driver can use when the network request is satisfied, or the application can poll the driver to see if there is data ready to read.)

---

As far as Alex goes: I can't speak for him, but it would seem to me that this magic blocks approach is accomplishing the same thing you negotiated earlier, using a safer and more conceptually dedicated method. I'll defer to his judgement but I would guess that he would like this approach about the same. The main thing I would expect him to care about is whether people are going to knock on his door if your system breaks --- since he didn't write it, he can't take responsibility for it. That situation is the same as what exists today, and it will not have changed if you switch to using a driver approach instead of a mailbox file. Of course, it would be best for Alex to confirm this.

I had my AI intern and tutor read everything you linked, plus Apple's ProFile driver source, and check it all against Alex's ESProFile firmware.

Here is what we found.

1. The drive side mostly exists already.
Alex's ESProFile firmware already speaks the Cameo/Aphid protocol that the Selector uses:

- Block $FFFFFF returns the spare table, which identifies the drive as "Cameo/Aphid 0001".

- $FFFEFD gives emulator status, $FFFEFE file information and file operations, and $FFFEFC Selector rescue.

- $FFFFFD takes the built-in commands (HALT and IMAGE:).

- $FFFEFF is the key/value store, but only the two keys the Selector needs (moniker and autoboot).

So ESPFuji would only need one more reserved block, or a small range, for network requests and replies.

That number should be agreed with you and Alex, so the Selector, ESPFuji and anything later never collide.

2. The stock ProFile driver cannot reach those blocks.

In Apple's source, DCONTROL handles only three codes: 15 (last error), 20 (disk status) and 21 (sparing on
or off).

Everything else goes to HDISK as ordinary blocks of the volume.

So a Lisa Office System tool needs a driver of its own, as you said.

lisa_io drives the 6522 directly, which suits bare-metal programs like the Selector, but not a tool running under the OS, because the OS owns the port.

3. Loading a driver at run time is a solved problem.

pappadf's lisa-share already does it. The driver is copied to the boot volume as SYSTEM.CD_<name>, then the tool calls CDINFO, CDKILL, CDMAKE and MOUNT, and puts the old driver back when it quits.

The rules are clear too: one read-only code segment, no writable globals, state kept in a GETSPACE block, and kernel services
only through the driver jump table.

4. The hard part is sharing the port.

The ESProFile is usually the boot disk, so Apple's ProFile driver is busy serving it. A network driver has to reach the reserved blocks on the same drive without taking the port away.

The options as I see them:

a. A small driver that sends its requests through the existing ProFile driver, adding only the reserved block numbers. This is the least invasive, if Apple's driver will pass on a block number it would never choose itself.

b. A replacement ProFile driver, Apple's source plus the reserved blocks, loaded the lisa-share way. This gives the most control, but it is the boot disk's driver, so it carries the most risk.

c. On the Macintosh XL under MacWorks, a Mac driver, or the block-range mailbox already on the ESPFuji 1.1 beta branch.

Suggested approach :

- Publish the design before any code, as you suggested, and keep it modular so other drivers can share the drive with locking or priority.

- Ask Alex first whether he wants this project for the stock ESProFile.

- Keep the file mailbox as the fallback, and update all the Lisa tools together when the route changes.

- Near term, rename MAILBOX.DATA to something distinctive.

- Expect two to three weeks, with every driver test on a spare ESProFile image first, since a bad driver can stop the boot disk.


What we read:

- Cameo/Aphid PROTOCOL.md: https://codeberg.org/stepleton/cameo

- lisa_io: https://github.com/stepleton/lisa_io

- Apple's Lisa Device Drivers Manual, January 1984 draft:
  https://www.applefritter.com/files/2018/09/10/LisaDeviceDriverManual.pdf

- pappadf's lisa-share, docs/architecture.md and driver/atalk.c:

https://github.com/pappadf/lisa-share

- The Lisa OS source files source-PROFILE and SOURCE-PROFILEASM (Computer History Museum release)

- Alex's ESProFile_Emulator.ino: https://github.com/alexthecat123/ESProFile

Corrections are welcome, especially from anyone who has written a Lisa driver.

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.

so I did the following

RAM      Slot        Error      Mac XL                  Service Code
B, A      1, 2         70          Works show 908k  00000186 0000 8000 0000 0000 0000 0000 0000 0000 (D8)
B          1             passes   Works show 304k  00000186 0000 0000 0000 0000 0000 0000 0000 0000
A          1             70          two beeps              00000186 0000 0000 0000 0000 0000 0000 8000 0000 (D8)

so it seem D8 is the culprit, I did piggy back it, here's the photos

Also I got an error 75 once and sound cut out twice also.

https://www.dropbox.com/scl/fi/4v4sdpmig7z0m5hokv48e/IMG_4180.HEIC?rlkey=jhvf8iqqthiq81sveanoociq5&st=6woi5hrl&dl=0
https://www.dropbox.com/scl/fi/5ie0w2jxpttjy83tf8uy8/IMG_4181.HEIC?rlkey=4q2ju9g0drmdiwmagc0grqvlc&st=748nxi4s&dl=0

 

Well you know what I like!

Making something free the community can (and will) use is a huge motivator for me.

With the emulators, sourcecode, FPGA and (I'm not sure the browser OS model is) it seems now is our chance make a strong lasting Lisa OS inspired hobby.


I know that I am far (far) from the most qualified to take this on, so hopefully Alex or someone else will take on this open system you propose. I think what I could concoct would be very poor compared with what a more Lisa and development experienced person could accomplish.

Additionally, while some have warmly embraced what I have tried to contribute so far, there have been some that don't want to touch anything developed with AI assistance.

I work in infosec so I have embraced AI as inevitable some time ago, its mitigation not exclusion IMHO. I know that projects like this are not "made by AI" they are made with AI assistance. I call Claude my intern and tutor. But many seem to think that you just push a AI easy button and poof its done.

So the point I am getting to is; the very core motivation for me to do this is to have people use it, yet the only way I could do it may undermine its acceptance.

With my other projects, I am fine with that, take it or leave it as far as I am concerned. But this might be different, I don't know. I would need some feedback. 

That said, with Alex's blessing, if no one else steps foreword by the time my Marchintosh projects are complete i will see what I and my intern can accomplish.