You likely have WIRELESS INTERNET ability in your LISA right now!

[bmwcyclist]

If your Lisa boots from an ESProFile (Alex Anderson-McLeod's ESP32 ProFile emulator), it can now reach the internet with no other hardware.

Alex has approved of this being published, but he does not support the ESPFuji firmware in any way: ESPFuji questions and bugs go to the repository's Issues, never to Alex. The ESProFile boards and the stock firmware remain his.

ESPFuji is a firmware for the ESProFile that leaves the ProFile emulation exactly as it is and adds a network task on the ESP32's second core: a Lisa Office System program writes a request into a file on the ProFile volume, the drive fetches the page over Wi-Fi, and the program reads the reply back from the same file. Nothing on Serial B.

What it does: HTTP and HTTPS pages up to 32 KB, and the time of day from SNTP, in your own time zone. LisaFuji 1.2 (news, Wikipedia, the space station map, the weather, the clock) and LisaCheckers find the drive by themselves and use it instead of a serial FujiNet; the first complete checkers game through an ESProFile was played on 29 October.

What 1.0 rests on: one Lisa 2/10 and two ESProFile boards, a month of work, an 8-hour idle soak, 1,500-fetch overnight runs and a day-long soak of the release code with a fetch and a clock check every 15 minutes, nothing lost. Flashing is one Python command from Windows, macOS or Linux; the script backs up your original firmware first and puts it back with one command, and the SD card is not touched. The repository: https://github.com/GyroPilot/ESPFuji (not the official ESProFile repository, which is github.com/alexthecat123/ESProFile).

Release, README and the test tool floppy: https://github.com/GyroPilot/ESPFuji/releases/tag/v1.0

I will be posting an informational presentation later today if the internet at this campground holds!

I will attach the software images although it seems most people download from GlobalTalk or GitHub. I think LIsaList2 is a good archive.

If you are using LisaFuji software (Checkers, Salvo, LisaBrowser etc.) you will need an update to use this.

[stepleton]

This is another considerable capability enhancement, but I have to say that the method that this approach uses is a fairly strange one in my opinion. It requires the ESProFile to have some rudimentary understanding of the Lisa OS filesystem, or at least it must detect read and write patterns characteristic of Lisa OS file I/O. Different OSs would not readily be able to use this approach. It does have the advantage of not requiring the Lisa to have any special driver software. That said, changing the contents of a file without the OS's knowledge feels kinda weird...

...It works, there's not likely to be a fundamental reason it wouldn't continue working (unless there are radical community updates to the Office System, which these days who knows), but to this longtime programmer, it just feels kinda... cursed I guess... (It is Halloween, I suppose!) It's not the kind of thing you would ordinarily do, just because it kinda violates assumptions that other programmers and programs make when they code for a computer platform. What if someone else is writing an email app and chooses to store emails in a file with a perfectly ordinary name like MAILBOX.DATA? There would be trouble! (And while using a more obfuscated name like ~~00MBOX~~.DATA would reduce the odds of collision, it still feels like a bit of an untidy workaround to a risky method; there'd be something 95-era Microsoft about it.)

The ESProFile has other ways of exposing special functionality that goes beyond what a regular ProFile does. The Selector takes advantage of this functionality to list disk images and make changes to them. It's modular and extensible; you can add to it. There's documentation all about it here:

https://codeberg.org/stepleton/cameo/src/branch/master/aphid/selector/PROTOCOL.md

To take advantage of this capability, you would just say on a forum like this one, "I'm reserving another one of these 'magic blocks' for myself" (or more than one if you wanted, there are tens of thousands) and then have direct reads or writes to your magic blocks engage the FujiNet functionality. This would no longer rely on having an operating system that writes to files in the way the Lisa OS does. The downside is that you would need to make and install a driver on the Lisa OS. But Claude appears to be quite good at making drivers, the Lisa OS has a very sophisticated and capable driver system, and we have already seen projects ship custom drivers for various things. Other OSs like MacWorks and the Unixes would need drivers too, but it would probably be a good amount easier to make those than to make them do something that looks like the Lisa OS writing to a file.

So I guess I'm excited by the idea (have been interested to try out FujiNet for a while), but I'd hope for a different execution of it. I hope this criticism is welcome and that it seems constructive. I am sure it would be well within the grasp of the tools to do it in this way. What do you think?

[bmwcyclist]

Lisa FujiNet tools, 30 October 2026 update (Lisa_FujiNet_Tools_2026-10-30_pack.zip)

Every tool in the set now works three ways:

through an RS-232 FujiNet on a serial port,
on a LisaFPGA through LisaNet, Michael Wottle's ESP32 add-on on the FPGA's GPIO header,
or through an ESPFuji ESProFile, the drive your Lisa already boots from, with no serial adapter. Put the tool on the drive's own volume and it finds the network by itself.

What's in the zip:

LisaFuji 1.2: news, Wikipedia, the space station and crew, the weather, and the Lisa's clock from the network
LisaFuji Browser 1.2 beta: a text web browser
LisaTwinClock 1.3: sets the Lisa's clock from the network
LisaCheckers 1.2: checkers against the Lisa or people on other machines
LisaSalvo 1.2: Battleship on the FujiNet Battleship server
ESPFuji test tool 0.2: checks an ESPFuji drive and sets up its mailbox

Six Disk Copy 4.2 floppy images with a read-me each, for a Floppy Emu, BlueSCSI or LisaEm. Lisa Office System 3.1. Free and open (MIT); sources at github.com/GyroPilot. Thanks to Michael for LisaNet, and to Alex Anderson-McLeod for the ESProFile.

[bmwcyclist]

This is another considerable capability enhancement, but I have to say that the method that this approach uses is a fairly strange one in my opinion. It requires the ESProFile to have some rudimentary understanding of the Lisa OS filesystem, or at least it must detect read and write patterns characteristic of Lisa OS file I/O. Different OSs would not readily be able to use this approach. It does have the advantage of not requiring the Lisa to have any special driver software. That said, changing the contents of a file without the OS's knowledge feels kinda weird...

...It works, there's not likely to be a fundamental reason it wouldn't continue working (unless there are radical community updates to the Office System, which these days who knows), but to this longtime programmer, it just feels kinda... cursed I guess... (It is Halloween, I suppose!) It's not the kind of thing you would ordinarily do, just because it kinda violates assumptions that other programmers and programs make when they code for a computer platform. What if someone else is writing an email app and chooses to store emails in a file with a perfectly ordinary name like MAILBOX.DATA? There would be trouble! (And while using a more obfuscated name like ~~00MBOX~~.DATA would reduce the odds of collision, it still feels like a bit of an untidy workaround to a risky method; there'd be something 95-era Microsoft about it.)

The ESProFile has other ways of exposing special functionality that goes beyond what a regular ProFile does. The Selector takes advantage of this functionality to list disk images and make changes to them. It's modular and extensible; you can add to it. There's documentation all about it here:

https://codeberg.org/stepleton/cameo/src/branch/master/aphid/selector/PROTOCOL.md

To take advantage of this capability, you would just say on a forum like this one, "I'm reserving another one of these 'magic blocks' for myself" (or more than one if you wanted, there are tens of thousands) and then have direct reads or writes to your magic blocks engage the FujiNet functionality. This would no longer rely on having an operating system that writes to files in the way the Lisa OS does. The downside is that you would need to make and install a driver on the Lisa OS. But Claude appears to be quite good at making drivers, the Lisa OS has a very sophisticated and capable driver system, and we have already seen projects ship custom drivers for various things. Other OSs like MacWorks and the Unixes would need drivers too, but it would probably be a good amount easier to make those than to make them do something that looks like the Lisa OS writing to a file.

So I guess I'm excited by the idea (have been interested to try out FujiNet for a while), but I'd hope for a different execution of it. I hope this criticism is welcome and that it seems constructive. I am sure it would be well within the grasp of the tools to do it in this way. What do you think?

Thank you!

Great point about the filename, I did not think of that at all.

There are now 4 ways to connect the Lisa LOS to Fujinet; ESprofile is just one, but it does have an advantage in speed, and lots of people already own one.

I will make a filename change in the next version.

Writing a driver is more than I want to take on right now but... maybe someday.

If someone else is up for it, I would be more than happy to collaborate!

All constructive feedback is VERY welcome!

[stepleton]

Writing 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...

[bmwcyclist]

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...

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!

[bmwcyclist]

For 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.

.

[bmwcyclist]

[stepleton]

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!

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!)

[stepleton]

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).

[bmwcyclist]

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.

[bmwcyclist]

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.

[stepleton]

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.

[stepleton]

PS: Regarding this:

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.

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.