LisaList2

With the recent revival of the thread about an LOS accelerator, I thought that it might be a good idea to have a quicker, easier, and cheaper way to prototype and test new Lisa hardware. And also a way for people to have a 100% authentic Lisa experience (no emulation) without having to buy or build an actual Lisa. So I figured I'd try and implement the entire machine in SystemVerilog on an FPGA.

I'm still pretty early into the project right now, so there's a decent chance of failure or it taking forever, but I figured I'd at least tell everybody about it.

So far, I've written SystemVerilog modules for the 512K RAM board and the CPU board. I'm in the process of testing and debugging them right now, and needless to say, there are still a LOT of problems to work out. But most of the timing logic (Page 2 of the CPU board schematic) seems great, and I just got the CPU to start fetching instructions from the ROM, although it's clear that it gets stuck pretty quick. The video state machine seems mostly functional too, although I think there's some signal contention messing something up there. So it's just slow incremental progress, chipping away at each failure until I slowly get closer to a working CPU board. I think there are some serious problems with the MMU, so that one might take a little while.

I'm going to wait and do the I/O board once I get the CPU and RAM boards fully-working (or at least as fully-working as I can test without the I/O board). If I remember correctly, a Lisa without an I/O board should boot loop with some sort of error on the screen, so this should be a good enough configuration to validate minimal functionality of most of the CPU board and RAM hardware.

I'll keep you guys posted on my progress, or lack thereof!

Neat! I'm curious enough to press for more details --- answer whatever you feel like answering:

What FPGA are you using?

What 68k core are you using?

As one goal is to support developing new Lisa hardware (I'm imagining the situation where I want to develop a new expansion card), do you expect developers to prototype the hardware inside or outside of the FPGA? If the latter, how will you cross the +5V barrier?

Good luck!

Fantastic!

Please keep us updated!

Quote from: stepleton on September 05, 2025, 03:44:53 AM
What FPGA are you using?

I'm using a Xilinx Pynq-Z2 board with a Zynq 7020 chip on it, just because it's what I already had on hand. No particular reason, although I avoid anything from Altera at all costs because of how horrible Quartus is. Note that I haven't actually run the Lisa on the FPGA yet, short of synthesizing and programming it once just to make sure that my design is synthesizable. All of my testing is being done in simulation to save heaps and heaps of time.

Quote from: stepleton on September 05, 2025, 03:44:53 AM
What 68k core are you using?

The FX68K (https://github.com/ijor/fx68k) because it's supposed to be cycle-accurate, and a lot of the CPU board timings in the Lisa are centered around the timing states of the original processor. It gets clocked differently from the original 68K though, and I don't think its clock is in phase with the rest of the system right now.

Quote from: stepleton on September 05, 2025, 03:44:53 AM
As one goal is to support developing new Lisa hardware (I'm imagining the situation where I want to develop a new expansion card), do you expect developers to prototype the hardware inside or outside of the FPGA? If the latter, how will you cross the +5V barrier?

Right now, I'm picturing people designing their hardware inside the FPGA so that they can get a working prototype going way faster and cheaper than with real hardware. But once it comes time to convert that design into real hardware, I think bidirectional level shifters will be the way to go.

An update on my progress: I can now confirm that the Lisa is getting through the ROM checksum tests and the MMU tests and configuration routines in the boot ROM, all the way up to the point of enabling the MMU for access to RAM. The MMU even seems to translate its first RAM address properly, although it's just address 0 and a 0 could pop out in a variety of failure modes, so that doesn't really confirm a whole lot. But then when it tries to talk to RAM for the first time, it never gets a /DTACK and everything screws up. I've traced the problem down to /CAS getting inhibitied when it shouldn't be thanks to a slight timing discrepancy with the address strobe. Now I'm just having to figure out why the address strobe doesn't quite look the way that it's supposed to. I hope they weren't mistaken when they said the core was cycle-accurate; it's probably just a case of me screwing up the weird 2-phase clock that the core requires.

Good news! After much debugging, according to my simulations, the FPGA-based Lisa is making it all the way to the point where it tries to talk to the I/O board, realizes it's not there, and shows an error code on the screen!

This means that much of the logic on the CPU board is confirmed working, including the entirety of the MMU, all the timing stuff, the system control latch, video address latch, bus error circuitry, and so on. There are only a few things on the CPU board that haven't been tested at this point in the boot process, like interrupts, the memory error address latch, and system status latch, but those are all really minor and easy to fix if broken.

And obviously the 512K memory board has to be pretty much fully-working to get to this point too, because the ROM has already done memory sizing, a full test of the 32K video page, and has stored constants in low RAM that it's clearly able to read back. I know that something's wrong with the RAM board's /HDER (hard memory error) signal and it's just stuck asserted all the time, but I've disabled it for now in order to get to the point of hopefully having something on the screen. It should be an easy fix when I get around to doing it.

Now it's just a matter of moving out of simulation and trying this on the actual FPGA, at which point I'll be able to see what's on the screen to confirm that it's actually displaying stuff like the instructions executing in the simulation are indicating. There's one roadblock keeping me from getting it onto the FPGA; Vivado is complaining about a double-driven net that I'm really confused about because it's clearly not being double-driven, but once I figure that one out, it should be ready to put on the FPGA and test!

Once that's working, the only big step left before we have a completed Lisa is making and testing the I/O board, which should hopefully be easier given its relative simplicity compared to the CPU board. I believe there are preexisting Verilog cores for the 6522 VIA, COP400 microcontroller series, and 6502 (which can be used in place of the 6504), but I'm not sure about the 8530 SCC. I might have to implement that chip myself.

Wow! reminds me of when Dr. Chandra revived HAL in Odyssey 2 ;)

Another update: although things worked in the simulation, they don't quite work in real life.

When I hook the FPGA Lisa up to a display, it's clearly syncing properly, so that's at least something. But the rest of the system seems to be pretty dead. After hooking some virtual logic analyzer probes up to the FPGA, I think that most of my problems are stemming from signals being in undefined states at power-on. In the simulation, these kind of work themselves out after the CPU comes to life and starts executing code, but in the actual hardware, they cascade until about 50% of the signals that I'm probing get locked up.

As the fix, I'm working on improving the reset logic so that it puts all these signals into the proper initial states, in addition to the obvious stuff that it was already doing like resetting the CPU and clearing some counters.

Unfortunately, the synthesis and implementation process in Vivado takes about 35 minutes for this design, so that's how long I have to wait to test things out each time I make a code change. It's not a fun process, so let's hope this reset thing is the only issue that arises...

More progress. After lots of work, we're making it through the ROM checksum test and MMU tests/configuration on the actual FPGA hardware now. So that means that much of the core CPU board logic is alive!

The less great news is that I've been stuck on some RAM problems for several days now. For some reason, the Lisa just isn't capable of writing to the RAM. It always reads back a zero on the actual hardware, despite working fine in simulation, and I've tried tons of things to fix this, all to no avail. It's putting out the right address and asserting all the correct control and selection signals at the right times, but the write just doesn't "stick" for some reason. I tried testing part of the RAM subsystem in a small SystemVerilog module that does nothing but write stuff into memory and read it back, and it worked fine there, so it's got to be something about its integration into the greater Lisa system. It's just a question of what. I'll keep working and let everyone know once I've figured it out!

Thanks for your work!

I wish I could help, but that is way out of my skill sets...

It's not pretty, but that is indisputably a CPU board error 41 on the screen. Which is exactly what we'd expect to get from a fully-functional yet I/O board-less Lisa!

Now I just need to figure out why it looks so terrible...

Wow, this is big news, and thank you for your efforts Alex! I can't wait to own one, and I will want one.

Quote from: AlexTheCat123 on September 19, 2025, 02:51:00 PM
It's not pretty, but that is indisputably a CPU board error 41 on the screen. Which is exactly what we'd expect to get from a fully-functional yet I/O board-less Lisa!

Now I just need to figure out why it looks so terrible...

Incredible! Where do you find the time??

Nice work!

Quote from: classiccomputing on September 19, 2025, 06:37:41 PM
Wow, this is big news, and thank you for your efforts Alex! I can't wait to own one, and I will want one.

Progress has been great so far, but it's probably going to be a while before we get to that point of other people being able to build one! Getting I/O working and deciding how much I want to modernize that stuff as opposed to requiring the use of original Lisa hardware (like adding native support for USB keyboards/mice vs making the user plug in Lisa originals) is what I anticipate to be the hard part.

For instance, I'm working on piping the Lisa's video output straight through HDMI right now, and that's proving to be a bit weird/challenging in several ways. But it'll be nice once I succeed because then we'll no longer have a need for an RGBtoHDMI, and the Lisa's contrast control can be simulated by simply adjusting the intensity of the white sent over the HDMI link.

Quote from: jamesdenton on September 19, 2025, 08:48:17 PM
Incredible! Where do you find the time??

Just working on it whenever I'm done with school and homework for the day, and as much as I can on weekends. The PhD program keeps me busy, but luckily I've still got enough spare time to fit in a couple things like this!

Thank you so much !

The video problems have been fixed; it turns out that they were being caused by a RAM timing issue where video reads from RAM were occasionally causing addresses adjacent to the current read address to be overwritten with random garbage. This one was really subtle and took a long time to figure out!

I've moved onto the I/O board now, and I've finished the initial design of the whole thing other than Page 2 of the original schematics, which contains the keyboard VIA and the COP. Since the COP core I found is in VHDL, whereas the rest of my code is in SystemVerilog, and I'm a bit nervous about integrating the two, I think I'm going to implement everything but the COP and then come back for that later. We should still get waayyy further in the boot process even in its absence.

Some people might be wondering what cores I'm using for the 6504, 6522s, 8530 SCC, and the (yet to be integrated) COP. Well, no 6504 cores seem to exist, so I'm using this (http://www.aholme.co.uk/6502/Main.htm) transistor-accurate 6502 core instead. As for the 6522 and 8530, I'm using the cores from the NanoMac project (https://github.com/MiSTle-Dev/NanoMac/). The 6522 core seems really accurate and fully-featured, but the SCC core leaves a lot to be desired; it seems to just implement the bare minimum to get the Mac to work and leaves out a lot of I/O lines used by the Lisa. But it's the only 8530 that I could find, and it should at least get us booting. And last but not least, the COP. I'll be using the T400 (https://github.com/devsaurus/t400) core, which as I said is written in VHDL instead of Verilog, which hopefully won't cause too many headaches. It also has a really weird/unpleasent way of reading in the ROM (you have to run a script that generates a VHDL file that's essentially a massive case statement for each ROM address instead of just using $readmemh) and some weird platform-specific scripts that you have to run, so I'm hoping that none of that causes a problem.

I should be able to start testing the I/O board in simulation by tonight or tomorrow, and then in actual hardware whenever I get all the simulation kinks worked out!

The 6504 is a 6502 with some pins not connected. Both parts use the same silicon die. So you can use the 6502 core and ignore the upper address lines.

Quote from: patrick on September 25, 2025, 03:15:20 PM
The 6504 is a 6502 with some pins not connected. Both parts use the same silicon die. So you can use the 6502 core and ignore the upper address lines.

Yep, that's exactly what I'm doing!

Time for another progress update!

I'm in the process of testing and working out the kinks on the I/O board, and it's getting pretty far in its series of tests.

The boot ROM actually does a decent bit of testing on the I/O board before it even puts up the "Testing..." screen, with only a relatively small amount of testing happening during the "I/O board test" that you actually see occurring after the RAM test completes. Once it gets through that initial I/O board test, it actually goes back and does some additional CPU board tests (this is what's happening when the CPU icon is highlighted on the Testing... screen) and this exposed a few more minor problems with the CPU board. Namely that the "write wrong parity" and vertical sync interrupt circuits weren't working right, but those have now been fixed and I think it's safe to say that the CPU board is fully-functional.

It also completes the long RAM test just fine (the one that you see on the Testing... screen), so that's some additional confirmation that memory addressing and parity checking is working fine!

As for the I/O board itself, both VIAs seem to be working flawlessly, and the COP seems to be executing code and putting out its ready signal like it's supposed to. The boot ROM isn't making it to the in-depth COP test yet (that's the very last test that it does on the I/O board), but the preliminary test at least looks good.

Communications with the SCC seem to work fine too, although the SCC core I found from the NanoMac project is insanely limited, to the point that it doesn't even support the internal loopback mode that the Lisa uses during the self-test. For now, I've just patched the loopback test out of the boot ROM, and I'll come back and improve the SCC core later. Reading and writing all the SCC registers seems to work great though!

The only two tests left in the I/O board phase of testing are the floppy controller and extended COP tests, and it's stuck on the floppy controller right now. Up until yesterday, the floppy controller was actually completely dead, but I've got it in a much better state now. It's now happy enough that it puts its ROM revision in the shared RAM for the 68000 to read,  and the 68K reads the A8 just fine. And it seems to be able to address and control all the floppy drive control signals as well. I'm not 100% sure if the LS323/P6A PROM/LS174 state machine is working the way it's supposed to, but it at least seems to be running and doing something.

The current issue with the floppy controller is that it's failing its initial self-test, which the boot ROM notices when it reads the test results from the shared RAM, causing it to abort testing at that point. Luckily, I know why it's failing: for some reason, the floppy controller thinks a drive is connected, even though there isn't one, and so it tries to seek the heads back to track 0. But even after sending the seek command 80 times, the track 0 indicator bit still doesn't turn on (because there's no drive connected to turn it on), so the floppy controller thinks that either the drive or controller is defective and sets an error bit in the self-test result byte. So I just need to figure out why it thinks there's a drive connected when there's actually not.

After that, it's just the COP test, and then the I/O board should be done (aside from the SCC fix of course). The only thing left in the boot ROM's self-test after that is the scanning of the expansion slots for cards, but I don't have any cards "inserted", so it shouldn't detect anything and will hopefully just breeze through that test just fine.

At that point, we should be at the boot menu, where my next step will be getting a keyboard and mouse hooked up and interfacing with the COP so I can actually control things. I think I might try to hook up a USB keyboard and mouse, or PS/2 at the very least. And after that, I think connecting a ProFile would be a good idea. Not sure if this is even a thing, but if an ESP32 Verilog/VHDL core exists, I might even be able to integrate the functionality of ESProFile straight into the FPGA; no external drive or emulator needed!

Okay, I'm very nearly to the point where I can get to the boot menu consistently!

In fact, the FDC and extended COP tests work great in simulation and I'm able to get to the menu there every time just fine, but I'm still having a minor problem on the actual hardware, although it's proving to be pretty annoying.

When running on the actual FPGA, sometimes the FDC RAM gets corrupted and causes the Lisa to fail the self-test with an Error 57, and other times it passes just fine and makes it to the "no keyboard connected" and then Startup From... menu. It looks like the problem has to do with setup time issues with the addresses going to the floppy controller RAM, which of course only show up in actual hardware where you've got propagation delays to worry about. I've tried some strategies to fix the address issue (like delaying the RAM CS signal so that it wouldn't arrive until a 16MHz clock cycle later after things are stable), which helped, but then that has introduced weird edge cases where things completely break if the 68K tries to access the floppy controller RAM at the wrong time and interrupts the delayed CS pulse from the 6504. So I'm now trying out another solution, which will hopefully do the job a bit better. I'm super close though!

It must be an inspiring site to see it go through the pre-boot hardware check and then come up with the "no keyboard connected"!

I don't have much to offer to help along this journey, but every time I see that there's another update to this thread I get pretty excited. Go Alex go!

Still getting the "no keyboard connected" icon, but the good news is that the mouse is now working!

I hooked up a Macintosh mouse, and it works! FPGAs aren't 5V-tolerant, but the Mac mouse requires 5V since it's got a TTL logic chip inside, so I was pretty worried about what do do there, given that I'd rather not add any additional complexity in the form of level shifters until I get to the point of designing a custom PCB. But luckily, I discovered that certain mice would actually function fine on 3.3V, although it took about 5 or 6 mice before I found one that would.

I was initially trying to hook up a USB mouse, only to discover that my FPGA dev board doesn't actually have a USB host controller on it, just a USB line driver. Given that my FPGA (a ZYNQ 7020) has an ARM core inside it, I think they were expecting that to handle the USB protocol, but obviously we're not even using that here at all! And I don't feel like implementing the entire USB protocol from the ground up in Verilog, so USB support will probably just need to wait until I make a custom PCB with a host controller.

I've plugged up the keyboard now too, although it's not working yet. Well actually it's a USB to Lisa keyboard adapter because believe it or not, despite having three Lisas, I somehow don't have an actual Lisa keyboard! But regardless, something's keeping it from working. Not sure what though; I've probed the line with a scope and the COP is clearly sending out sync pulses that the keyboard responds to with data whenever I press a key. And the keyboard sends a reset packet too whenever it powers up, so it doesn't look like the issue is anything with the physical line itself.

I'm not sure how tight the timings have to be on the keyboard signals (maybe @patrick would know thanks to his reverse-engineering of the protocol), but my current suspicion is that the COP's clock is slightly off and it's not quite in step with the signals coming from the keyboard. The sync pulses generated by the COP are supposed to be 20us but are more like 13us in my case, so I think there might be something to this theory. The PLL inside the FPGA isn't producing exactly 3.9MHz like the COP expects, although it's only off by a little and I figured that it wouldn't be enough to matter. But to test my theory, I'm going to expose the COP's clock to an I/O pin and feed it from a function generator so I can fine-tune the clock and see if I can get that sync pulse tuned to exactly 20us. Then it should hopefully be perfectly in sync with the timings it expects from the keyboard, and maybe then it'll actually detect it properly!

Still having intermittent issues with the floppy controller, but I want to get the keyboard and mouse working before I go any further with that so I can go into service mode and write bytes straight into the FDC's shared RAM to try and diagnose the problem.

I occasionally would have delays or issues with my USB to keyboard adapter. Typically, right after a power on. Might've been my individual keyboard or equipment though so consider it anecdotal.

Luckily, it wasn't a problem with the keyboard adapter! It was a combination of accidentally having the wrong clock divider value set for the COP (/8 instead of /16) and forgetting to gate the output of the keyboard reset signal with the VIA's DDR so that it's not stuck low the entire time the computer is in reset. So now we have working keyboard and mouse, and I can type stuff into Service Mode!

I'm tempted to just go ahead and try to hook up an ESProFile to see if I can get anything to boot. I know the floppy controller's not quite healthy, but at least the Selector should start up assuming everything else is working. Luckily, the ESP32 uses 3.3V logic levels to begin with, so need to worry about any level shifting there!

ESProFile is hooked up and somewhat working! I can get into the Selector just fine and BLU on most attempts (although it fails its self-check presumably because of the SCC or floppy controller), so that's a start. And thanks to the serial number reading feature in BLU, I can finally confirm that the time-sensitive SN logic seems to be working okay!

Unfortunately though, it seems that the Lisa doesn't really like ESProFile for some reason. Or maybe it's a timing thing inside the FPGA, but results seem better with a real Widget, so I tend to think it's an ESProFile thing. Which means that I can't really get any other environments to show any signs of life because of disk read errors before they can load more than a few blocks off the ProFile. MacWorks Plus gets as far as clearing the screen to grey before crashing, but that's the farthest we get, aside from LOS.

It honestly shocked me that LOS made it the furthest of them all, but it did! Not to the "welcome to LOS" screen or anything, but it clearly loaded for a few seconds before disk erroring, and gave a 10726 (boot device read failed) error when it finally did fail. The others just hung or gave an error 75 from the boot ROM after reading a block or two, so LOS got quite far by comparison.

So then I decided to try and plug in a real Widget with LOS 2.0 installed to see if I'd have any better luck with a real drive. And I sure did! This time, it loaded for a good 10-15 seconds before giving a 10727, which means that the loader exhausted all the system's memory and had to give up. This makes a lot of sense; my Lisa currently only has 256K of RAM installed in it, which very likely isn't enough for LOS!

I'm just realizing as I type this that I plugged the Widget into the FPGA without level shifters. Whoops. At least it didn't fry anything.

The only big peripheral left to hook up is the floppy drive, but obviously I need a working floppy controller before I can do that! And given that I designed this thing around the 2/5 I/O board so that people can hook Twiggies to it, I guess I need to do the Lite adapter too, although that should be super easy. So I think I'm going to go back and finally get the FDC fixed up now. I could see this being really perplexing and taking a while, so don't be shocked if the next update isn't for several days or a week.

I'm noticing that (aside from the garbled CPU board error 41 picture) I haven't really provided much proof that anything I've been saying is actually true up until this point, so I've attached some photo evidence of all this too!

Okay, the floppy controller interfacing problem is fixed now! I ended up adding some delay logic that keeps the 6504's clock paused for a little while after a 68K access to shared RAM ends, which gives some other logic enough time to raise and then lower the FDC RAM CS signal again to re-latch the RAM address that the 6504 was accessing before the cycle got interrupted by the 68K. It was a pretty convoluted fix, but no more Error 57 or hanging!

I also implemented the Lite Adapter, which was super easy. It just compares a constantly-incrementing counter to the value in a shift register (which represents the PWM duty cycle) and sets or clears the PWM output signal depending on whether the counter is greater than or less than the shift register value.

Now that the FDC seems to be working and fully-implemented, I've hooked up a Floppy Emu, and unfortunately we can't quite boot from floppy yet. But we're really close. It can clearly detect whether or not there's a disk inserted, and I've confirmed that seeking and ejecting the disk work perfectly by sending those commands to the FDC manually in Service Mode. The one thing that's not working is reading and (presumably) writing, which is obviously a pretty big problem! Whenever you try to read a sector (either manually in Service Mode or automatically by booting from the disk), the FDC just sits there trying to read the sector forever. This is making me think that something's wrong with the PROM state machine, which is supported by the fact that the only two things I've ever seen it put out onto the 6504's data bus are 0 and 1, which obviously doesn't seem right when reading sectors off a disk. So that's what I'm about to start troubleshooting next; hopefully it's not too hard of a fix!

After reading some more about the theory of the Apple ][ floppy state machine (which is basically identical to the Lisa's) and tracing through the states, I discovered that I had wired one of the pins on the ROM to the QH pin of the shift register instead of the QA pin, causing it to clear the shift register every time it shifted in a bit instead of only after a full byte was shifted in. And after fixing that, I can boot from floppy! Here's the status of booting various things from floppy, I'm assuming anything that's failing is because of my tiny 256K of RAM:

BLU - Works
Selector - Works
NewWidEx - Works
LisaMandelbrot - Works
MacWorks XL - White screen, floppy activity for a while and then hangs
MacWorks Plus - Gets about halfway through the Loading... screen and then hangs
MacWorks Plus II - Gives error about PFG since we don't have a PFG installed, if we choose to continue it loads about half the sectors from the floppy before hanging
UniPlus - Immediate error 75, I think my UniPlus floppy might just be corrupted
Xenix - Gets to the screen where it prints the Lisa system type, expansion slot contents, and free RAM, then kernel panics
GEM - Can boot to the command line, starting the GUI causes it to hang midway through loading
LisaTest - Error 49 (Line 1010 or 1111 trap)
LOS/Workshop - Error 10727 (Memory exhausted)

I don't have enough room in the FPGA to go to 512K of RAM, and I can't move the RAM to my board's external SPI flash because the write speed is too slow. My board has a DDR3 RAM chip on it too, but I really don't feel like interfacing with that, and I'm worried the latency would be too high anyway. So I think it might be time to design a custom board with an external parallel (or maybe SPI) SRAM before I continue. Unless anyone's got any better ideas (which I would love to hear), I think this will be my next step, and so it'll probably be a little while before another progress update. I guess I can go ahead and try to fix the intermittent ProFile read problems that I was having, but that's about all that I can do with the current version of the hardware.

Fantastic work!

LisaMandelbrot? I will have to look into that.

Amazing progress!

LisaMandelbrot is a set of Mandelbrot set plotters that I wrote a while ago. You can find it here: https://codeberg.org/stepleton/LisaMandelbrot
That page looks sparse because there are three varieties: "Port" which runs on the Office System, "Pro" which runs in the Workshop (no extra features, it's just that the workshop seems like the place for "pros"), and "Solo" which is a standalone program (i.e. boots and runs without an OS). Solo is quite small. Anyway, click through to any of the three to see more detailed information.

My standalone programs (including the Selector) don't really exercise all that much of the Lisa's capabilities; for a start, they all leave the MMU in the boot-up "flat" configuration. So it's not a big surprise that they run. For this reason I wouldn't think there's much point in running my stunt standalone Forth port (https://codeberg.org/stepleton/lisa-fig68k) for Lisa, as it is just as gentle on the machine (the Forth part can't even use RAM above 64k!).

Alex's SRAM idea touches on a project I was thinking of attempting but was in my project pile: the Smallest 2Meg RAM Card On Earth. I had a vision of an SRAM-based RAM card that would be comically small inside of the card cage, and I'd even had my eye on this single, somewhat pricy RAM chip (https://www.mouser.co.uk/ProductDetail/727-CY62167ELL-45ZXI), with its 16-bit data bus and (IIUC) +5V tolerance. But I hadn't started to sweat the details yet, and realistically it is a project that would have sat on a back burner for months at least. All of which is to say: Alex, if you wanted to stretch your SRAM plans slightly to make the Smallest 2Meg RAM Card On Earth, it would be pretty cool, and maybe that IC is worth knowing about  :)

Ha, it's interesting you mention the 2MB RAM card thing; I was just thinking about doing something like that! All the RAM card logic I've written would easily fit into a small CPLD, so throwing the CPLD, some level shifters, and the SRAM onto a tiny little board would work nicely. And funnily enough, that SRAM chip is the exact one that I've been eyeing for the FPGA!

The COP core I'm using seems to also be small enough to fit into a CPLD, so a CPLD-based COP replacement could be another interesting idea...

(all out of curiosity)

Are the level shifters for the CPLD? That SRAM itself seems to accept and send TTL-compatible signals, though the outputs won't go up to a full +5V.

What kind of things does the CPLD do? I only scanned the Lisa Hardware Manual about this once, but I took away the impression that some of the work of the support logic was dealing with placing the RAM board in the appropriate part of the address space. (As the SRAM is a full 2 MB, the correct positioning is straightforward: it takes up all of it.) Furthermore, there's no need for DRAM refresh, so maybe that simplifies things too.

I suppose I'd hoped therefore that you might be able to reduce necessary logic down to a few surface-mount TTL ICs. You might put them on both sides of the board to achieve more compactness, though it would be better to avoid that so that you can use a hotplate for assembly.

But I assume there is plenty of remaining devil in various timing details for RAM reads/writes, etc.

Meanwhile, I was always wondering if you could replace the COP with a suitably busy Arduino (with enough pins)...

Quote from: stepleton on October 15, 2025, 03:48:47 AM
Amazing progress!

Indeed!

Quote
vision of an SRAM-based RAM card that would be comically small inside of the card cage, and I'd even had my eye on this single, somewhat pricy RAM chip (Infineon CY62167ELL-45ZXI), with its 16-bit data bus
...
But I hadn't started to sweat the details yet

I suspect parity could become a sweaty consideration, so I suggest sorting out how you will handle the parity issue before finalizing your part requirements.

The issue is that the parity test circuitry allows storing bad parity in multiple byte addresses for discovery at an indeterminate time.

IIRC, the POST sets bad parity at only one address, so rather than storing parity, it is possible to record that address and report the parity error when it is read again, but if some software (LisaTest maybe?) does a more complicated parity circuit test, it may discover your secret of circumventing stored parity bits.

Modifying the CPU ROM to remove the parity circuit check may be sufficient for most operation, but some purists prefer LisaTest success, and I don't know if anything else checks the parity circuits, so ymmv etc.

Quote from: AlexTheCat123 on October 14, 2025, 04:42:15 PM
MacWorks Plus II - Gives error about PFG since we don't have a PFG installed

Since you don't have a fully functional SCC module, and possibly don't want to develop one (in particular with the SDLC (or whatever it is) complication that makes LocalTalk possible), you might consider using a real SCC, which then makes plugging in a real PFG an option. And/or we can figure out a strategy for implementing any desirable features of the PFG without the real hardware if the SCC can be adequately emulated.

But this is just one aspect of what the final result might be... now that you've very well established a proof of concept, it might be time to brainstorm the final objectives...

For example, is it, or some version of it, going to:

• completely replace real Lisa hardware including card cage, video, chassis, specific expansion cards, while not supporting arbitrary real expansion cards?
• replace the CPU and memory boards in a real Lisa card cage/chassis that uses real motherboard, video, I/O and expansion cards?
• replace CPU, memory, and I/O boards in motherboard form-factor so real expansion cards can be inserted in a real chassis?

Lots of options to consider that have their benefits and drawbacks... some of the challenges of being the project manager!

Yeah, I know it would be some pretty simple logic, but the purpose of the CPLD would be consolidating the small amount of TTL logic that would be required as well as figuring out parity. It could be done in TTL too, but I figured that a CPLD would probably be more compact and inexpensive. I was thinking about doing @sigma7's strategy of remembering the one address that the boot ROM does the "write wrong parity" test to, but it's true that we don't really know what else may use this feature. It would be easy enough to find out though; just boot each Lisa OS with the FPGA-based Lisa set to trigger on accesses to the appropriate address in the system control latch.

Unlike the SRAM card (if and when I get around to making that), I want to actually handle parity the proper way in the FPGA-based Lisa. So I was thinking about using the external SRAM for the main memory and then still keeping the parity inside the FPGA's block RAM.

Quote from: sigma7 on October 15, 2025, 07:07:08 PM
Since you don't have a fully functional SCC module, and possibly don't want to develop one (in particular with the SDLC (or whatever it is) complication that makes LocalTalk possible), you might consider using a real SCC, which then makes plugging in a real PFG an option. And/or we can figure out a strategy for implementing any desirable features of the PFG without the real hardware if the SCC can be adequately emulated.

Yeah, that's a good idea that I hadn't really thought about before! I had previously planned on (and really, REALLY dreaded) implementing the SCC myself later on, but this might be a better (even if temporary) solution.

I've already implemented the PFG in an ESP32, and I've been imagining that implementing the same state machine inside an FPGA would be even easier, so my current plan is to (at least for my own personal use) make a Verilog version of the PFG. And same for the XLerator and LSAC too. Maybe we could work out a deal where @sigma7 could sell those as IP cores that people could add to their own FPGA Lisas without having access to the source code?

Quote from: sigma7 on October 15, 2025, 07:07:08 PM
But this is just one aspect of what the final result might be... now that you've very well established a proof of concept, it might be time to brainstorm the final objectives...

I'm currently imagining two different versions of the final device:
1. A modernized standalone version of the Lisa. This will be a board that sits on your desk with HDMI video output, USB (or possibly PS/2) keyboard and mouse input, built-in ESProFile hard drive emulation, USB to serial feeding directly into the Lisa's serial ports, and perhaps built-in floppy emulation if I end up writing a floppy emulator. It would also let you plug in original keyboards, mice, hard/floppy drives, and would expose the original Lisa video signal for those who want it.
2. A version in the form factor of the Lisa motherboard. This would be a drop-in replacement that people could stick straight into their Lisas to replace a bad card cage, and it would include expansion slots too, on top of all the original ports that you'd expect.

Both versions would probably have switches that would let you flip between H and 3A as well as 40 and A8 ROMs on the fly.

Option #1 is the first priority that I'm just starting to mess around with now, with #2 coming later.

It's been a while, time for an update!

I'm getting pretty close to finishing the schematic for the PCB, and then I'll be onto the layout and routing phase. The whole schematic is done other than the connections of everything to the FPGA itself. Hopefully that shouldn't be too hard, I just need to look at the datasheet and make sure I connect certain Lisa signals to certain special-purpose I/O pins.

By the way, I've settled on the Xilinx Artix 7-100T as the FPGA of choice for the final board. It's pretty darn cheap at about $20, has plenty of LUTs, and between 200 and 400 I/O depending on which package you get it in. I'm currently using a little over 200 I/O, and this board doesn't even have expansion slots on it (which will add even more to that), so the 300-I/O version is going to probably be the chip of choice.

The key features of the board are:
- Power over either USB-C or barrel jack; 12V, -12V, and -5V (along with the 1V, 1.8V, and 3.3V FPGA voltages) are all generated onboard.
- USB port goes into an onboard hub chip, which feeds four devices: JTAG for FPGA programming and debugging, an onboard ESProFile, an onboard (yet-to-be-coded and I'm not even sure if I'll ever get it to work) floppy emulator, and a USB to serial chip that can directly feed the Lisa's Serial B port.
- As just mentioned, an onboard ESProFile and ESP32-based floppy emulator. There's a Floppy Emu-style OLED display and set of buttons for controlling floppy emulation, although once again none of that is implemented yet. And of course there are switches to choose whether you want to use the hard/floppy emulators or actual drives plugged into ports on the board.
- Switches to toggle between H and 3A CPU ROMs (and the corresponding VSROMs) and A8 and 40 I/O ROMs on the fly.
- The first version won't, but future versions will have Twiggy headers for the lucky few of you who happen to own a set of Twiggy drives!
- Onboard speaker (with the Lisa's 3-bit volume control) for Lisa audio, and external speaker header if you want to connect a larger one.
- Onboard contrast latch DAC in case you want to use the analog contrast signal for anything.
- HDMI video output. The VSYNC, HSYNC, and VID signals are also exposed on a header for easy connection of an RGBtoHDMI if you prefer that.
- USB keyboard and mouse input. As with the ProFile and floppy interfaces, these are switchable, so you can still plug in original Lisa keyboards and mice and use those too.
- Per James' suggestion, the Lisa's serial ports are implemented using a real 8530 SCC that you'll have to pop into a socket on the board once you receive it. But all the SCC's serial I/O pins are also bidirectionally level-shifted and run back to the FPGA so that a future version of the firmware can implement the SCC internally without requiring any changes to the PCB. The FPGA would just enable the level shifters, and that would take control from the external SCC.
- And as I mentioned earlier, Serial B is switchable between the actual DB25 port and a direct USB to serial interface with your computer, making it really easy to do things like transferring over all the LOS source code without needing a USB to 9-pin serial adapter and then a 9-pin to 25-pin serial cable.

There's no way that this thing will even come close to working on the first try, but hopefully I'll be able to figure out all the problems reasonably easily after getting a prototype run of boards in the mail.

As with some of my other recent designs, I've made sure that every part I'm sourcing is from JLCPCB/LCSC's parts library, so they'll be able to assemble the whole board for you when you order one. Which is pretty crucial given how much surface-mount stuff there is on here! The parts cost is currently looking to be a little over $100 per board, but I'm hoping to get it a little lower than that on the next board revision when some of the debugging hardware is removed.

It's still probably going to be a couple weeks before the layout and routing are done, but at least finishing up the schematic means that I'm about halfway there now!

That is astonishing. Congratulations, Alex! Looking forward to seeing it in the real world.

I am stunned fantastic work thank you!!

Getting pretty close now!

The whole board is laid out and most stuff is routed too, with the exception of the traces to/from the FPGA itself. All the individual subsystems and power are completely hooked up though, and you might be able to see that a few things (the config flash, JTAG, differential pairs for USB and HDMI, and half the SRAM) are routed to the FPGA at this point. And all the pins on the BGA are fanned out (which was an absolute nightmare), so it's just a matter of connecting everything to them now. Although I'm anticipating that being a pretty big challenge given how dense everything is and the fact that I'm using literally every single I/O pin on the FPGA.

In case anyone's wondering, I decided on a 6-layer board with planes for 3.3V and ground, and the other 4 being signal layers. I didn't bother making power planes for 5V, 1V, 1.8V, or any of the other voltages because they're used so sparsely that it was just more efficient to route them on one of the internal signal layers.

Out of curiosity, I threw the design into JLCPCB to see how much it would cost, and fabricating 5 bare boards comes out to about $60. When you add their assembly service to that and ask them to assemble 2 of the 5 boards, the total price comes up to $438. About $200 of that is parts ($100 per board) and the rest is labor. So people probably won't want to order a set of boards unless they're buying several and selling the ones they don't use themselves. I checked the price for ordering and assembling 100 of them, and it comes out to about $8000, so you really do save a lot when you buy in bulk. That's only $80 per fully-assembled board!

I've attached a rendering of the PCB so you can get an idea of what it'll look like. The layout is completely finalized; the only thing that should change from here is the routing of traces going to/from the FPGA.

Impressive and certainly a project for the advanced home soldering enthusiast.
I can see the floppy emulator you've mentioned before. But I also notice the wall of capacitors to keep out the riff-raff ;-)
It's interesting to see all the DC-DC conversion on the board; I'm guessing that using off-the-shelf switching regulators is pricier?

I've never used an assembly service (but would have to in this case). Would there be some savings possible if you just used them for the surface-mount parts and left through-hole parts for the buyer to sort out?

Really nice. I wonder how easy it would be to replace the innards of a Lisa with this, so that from the outside all the original ports would appear in the normal places. Seems like it would require a bit of snaking some extension cables around inside the case, and a tiny power strip where the power supply usually is to accommodate both the board and whatever is powering the CRT.

Quote from: stepleton on November 05, 2025, 08:13:16 PM
I can see the floppy emulator you've mentioned before. But I also notice the wall of capacitors to keep out the riff-raff ;-)

No guarantees that I'll get the floppy emulation working, but I'll sure try my best! And yeah, there's an insane number of caps on this board. There are another 30 or 40 that you can't see on the bottom underneath the FPGA too.

Quote from: stepleton on November 05, 2025, 08:13:16 PM
It's interesting to see all the DC-DC conversion on the board; I'm guessing that using off-the-shelf switching regulators is pricier?

Yeah, that's the way it seemed. If you're just doing a single voltage rail, then a switching regulator module is cheaper than all the discrete components to build a DC-DC converter from scratch, but when you're doing 5 or 6 of them, then the discrete version is cheaper thanks to how many parts are reused between them and the fact that you're already ordering 20 to 100-ish of each to begin with thanks to minimum order quantities.

Quote from: stepleton on November 05, 2025, 08:13:16 PM
I've never used an assembly service (but would have to in this case). Would there be some savings possible if you just used them for the surface-mount parts and left through-hole parts for the buyer to sort out?

Ha, somebody else asked me that same thing a few days ago! Yeah, it would certainly save a few dollars, but only if we used the cheap Chinese through-hole parts. And somebody told me that you get double-tariffed if you order boards and parts from China separately, so the through-hole parts would need to come from DigiKey or Mouser instead. And by the time you pay the higher DigiKey/Mouser component prices, it comes out to about the same price as getting them to assemble it anyway.

Quote from: andrew on November 06, 2025, 01:15:50 PM
Really nice. I wonder how easy it would be to replace the innards of a Lisa with this, so that from the outside all the original ports would appear in the normal places. Seems like it would require a bit of snaking some extension cables around inside the case, and a tiny power strip where the power supply usually is to accommodate both the board and whatever is powering the CRT.

Not sure when I'll get around to it, but my eventual plan is to design a second version of the board that's in the form factor of the Lisa motherboard, so it would be a drop-in replacement for the original card cage without any adapter cables or extensions or anything. And I could omit some of the circuity on the board (HDMI port, voltage regulation, keyboard port, and so on) since those facilities would already be provided by the Lisa chassis.

Quote from: AlexTheCat123 on November 06, 2025, 02:28:42 PM
Not sure when I'll get around to it, but my eventual plan is to design a second version of the board that's in the form factor of the Lisa motherboard, so it would be a drop-in replacement for the original card cage without any adapter cables or extensions or anything. And I could omit some of the circuity on the board (HDMI port, voltage regulation, keyboard port, and so on) since those facilities would already be provided by the Lisa chassis.

You ought to try putting a micro HDMI port in place of the video out port!

And in general, I don't think it hurts to have redundancies here and there. For instance, the USB keyboard and mouse inputs are probably worth keeping in the event you need to troubleshoot a keyboard or mouse issue with the original hardware.

Yeah, I haven't fully decided what to keep and what to take away on the Lisa motherboard version of the board. That's all pretty far out in the future. But I like the idea of micro HDMI and maybe keeping USB too!

If it were me, I'd keep the motherboard ports exactly the same as a /5 and run a second board over to the expansion bays with all the extra goodies on it.

Does MacWorks, XENIX, UniPlus run on this?

Quote from: blusnowkitty on November 07, 2025, 09:00:51 AM
Does MacWorks, XENIX, UniPlus run on this?

Well, nothing (other than BLU, the Selector, NeoWidEx, LisaMandelbrot Solo, and GEM sort of) actually runs on it right now! Everything else tries to boot but hangs or errors out somewhere during the process. The common thread between all the errors is memory exhaustion, which makes a lot of sense given that I've only had room for 256K of system memory up until this point. To get more RAM, I had to take a break from the HDL side of things and design this board (which happens to have a 2MB SRAM on it), and then I can get back to trying to get stuff to boot once I've got enough memory. I'm hoping that everything will just work once it's got more than 256K of RAM to play with, but there could absolutely be more bugs to figure out too!

Finally done with the board! Here's the final rendering of it, which looks basically identical to the previous one other than a bunch of additional traces going to the FPGA. And I've also attached a screenshot of the board layout with the inner layers visible so you can see what's going on under the surface; that's where most of the traces converge toward the FPGA.

I'm about to place the order, and the price has gone up a bit thanks to me not selecting a few important options during the first price estimate. But selecting those options now (double-sided assembly for the bypass caps under the FPGA and vias smaller than 0.4mm) have brought the final price up to $525 for two fully-assembled boards and three unpopulated spares. And then there might be tariffs on top of that, but hopefully not. I haven't actually placed a PCB order since the tariffs went into effect, so I'm not completely sure how that works.

Given the complexity of the boards, it's going to take them 8 or 9 days to fabricate and assemble them versus the standard 2-4 days for fabrication and assembly, but hopefully they'll get to me within the next couple weeks!

Edit: Oh my god, the tariff is $289. I could barely afford this before, but I sure can't now. I hate to say it, but this project might have to wait a while until I can save up enough to actually buy these things.

Damn, that's insanity. It's too bad.  :'(

Quote from: AlexTheCat123 on November 10, 2025, 12:56:19 AM
Edit: Oh my god, the tariff is $289. I could barely afford this before, but I sure can't now. I hate to say it, but this project might have to wait a while until I can save up enough to actually buy these things.

Community effort here. How much of a donation would you need to continue your work?

Good news! Thanks to an incredibly generous donation by @jamesdenton, I was able to place the order, and I should have the boards on hand within the next 2 weeks. Thank you so much James, I really appreciate it!

Quote from: bmwcyclist on November 10, 2025, 02:07:05 PM
Community effort here. How much of a donation would you need to continue your work?

Thanks for offering to pitch in, but I think I should be good for now!

I would really love to be able to buy one of these, but I would also need it ready to run.

Quote from: classiccomputing on November 14, 2025, 10:44:48 AM
I would really love to be able to buy one of these, but I would also need it ready to run.

I'm definitely not to that point yet, but that's the ultimate goal. This is just the initial round of prototypes, so I'm absolutely expecting problems!

They just finished assembling the boards, and they'll probably be shipped within the next day or two. Hopefully I get them before Thanksgiving. In the meantime, here's a cool X-ray shot they sent me of the area under the FPGA on one of the fully-assembled boards!

that is crazy cool!

Good news, the boards are here and they look great! I've attached some pics in case anyone wants to see.

Now into my current progress with testing them, which is mostly good news so far.

I designed each of the switching regulators such that they could be disconnected from the rest of the board, just in case my initial design was bad and was causing them to put out a bad voltage. So I tested them in the disconnected state first, and everything was 0V! Well, it turns out that I labeled the jumper that selects between USB-C power and barrel jack power backwards, so I just swapped the jumper around and then things started coming to life.

All the voltages were spot-on, most of them to the thousandth of a volt. The only ones that weren't were the 1V and 1.8V rail, which were 0.999V and 1.801V, respectively. Definitely close enough. I was honestly shocked at how spot-on the voltages were, and they stayed this consistent under load. The ripple on all the rails is 40mV or less, with most being below 20mV, so pretty darn good and well within spec of all the components.

Then I hooked the PSUs to the rest of the board, and the USB hub activity LEDs came to life! Plugging it into my laptop, all four USB devices (the FT2232 for JTAG, the CP2102N for serial comms with the Lisa, and both ESP32s) were visible, although the ESPs were repeatedly connecting and disconnecting every second for some reason.

Luckily, after programming both ESP32s, they stopped this weird behavior and are working perfectly. I can't really fully test the CP2102N (or the ESP32s, for that matter) until the Lisa is up and running, but I was able to talk to it and program in some custom name and vendor strings, so I'd say it's working pretty well.

The FT2232 is where I encountered my first major problem. Which sucks because it's how you program the FPGA! Xilinx has a tool that flashes its configuration EEPROM (a 93C46) with a special signature that Vivado looks for to recognize it as a USB to JTAG interface, but the tool kept erroring out whenever I tried to flash it. After some experimentation, I discovered that it was successfully programming the EEPROM, but was running out of space. The 93C46 is a 64-byte EEPROM, but it turns out that you need at least 128 bytes (93C56 or above) to store all of Xilinx's configuration data. So there's nothing I can do to make this work with the existing chip.

Luckily though, the 93C46 is the only chip on the entire board (aside from the SCC) that's through-hole, so I went ahead and ordered some 93C56's and I'll just solder one in once I get them in the mail next week.

But fortunately, I put a JTAG header on the board just in case something like this were to happen, so I was able to plug in a Digilent USB to JTAG adapter to try and program it that way. Sadly, it didn't work at first, but then I noticed that it was because I'd plugged in TDI and TDO backwards. After swapping those, Vivado was actually able to see and program the FPGA!

Then I tested out the configuration flash connected to the FPGA (in case you're not familiar with FPGA stuff, this is the nonvolatile RAM where you store your bitstream if you want the FPGA to automatically load it at boot), and that worked too. I put a bitstream in there, and it clearly loads it and illuminates the "DONE" light once it's finished loading!

I flashed the Lisa bitstream to it to try and see how much life I could get out of the Lisa peripherals, and there certainly is some, but clearly there are still some problems to solve. Hitting the Lisa's power switch causes the power LED (connected to the ON signal) to light up, and I get a good HSYNC out of the video connector, but VSYNC and VID are dead. I'm guessing that it's just a problem in Verilog or my design constraints file though as opposed to an actual board problem. We'll see!

Overall, a really successful test; a good bit better than I was expecting!

 Very good news!

Here are the latest LisaFPGA updates, in video form!

https://www.youtube.com/watch?v=zE4fxzj6V4A (https://www.youtube.com/watch?v=zE4fxzj6V4A)

Alex, that is insanely cool! Nice work  8)

Quote from: AlexTheCat123 on December 05, 2025, 11:42:24 PMHere are the latest LisaFPGA updates, in video form!

https://www.youtube.com/watch?v=zE4fxzj6V4A (https://www.youtube.com/watch?v=zE4fxzj6V4A)

Fantastic work, and in such a short time, all things considered! Looking forward to your next update!

@Alex You mention switching over to the dedicated RAM chip but needing a place for the parity bits. I know this is wasteful, but the RAM chip is 2 MiB, so what about an option for emulating a Lisa with the common configuration of 1 MiB of RAM and squeezing the 128 KiB of parity bits somewhere in the space that remains? It would ensure a working system if software ever turns up that uses parity more than the boot ROM does.

Or even 1.5 MiB / 192 KiB to be more space-efficient, though there you will need more than one bit per byte in your parity pool, which could slow things down. This would be like a Lisa with one each of a 1 MiB and a 512 KiB RAM card.

In general, would it be a good idea to allow the amount of RAM to be configurable? I seem to dimly remember hearing here about some OS (maybe one of the UNIXes) or other piece of bootable software that required exactly 1 MiB of RAM.

Quote from: stepleton on December 07, 2025, 12:32:19 AM@Alex You mention switching over to the dedicated RAM chip but needing a place for the parity bits. I know this is wasteful, but the RAM chip is 2 MiB, so what about an option for emulating a Lisa with the common configuration of 1 MiB of RAM and squeezing the 128 KiB of parity bits somewhere in the space that remains? It would ensure a working system if software ever turns up that uses parity more than the boot ROM does.

Or even 1.5 MiB / 192 KiB to be more space-efficient, though there you will need more than one bit per byte in your parity pool, which could slow things down. This would be like a Lisa with one each of a 1 MiB and a 512 KiB RAM card.

Hmm, interesting idea! I had actually considered doing this a while back, but I really wanted the full 2MB to be available, so I decided not too. But maybe it wouldn't be such a bad idea after all. I'd still like to have  2MB of RAM though, so maybe I should just upgrade to a larger RAM chip on the next board revision. Like 4MB maybe. That would give plenty of room for parity! And spoiler: the design meets timing now by a pretty hefty margin, so maybe I would be able to add some parity stuff back into the internal block RAM without destroying timing closure again...

Quote from: stepleton on December 07, 2025, 07:52:03 AMIn general, would it be a good idea to allow the amount of RAM to be configurable? I seem to dimly remember hearing here about some OS (maybe one of the UNIXes) or other piece of bootable software that required exactly 1 MiB of RAM.

Don't worry, that's already part of the plan! I've got 2 jumpers on the board that you'll be able to use to select between 512K, 1M, 1.5M, and 2M of RAM. They don't do anything yet (it's currently hard-coded to 512K), but they will once I get the RAM working reliably.

Speaking of RAM, I've got another update to give! I was surprisingly able to fix all 2000-something of the timing violations yesterday, and now we're down to zero; everything meets timing! Which meant that I was able to proceed to the next step of migrating to the external RAM chip. It went better than I expected given that the Lisa actually tried to boot on the very first attempt, but there are clearly still some problems. It fails the RAM test with error 70 (so actual RAM problems, not just it thinking that parity is wrong) and the entire screen has these weird ghosting artifacts all over it. Anything that's shown on the display will have repeated ghosts of itself off to its right, and there's a bit of noise on certain parts of the screen too. I've also noticed that it now takes the Lisa quite a long time to hunt for a valid chunk of memory to stick the video page in when it first turns on, so I think we've got some sort of RAM timing issue where either certain writes aren't fully sticking or certain reads are being done before the data is ready. Figuring all that out is my job for today!

Quotemaybe I would be able to add some parity stuff back into the internal block RAM

If it is true that nothing important uses/tests the parity circuitry aside from the ROM's self-test, then perhaps modifying the ROM to ignore that part of the self-test would be the best ROI option.

Perhaps even that's not strictly necessary... can one just "Continue" after getting error 71?

Quote from: sigma7 on December 07, 2025, 06:18:25 PMIf it is true that nothing important uses/tests the parity circuitry aside from the ROM's self-test, then perhaps modifying the ROM to ignore that part of the self-test would be the best ROI option.

Perhaps even that's not strictly necessary... can one just "Continue" after getting error 71?

I've already patched the parity test out of the ROM for the sake of testing, so it's certainly an option to just keep that patch in there!

You can indeed Continue after the parity error, so leaving it alone is another option if people are okay with that. Although I'd prefer something more elegant if possible. The solutions, from most to least elegant, are:

1. Get a bigger SRAM and implement parity in there or do parity internally using block RAM.
2. Put some logic on the CPU board that detects the ROM's "write wrong parity" test and asserts HPIR at the appropriate time to simulate the detection of the parity error.
3. Patch the test out of the ROM entirely.
4. Don't do anything, and have the user hit Continue whenever the parity error pops up.

I'll probably try the block RAM strategy, but that'll be a job for later on once much more of the system is fully-functional!

On a real Lisa memory board, the "HDER" (Hard Memory Error) signal (pin 49 on each memory slot) "tells" the Lisa that there was a parity error (during read). If you disconnect that signal, the Lisa will never see such errors and should run happy. Perhaps the same can be done in the FPGA? Then you don't need any parity circuitry.

Source: http://www.bitsavers.org/pdf/apple/lisa/hardware/Lisa_Hardware_Manual_Sep82.pdf

Quote from: TorZidan on December 07, 2025, 11:38:59 PMOn a real Lisa memory board, the "HDER" (Hard Memory Error) signal (pin 49 on each memory slot) "tells" the Lisa that there was a parity error (during read). If you disconnect that signal, the Lisa will never see such errors and should run happy. Perhaps the same can be done in the FPGA? Then you don't need any parity circuitry.

That's absolutely right most of the time, but there's one extra detail to HDER that makes this fail under certain circumstances.

The CPU board has a "write wrong parity" circuit on it the forces the memory board to write incorrect parity info to any address that the CPU writes to while this circuit is enabled. As a test of the error detection circuitry, the boot ROM (and maybe LisaTest too, not sure) uses this feature to write invalid parity to an address, and then reads it back to make sure that the memory board detects the bad parity, that it pulls HDER low, and that the CPU receives the corresponding HPIR (high-priority interrupt). So if we tie HDER high all the time (which is what I'm doing temporarily right now), this test will fail. Parity will be fine all the time otherwise, but not during this test! That's the whole problem here.

Back when I was considering the "tiniest 2 MiB RAM card" project (now shelved since multiple people seem to have this idea cooking away on a side burner), I wondered whether you might be able to accomplish something that passes write-wrong-parity checks using something like a lousy LRU cache. If write-wrong-parity is enabled, push the lower N bits of the address into the cache. Then when retrieving memory data, check to see if any address matches any of the cached address pieces and, if so, invert the parity bit. A bit more complexity and for what? Who knows. Maybe the idea can inspire something else.

I also meant to learn more about the "write wrong parity" feature to see if I could "unlock" 128 KB of extra (albeit inconvenient) RAM in my Lisa, but I haven't done that either.

Quote from: stepleton on December 08, 2025, 07:20:03 PMBack when I was considering the "tiniest 2 MiB RAM card" project (now shelved since multiple people seem to have this idea cooking away on a side burner), I wondered whether you might be able to accomplish something that passes write-wrong-parity checks using something like a lousy LRU cache. If write-wrong-parity is enabled, push the lower N bits of the address into the cache. Then when retrieving memory data, check to see if any address matches any of the cached address pieces and, if so, invert the parity bit. A bit more complexity and for what? Who knows. Maybe the idea can inspire something else.

That was basically my exact idea! But time will tell if we actually need that level of complexity...

In the meantime, check this out; it actually boots MacWorks Plus now (albeit with barely-visible video)!

https://youtu.be/OBmNUpbnqVc (https://youtu.be/OBmNUpbnqVc)

And it boots LOS as well, but it's nearly impossible to see the desktop given the horrendous-looking video! Ignore what I say about it only booting LOS 2 and not LOS 3; it actually boots 3 just fine and only failed because I tried to boot a corrupted image!

https://youtu.be/HIbJPjjW5ls (https://youtu.be/HIbJPjjW5ls)

According to some logic analyzer traces, it seems like the video issues have something to do with the RAM not liking to be read from immediately after a write has finished. The CPU writes data into RAM during its half of the bus cycle, but then when the video circuitry goes to stick some stuff onto the screen during its half of the cycle, it reads completely wrong data and garbage ends up on the screen in that area. So I'm thinking that the RAM needs a little more turnaround/delay time after the end of a write before it's ready to do a read.

This would totally explain why the Lisa passes the RAM test just fine but still has the corrupted video; a CPU write is always followed by a video read, so the video read will get corrupted, but the next CPU read or write doesn't happen until a whole cycle after the first one, so by then the RAM is ready and reads and writes just fine again. If the video circuitry were somehow able to write to RAM too, then this would be a different story and we'd be getting RAM errors left and right.

Now I just need to figure out how to fix it. Right now I assert the RAM's CE only while RAS and CAS are both asserted, but keep WE asserted for a good bit longer (for as long as MREAD is low). I'm wondering if maybe it doesn't start "recovering" from the write until after WE gets deasserted, regardless of whether or not the chip is selected, so I'm going to try and shorten the WE pulse to be the same width as UDS and LDS instead. Hopefully that clears things up a bit! If not, I guess I can try shortening the CE pulse to not even be as long as the overlap of RAS and CAS, but I have to be careful there because it's already so short that I think we're pretty close to the minimum pulse width that the RAM will detect.

Ha, wild about how the major issue is video when so much else works. It's interesting how it's so correlated with what the Lisa is doing. Is there a way to investigate the hypothesis more directly with software? In particular, what if you put the CPU into a tight loop where it wasn't writing to RAM at all, just constantly executing

.lp BRA.S .lp

which you might be able to run in Service Mode "in the blind" by putting 60FE in RAM somewhere and jumping to it. Would the display look OK then?

Meanwhile, I wonder if those bidirectional level shifters you've chosen are the same TXS0108Es I've regretted on Cameo/Aphid...

Quote from: stepleton on December 10, 2025, 04:34:05 AMHa, wild about how the major issue is video when so much else works. It's interesting how it's so correlated with what the Lisa is doing. Is there a way to investigate the hypothesis more directly with software? In particular, what if you put the CPU into a tight loop where it wasn't writing to RAM at all, just constantly executing

.lp BRA.S .lp

which you might be able to run in Service Mode "in the blind" by putting 60FE in RAM somewhere and jumping to it. Would the display look OK then?

Yeah, it's insane that the problem is so horrendous while everything else is fine. You'd think that there would be no way that the RAM would be functional with that kind of corruption.

Trying to write some code to get some more info on what was going on was going to be my next step, but I actually was able to fix it without needing to do that! It turned out to be a problem with the /LDS and /UDS data strobes for the lower and upper bytes of RAM. The stock RAM board uses them for writes (obviously) to determine which byte(s) to write to, but completely disregards them for reads. During a read op, both bytes are always returned no matter their state. During the CPU half of a bus cycle, the CPU always puts the strobes in the "proper" states for reads even though the memory disregards them, but when the video circuity goes to read from memory, it doesn't set the strobes at all. And my RAM chip, unlike the original board, requires the strobes for BOTH reads AND writes; without them, garbage data will be returned. So this explains why CPU cycles were fine, but video ones weren't; the CPU always set the strobes right, but the video didn't. The only reason that video sometimes worked was because a CPU strobe would occasionally overlap into a video cycle just enough to trigger the RAM, but this happened less when the CPU was accessing RAM vs ROM, hence the worse video performance when there was heavy RAM activity. So the solution was to force my RAM's strobes to be asserted all the time when MREAD is high (read mode), and to only follow the strobes from the CPU when MREAD is low (write mode). Now the picture is perfectly-crisp, as you can see here!

Perfect over RGBtoHDMI, that is. Oddly enough, it's a little weird over the native HDMI output. Not sure why; it was fine before. I've attached a pic of the HDMI output too; you can clearly tell the difference!

Quote from: stepleton on December 10, 2025, 04:34:05 AMMeanwhile, I wonder if those bidirectional level shifters you've chosen are the same TXS0108Es I've regretted on Cameo/Aphid...

Yep, that's the exact level shifter I'm using! I'm really regretting them here too. They're probably/hopefully fine on the bidirectional lines, but utterly destroy the unidirectional ones. I just get random 5-20MHz oscillations that come and go. Not the end of the world for the ProFile because I've got the internal ESProFile that works fine, but this might prevent me from getting the floppy drive working on this board. I've got the onboard ESFloppy emulator, but I doubt my code for that is functional, and also it can't do writes yet. I really need to test with a real floppy drive first, but if I can't plug one in without oscillations, then I'm not sure what I'm supposed to do. I think the FPGA can actually tolerate 5V even though it's out of spec, so maybe I just remove the shifters and bridge straight across them?

You know the floppy controller error 57 I was getting? Well, it was really confusing me because the floppy controller worked great on the previous version of the project that ran on the PYNQ board, and I finally figured out why it's broken. It turns out it's not broken; it was getting confused because of the crazy multi-MHz oscillations on its inputs! I checked the status byte at FCC017 and it said the reason why it was failing the test is that couldn't step away from Track 0, but I didn't even have a drive connected, so I figured the oscillations were screwing things up. And sure enough, flipping the "Floppy Drive Source" switch from External to Internal (which isn't even running any code yet) made the error go away entirely. So we now make it through the whole self-test without issue!

The next order of business is going to be to expand the RAM a bit. Right now we're stuck with 512K, which makes LOS painfully-slow. So expanding to the full 2MB and getting the memory size jumpers going is next up.

I also tried booting the Workshop, and it boots just fine, but it's insanely slow. Anytime you type a key from the main menu, it takes about 10 seconds for it to process what you typed, and it comes back with a filesystem error whenever you try to launch a program. But clearly the FS is fine because it can list the directory just fine and the Preferences program can launch from an LOS instance on the same disk just fine. So I'm hoping that maybe the Workshop just hates living in 512K of RAM and that this will fix it.

After that, I'll probably get the H/3A and A8/40 ROM selection switches working. The selection part should be easy, but this also means that I'll need to add extra scaling logic to the HDMI subsystem for when the 3A ROMs are selected. So that'll be a good time to fix the HDMI issue that I'm having too.

Then I'll probably do the speed selection switches, which will control the DOTCK frequency. I'm not sure how high I can go before things break, but the SRAM will probably be the limiting factor. I'm hoping for at least 40MHz (2x the normal DOTCK speed), but maybe we can go even higher. I've already confirmed that I can lower the DOTCK (all the way down to 5MHz) without breaking anything, so hopefully raising it will be the same story.

Ignore the weird artifacts on the "good" picture; that's just thanks to image compression and nothing wrong with the Lisa!

Just got the full 2MB of RAM going. It's crazy how much faster LOS is with that extra RAM. Nearly unusable with 512K, but quite pleasant with 2MB. And those weird issues with the Workshop where programs wouldn't open and everything was insanely slow are all gone now, so it looks like the RAM upgrade fixed that too!

The size selection jumpers don't work because I implemented all the logic for size selection by inhibiting CAS and RAS when the CPU tries to access out-of-bounds memory, but then forgot to send those inhibited versions of CAS/RAS over to the RAM controller. So it's just stuck at 2MB all the time. But that's a super easy fix!

I've implemented that fix now, and I'm currently resynthesizing. I also added code to get the H and 3A CPU board ROM selector switch and the A8 and 40 I/O ROM selector switch working, so we'll see if those go as planned...

At the same time, I also added functionality to the speed selection switches, so that they can alter the speed of the Lisa's DOTCK. I picked 20MHz (stock), 40MHz, 60MHz, and 80MHz, which correspond to CPU clock speeds of 5MHz, 10MHz, 15MHz, and 20MHz, respectively. Given the external SRAM and its 55ns speed limitation, I'm not optimistic about being able to increase the DOTCK very far. I'm hoping to at least get the 40MHz DOTCK to work, but I really only give that about a 50/50 chance of success, and I highly doubt I'll be able to push it past there without having RAM issues.

But I'll find out about all of that in 40-ish minutes when the design is done synthesizing!

Awesome to see good video.

The HDMI issue looks a bit similar to situations I've encountered when making hacky adapters that go from TTL monochrome video to VGA. (Basically you buffer and level-shift the video signal into VGA RGB and then, if needed, massage the sync pulse timing as best you can to match the spec.) Modern LCD monitors do the best they can to cope with your adapted signal, but it's all too common to be off by subpixels, which does a number on single-pixel vertical lines. You find yourself making minute adjustments via on-screen menus to stretch the screen geometry just right, to change the phase of the video signal, and so on.

In the image itself it almost looks to me like the horizontal screen resolution is set to be just a little bit too narrow.

But I can't account for the "ghosts" of vertical contrast edges (e.g. the one just to the right of the window), which seems to me almost like a signal integrity issue!


As for the parallel port issues --- I'm inferring from your remarks that you're running I/O ROM 88, meaning a 2/10 I/O board, meaning a faster parallel port (reflecting earlier discussions). Maybe a 2/5 I/O board would achieve better behaviour? Or maybe the oscillations are more fundamental. For Cameo/Aphid, I achieved some stability improvements by putting some series resistance on the signal lines (on the +5V side).

For future designs, unidirectional ICs are likely the way to go, but if you want a bidirectional approach, the fistful-of-MOSFETs (https://electronics.stackexchange.com/questions/555631/understanding-how-this-bi-directional-logic-level-shift-works) method seems to work pretty well, as James D. can attest.

Eager to see what's next, in any case...

Quote from: stepleton on December 10, 2025, 11:43:03 PMAwesome to see good video.

The HDMI issue looks a bit similar to situations I've encountered when making hacky adapters that go from TTL monochrome video to VGA. (Basically you buffer and level-shift the video signal into VGA RGB and then, if needed, massage the sync pulse timing as best you can to match the spec.) Modern LCD monitors do the best they can to cope with your adapted signal, but it's all too common to be off by subpixels, which does a number on single-pixel vertical lines. You find yourself making minute adjustments via on-screen menus to stretch the screen geometry just right, to change the phase of the video signal, and so on.

In the image itself it almost looks to me like the horizontal screen resolution is set to be just a little bit too narrow.

But I can't account for the "ghosts" of vertical contrast edges (e.g. the one just to the right of the window), which seems to me almost like a signal integrity issue!

Yeah, not completely sure what's going on just yet. I put the image up on my big monitor instead of the HDMI capture device to get a better look at it, and it looks like every 8th column of pixels is a duplicate of the one 8 columns before. So I guess something to do with switching between bytes as we either read Lisa pixels into the framebuffer or read HDMI pixels out of the framebuffer. I'm going to try to change the pipelining logic for the scaling a bit to see if that fixes it, but I'm not sure.

The weird thing is that it was working perfectly up until a few days ago, so I'm not sure what changed!

Quote from: stepleton on December 10, 2025, 11:43:03 PMAs for the parallel port issues --- I'm inferring from your remarks that you're running I/O ROM 88, meaning a 2/10 I/O board, meaning a faster parallel port (reflecting earlier discussions). Maybe a 2/5 I/O board would achieve better behaviour? Or maybe the oscillations are more fundamental. For Cameo/Aphid, I achieved some stability improvements by putting some series resistance on the signal lines (on the +5V side).

I'm actually doing the 2/5 I/O board, mainly because I want Twiggy compatibility for the lucky few people (yourself included!) who happen to have some and might want to plug them in. I'm pretty sure the oscillations are more fundamental though, like where the level shifter can't figure out which side is driving it because it's got a signal from the FPGA on one end and a signal from a pullup on the other, and so it oscillates back and forth between the two, leading to a really high-frequency square wave.

For the next board revision, I'll almost certainly switch to unidirectional ICs for everything other than the few things that need to be bidirectional, and I'll probably go with the MOSFET strategy for those unless I come up with anything better. But I've heard that it's pretty reliable like you're saying, and James' board seems to prove it!

Synthesis finished, and I programmed the board with the new bitstream that should enable some of those additional switches. I ended up having to disable the speed switches thanks to some weird design rules Xilinx has when it comes to routing clock networks, so I'll have to come back to that later. But luckily it looks like the RAM sizing jumpers work now, and so does the CPU ROM H/3A selection switch. I obviously need to update the HDMI logic to detect which VSROM is installed and push out the pixels accordingly, but at least I can see that it's booting even if the square pixels make the screen garbled.

The I/O ROM A8/40 switch unfortunately doesn't seem to work though. The A8 position works fine, but the 40 position causes the I/O ROM revision to display as 52 and it hangs on the I/O board test for a while. Which means that the floppy controller never asserted DISK_DIAG and probably isn't making it through its self-test. I don't see anything it could be other than a corrupted ROM, so I'm rebuilding right now with a new ROM image and some tweaks to hopefully fix the HDMI weirdness to see if I have any luck there.

HDMI issues are (mostly) fixed! The weird repeated 8th line issue was thanks to a mistake in my video pipeline where I was always accidentally reusing the byte index from the previous pixel for the first pixel of the next byte, so the first pixel of the next byte was actually showing the first pixel of the previous byte. That's all fixed now!

The image is still slightly shifted to the right, but hopefully that'll easier to track down.

I think all the video issues are fixed at this point!

Now, when you flip the H/3A toggle switch, it not only switches the ROM, but it also switches the HDMI decoding to account for the different screen resolution and square pixels. It's pretty cool to be able to flip the switch and see the screen change while the Lisa is running, although of course it results in corrupted video until you flip the switch back or reboot!

While messing around in LOS, I discovered a really subtle bug with the I/O board. I was trying to change the contrast and noticed that the HDMI signal brightness wasn't changing, whereas it works fine in MacWorks.

After some digging through the LOS source code (LIBHW/MACHINE.TEXT and LIBHW/DRIVERS.TEXT), I discovered that LOS does a check at boot to see whether your I/O board is the "Sept81" or "Feb82" model. I don't think any Sept81 I/O boards are known to exist, so all 2/5 boards are the Feb82 revision. And interestingly enough, the two revisions handle setting the contrast differently.

But LOS is detecting my board as a Sept81 for some reason. And I think I know why. The way that it determines which one you have is by checking that the ProFile parity generator that hooks to PB5 on the parallel port VIA is functioning properly. Apparently the Sept81 board didn't have this parity generator, so if the parity doesn't work, then it knows it's a Sept81 board. So clearly my parity isn't working for some reason! So now I need to figure out why and fix it so it can set the contrast correctly...

It's just really funny that the parity on the ProFile bus being broken causes contrast not to work! And according to the source code, the contrast is the only thing that cares about whether your board is Sept81 or Feb82, so it makes sense that it's the only thing broken!

I was just thinking it would be pretty funny if someone crammed this into an old Macintosh case, like a 128K or Plus. It would give new meaning to the notion of a "Baby Lisa."

I've given up on the speed selection switches for the moment. I was able to get it going so that the Lisa would run at double speed (40MHz DOTCK, 10MHz CPU clock), and you could tell that it was a good bit faster, but it wouldn't boot anything except the Selector because I somehow managed to break the floppy controller pretty badly. And no matter what I did, I couldn't figure out why it was broken. So I've reverted back to the version before the speed switches were added and started working on other things from there.

The good news is that I fixed the I/O board parity issue that was keeping the contrast from working in LOS! I just had the parity backward from what it should be, so inverting it fixed things and now contrast works fine!

And over the past few days, I've been trying to get USB peripherals working. I've written the full interface modules for both the USB keyboard and mouse, and the mouse one actually works! It's so cool to be able to directly control the Lisa with a modern mouse! The mouse scaling is a little weird and so I'm trying to come up with a good algorithm for making it slower without sacrificing small mouse movements, but that's a minor detail.

The keyboard, on the other hand, is still having some problems. The keyboard module took forever to write thanks to the Lisa's weird keyboard protocol, the challenge of converting USB HID scancodes to the key down/key up codes that the Lisa uses, and the weird way that the USB keyboard handles modifier keys like control and alt, but I think the logic itself is fully-functional at this point. The problem is that it doesn't work! After probing it with a scope and comparing it to a real keyboard (actually a USB to Lisa adapter since I don't have a real Lisa keyboard), I discovered that I'd actually gotten one of the timings waaayyy wrong, so I just changed that and now I'm re-synthesizing to see if that helps at all. It really seems like the keyboard module is doing exactly what it should other than that; hopefully this is the only thing that's wrong with it. Aside from maybe some keys that I mapped incorrectly!

The USB keyboard works too! That timing issue was the whole problem. I've tested every key in LisaWrite and the only ones that don't work are the tilde, left option, numpad +, and numpad enter. Probably just a mistake with the scancode mapping, so any easy fix. And then we'll have a fully-functional USB keyboard interface!

I believe I have experienced some strange mapping issues with my regular Lisa keyboard and tilde vs. option sometimes. Could be a coincidence, but you may want to check what you're seeing against real hardware.

Quote from: stepleton on December 18, 2025, 03:56:37 PMI believe I have experienced some strange mapping issues with my regular Lisa keyboard and tilde vs. option sometimes. Could be a coincidence, but you may want to check what you're seeing against real hardware.

Yep, you were right! The tilde and option weirdness is the same on an actual keyboard. So the only issue was the numpad stuff, which is now fixed!

My next task is getting the USB mouse scaling to feel right, which is proving to be quite a challenge...

I haven't confirmed it, but there might be a difference in the behaviour of tilde/option when booting the Office System directly vs. booting via the Selector.

I base this suspicion on the fact that I can't imagine Apple would have shipped a LOS that swaps the keys like that, and I've observed it happen in basically-fresh LOS installs where the only thing different from 1984 is the presence of the Selector in the boot process.

If the Selector is indeed responsible, then the problem lies somewhere in here (https://codeberg.org/stepleton/lisa_io/src/branch/master/lisa_console_kbmouse.x68), though I have no theory that can account for why it should cause that trouble.

Another little update on what I've been doing over the past few days!

It's been really tough getting the USB mouse scaling right, but I think I'm finally getting close to something that feels decent. The original mouse still feels better and easier to control, but I'm not sure that I can get the USB one to feel much better. It's just really difficult to balance fine control when making small movements with reduced speed when making larger movements. Luckily Mac mice are plentiful, so if a user wants the better mousing experience, it's not very expensive to get it. Whereas the keyboard (where an original is much more expensive) is just as good over USB as it is with an original one.

The floppy drive wouldn't work thanks to the level shifters, so at the risk of pumping 5V straight into the FPGA and damaging it, I just desoldered the shifters and bridged straight over them. Which doesn't seem to damage anything, at least in the context of short-term testing. Obviously shifters will be the long-term solution though! And fortunately, the floppy drive works, so that's nice!

More recently, I've moved to converting HDMI from 1080p30 to 1080p60. I've been running on 30fps up until now because I have to be able to generate 5x the pixel clock in order to get the HDMI subsystem to work, and that comes out to a rather insane 750-ish MHz for 60fps versus about half that for 30fps. And it was pretty hard to meet timing for the 750MHz clock compared to the 325MHz one. But after some messing around, I'm now getting 60fps video out of it! It still doesn't quite meet timing and the audio over HDMI sounds weird for some reason, but I'm working on that right now. Most of the timing violation seems to be coming from the propogation delay through the divider circuit that divides the HDMI Y-coordinate by 3 to scale the pixels to the Lisa's 2x3 pixel aspect ratio. So I'm replacing the divider with a LUT and hopefully that'll fix it. If not, there are still some other solutions to try.

I've also messed around a bit with overclocking the Lisa, to more success than I was expecting. Clock muxing is much harder than I foresaw, so for the sake of testing, I've just been changing the clock speed and resynthesizing instead of making the speed configurable at runtime. It's able to run seemingly perfectly at a 40MHz DOTCK (10MHz CPU clock, twice the normal speed), and GUI operations in LOS feel really snappy at that speed. But disk I/O is still of course a bottleneck, so it's not a true 2x speedup.

It could also (sort of) run with a 60MHz DOTCK (15MHz CPU clock, 3x the normal speed), but there were some things that didn't quite work. For instance, communications with the floppy controller were pretty intermittent, and there were some COP issues too, but only with sending the "power off" command and reading/writing the clock; keyboard and mouse were still fine for some reason. And although the GUI in LOS of course felt really quick, it wasn't a 3x improvement overall thanks to I/O. As a test, I tried compiling LOS (which is a pretty disk-heavy workload) with the stock 20MHz DOTCK and then again with the 60MHz DOTCK, and the tripling of the clock only cut the compile time in half. Still a lot better than the stock compile time though!

I don't see it being very likely that I'll be able to get it working at 80MHz, but there's a chance that I might be able to get 60MHz fully-working, or something between 40 and 60 at the very least. We'll see!

Sorry for the big gap between posts!

Thanks to the help of another LisaList2 user who PM-ed me (they might want to remain anonymous so I won't mention their name, but they can feel free to comment here if they want credit), I was able to implement a much better mouse scaling algorithm that uses accumulators instead of the piecewise function scaling method, and it feels really, really good now. As good as (or maybe even a little better than) the stock Lisa mouse, so I'm going to call that a success!

I've put the 1080p60 and overclocking tasks aside for now so that I can get the more annoying task of designing the v2 PCB out of the way. There are several minor problems with the original board that, when all put together, are really bothering me (and some are a little more than minor), so I think it's time to fix all of them. I'm getting pretty close to finishing the board design, and here's a list of all the improvements:

• Swapped the labeling on two jumpers that I labeled backwards.
• Removed the power rail disconnect jumpers now that I know the switching regulators work.
• Swapped the R and B on ESProFile's RGB LED; I got them backwards the first time around.
• Added a BOOT button to both ESP32s; I learned the hard way that if you accidentally put them into USB-OTG mode and don't have a BOOT button, you'll be locked out and can't upload new code.
• Added a boost converter that generates 12V from the 5V USB-C rail instead of requiring 12V from the barrel jack; I'm honestly not sure why I didn't do this from the start...
• No need for the barrel jack anymore, so I deleted it.
• Replaced the FT2232's 93C46 EEPROM with a 93C56 EEPROM (see the posts from when I first got the v1 boards to learn why).
• Changed the interface between the two ESP32s and their SD cards from SPI to full-blown SDIO. This should greatly increase SD data transfer speeds, and will be necessary for the tight timings of the ESP32 floppy emulator. It won't hurt for ESProFile either!
• Added a jumper that lets you add/remove "scanlines" in the HDMI output; scanlines are added by simply blacking out every third line (or second line when using 3A ROMs) on the screen. I haven't actually tested this yet, so we'll see how well this strategy works before I commit to the jumper.
• Adjusted LED brightnesses by changing their series resistor values. They were all REALLY bright before!
• Fixed the issues with the TL074 op-amp and the onboard speaker. The audio output was really faint, caused by a combination of a few mistakes in that circuit.
• MOST IMPORTANTLY: Changed all the level shifters from TXS0108Es to a combination of other things. The bidirectional lines are now shifted by BSS138 MOSFETs, and the unidirectional lines are shifted by 74HCT245s (3.3V -> 5V) and 74LVC245s (5V -> 3.3V). Hopefully this will get rid of the weird oscillations and work a lot better!

Thanks to the level shifter oscillations, it seems like the external SCC wasn't really working at all, so I'll be able to test that for real when I get the new boards. Right now, any attempt to talk to it from LOS or the Workshop causes the system to hang.

I haven't fully settled on how to do this yet, but I'd also like to add Twiggy support without wasting tons of space with 2 huge Twiggy headers. So I was thinking I'd keep the Sony header, and then add a 4-pin header beside it to hold all the extra Twiggy signals. Then you'd hook both the Sony and 4-pin headers up to a separate breakout board that has the Twiggy ports on it. Does that sound like a good solution to the few Twiggy owners out there, or do you guys have some better ideas?

If anyone has any suggestions of other stuff to add/change on the v2 board, I'd be happy to listen!

Alex, I have to say I am absolutely astonished by what you've accomplished here. I've been lurking and following this thread after discovering it in November, and it finally pushed me to join LisaList2 so I could properly express my appreciation.

The Lisa holds a special place in my heart. As a teenager, it was my dream computer. That gorgeous machine with its revolutionary GUI felt like something from the future. Years later, I finally managed to acquire a Lisa 2/5, but it had suffered a NiCd battery explosion and leaking capacitors that led to corrosion and damaged PCB traces. The power supply was also failing with inconsistent voltages. I tried to repair it, but the work required was beyond my skill level at the time, so I regrettably sold it. I've kicked myself over that decision ever since.

Watching you bring the Lisa to life inside an FPGA has been incredible. From those first CPU board errors back in September to booting LOS and MacWorks, the pace of your progress is remarkable, especially considering you're doing this alongside a PhD program!

I'd love to support this project in any way I can. Whether that's helping with testing when you're ready, contributing toward board costs, or anything else that would be useful, please don't hesitate to reach out.

Thank you for giving those of us who couldn't hold onto our Lisas (or never had one at all) hope for experiencing this incredible machine again.

Is the V2 board going to be in the form factor of a 2/5 motherboard?  Ideally this should be the end goal so folks with battery bombed systems could replace the original CPU/IO/MEM/MOTHER boards with a single FPGA board.

Quote from: coffeemuse on January 09, 2026, 12:17:35 PMAlex, I have to say I am absolutely astonished by what you've accomplished here. I've been lurking and following this thread after discovering it in November, and it finally pushed me to join LisaList2 so I could properly express my appreciation.

Thank you! Glad you've been enjoying the journey so far, and I really appreciate the kind words!

Quote from: coffeemuse on January 09, 2026, 12:17:35 PMThe Lisa holds a special place in my heart. As a teenager, it was my dream computer. That gorgeous machine with its revolutionary GUI felt like something from the future. Years later, I finally managed to acquire a Lisa 2/5, but it had suffered a NiCd battery explosion and leaking capacitors that led to corrosion and damaged PCB traces. The power supply was also failing with inconsistent voltages. I tried to repair it, but the work required was beyond my skill level at the time, so I regrettably sold it. I've kicked myself over that decision ever since.

It was my dream computer as a teenager too, thanks to the revolutionary OS and fascinating architecture. But thanks to me being a teenager nearly 40 years after the Lisa was released, I was actually able to get one when I was 16 back in 2019. Also battery-bombed like yours, but I was able to fix it with the help of everybody on this forum. I didn't know a whole lot about them back then, but I've learned a lot over the last few years!

Quote from: coffeemuse on January 09, 2026, 12:17:35 PMI'd love to support this project in any way I can. Whether that's helping with testing when you're ready, contributing toward board costs, or anything else that would be useful, please don't hesitate to reach out.

Wow, thank you! Getting these boards fabricated and assembled in small quantities isn't cheap (around 700-something dollars after tariffs if I remember correctly), so I'd be really grateful for a contribution to cover some of that. Thanks for your generosity!

Quote from: Lisa2 on January 09, 2026, 12:40:45 PMIs the V2 board going to be in the form factor of a 2/5 motherboard?  Ideally this should be the end goal so folks with battery bombed systems could replace the original CPU/IO/MEM/MOTHER boards with a single FPGA board.

No, that's going to be a little further down the road. My initial goal is to make a board that's a completely standalone Lisa for people who don't have one but still want to experiment with one (or for people who do have one but want a nice and compact solution for messing around that has modern creature comforts like HDMI, USB peripherals, built in hard/floppy emulation, and USB to serial) so that's what I'm working on now. Besides, it's waaayyy easier to test/debug things on the standalone board versus a motherboard replacement version since you don't have to be tethered to a bulky Lisa chassis all the time.

But once the standalone board is fully-functional and up on GitHub, then I absolutely want to do a motherboard replacement version. After all of the FPGA stuff is working properly, that board should actually be easier to design than the standalone one since we won't need voltage regulation, HDMI, USB, onboard hard/floppy emulation, and other things like that.

Of course, the final designs will be open-source like everything else I make, so anybody is free to make and sell them. But to prevent people from having to pay the rather insane $700-ish just to get their hands on 2 boards, I'm thinking about also ordering a bunch of them in bulk (maybe my parents will give me a loan?) and selling them for a much-reduced price (maybe $160-ish each, it would depend on how big the bulk order is) to anyone who wants them. We'll see.

Quote from: AlexTheCat123 on January 09, 2026, 09:24:35 AMI'd also like to add Twiggy support without wasting tons of space with 2 huge Twiggy headers. So I was thinking I'd keep the Sony header, and then add a 4-pin header beside it to hold all the extra Twiggy signals. Then you'd hook both the Sony and 4-pin headers up to a separate breakout board that has the Twiggy ports on it. Does that sound like a good solution to the few Twiggy owners out there, or do you guys have some better ideas?

Don't go out of your way on my account at least! This seems like a good option to me.

Happy to chip in to the development fund.

Quote from: AlexTheCat123 on January 09, 2026, 01:34:49 PMIt was my dream computer as a teenager too, thanks to the revolutionary OS and fascinating architecture. But thanks to me being a teenager nearly 40 years after the Lisa was released, I was actually able to get one when I was 16 back in 2019. Also battery-bombed like yours, but I was able to fix it with the help of everybody on this forum. I didn't know a whole lot about them back then, but I've learned a lot over the last few years!

It was much earlier than 2019 for me, but I'll respectfully decline to post the actual date.

Quote from: AlexTheCat123 on January 09, 2026, 01:34:49 PMWow, thank you! Getting these boards fabricated and assembled in small quantities isn't cheap (around 700-something dollars after tariffs if I remember correctly), so I'd be really grateful for a contribution to cover some of that. Thanks for your generosity!

Hopefully the US Supreme Court sides with some of the lower courts and undoes some of the recent tariff burdens. In the meantime, I would be happy to contribute toward offsetting some of the costs for your next board run. Feel free to send me a PM and we can work out the details.

Quote from: AlexTheCat123 on January 09, 2026, 01:34:49 PMOf course, the final designs will be open-source like everything else I make, so anybody is free to make and sell them. But to prevent people from having to pay the rather insane $700-ish just to get their hands on 2 boards, I'm thinking about also ordering a bunch of them in bulk (maybe my parents will give me a loan?) and selling them for a much-reduced price (maybe $160-ish each, it would depend on how big the bulk order is) to anyone who wants them. We'll see.

If you end up doing a bulk order for the final standalone boards, I would definitely be interested. I would be thrilled to have one of these sitting on my desk someday. Thanks again for all your hard work on this!

Quote from: stepleton on January 09, 2026, 01:55:03 PMDon't go out of your way on my account at least! This seems like a good option to me.

Happy to chip in to the development fund.

Perfect, that's exactly how I'll do it then.

And thanks so much for the offer! Maybe I'll PM you as I get closer to being ready to order the boards.

Quote from: coffeemuse on January 09, 2026, 05:15:55 PMIn the meantime, I would be happy to contribute toward offsetting some of the costs for your next board run. Feel free to send me a PM and we can work out the details.

Thanks again, I sure will once the time comes!

Quote from: coffeemuse on January 09, 2026, 05:15:55 PMIf you end up doing a bulk order for the final standalone boards, I would definitely be interested. I would be thrilled to have one of these sitting on my desk someday. Thanks again for all your hard work on this!

Yeah, hopefully enough people will be interested for the bulk order idea to work out. Obviously it's not very useful if only 10 or 15 people say they want one!

Hi Alex,

Quote from: AlexTheCat123 on January 09, 2026, 09:24:35 AMIf anyone has any suggestions of other stuff to add/change on the v2 board, I'd be happy to listen!

Taking you up on your invitation for v2 board suggestions! This is more of a question than a suggestion, but I'm curious about enclosure options for the standalone board.

I noticed the OLED display, buttons, and switches for floppy emulation are mounted on the top surface of the PCB. I totally get that this makes sense for prototyping and early testing, but for those of us thinking about eventually housing a finished board in some kind of case or shell, are there any thoughts around this?

Specifically:

• Is there any consideration for providing headers to allow these controls to be relocated/extended?
• Are they positioned with any particular mounting orientation in mind?

Totally understand if this isn't a priority right now given everything else on your plate. I'm curious if it's on the radar.

Quote from: coffeemuse on January 12, 2026, 07:23:40 AMI noticed the OLED display, buttons, and switches for floppy emulation are mounted on the top surface of the PCB. I totally get that this makes sense for prototyping and early testing, but for those of us thinking about eventually housing a finished board in some kind of case or shell, are there any thoughts around this?

I honestly haven't thought about that at all! The floppy emulation is still in a really preliminary stage, so I'm not even sure if I'll be able to get it fully-working yet, and if not then those parts won't even be present on the final board. I think I've got all the code written to do floppy disk reads properly, but it hasn't been tested yet, beyond making sure the DC42-processing stuff works and that conversion to GCR and loading the data into the RMT is working properly. I can't test it until I get the v2 boards since I only have enough RAM to hold 2 sectors at a time (they take up a lot more space when in RMT format, a full 4 bytes of RAM per flux transition), which means that I have to access the SD card a lot, and SPI just isn't fast enough for this. So I need SDIO, which will be present on the v2 board.

All this to say that the relocation of the buttons will probably be an issue for further down the road when I'm sure that they'll actually be on the board to begin with. And if the floppy emulator ends up working out, then I'd probably stick the buttons and OLED (along with the power, reset, and other control switches maybe) on a little breakout board that plugs into the mainboard with a ribbon cable. Then you can just screw that to the top of your (presumably 3D-printed) enclosure. How does that sound?

Quote from: AlexTheCat123 on January 12, 2026, 04:07:24 PMAll this to say that the relocation of the buttons will probably be an issue for further down the road when I'm sure that they'll actually be on the board to begin with. And if the floppy emulator ends up working out, then I'd probably stick the buttons and OLED (along with the power, reset, and other control switches maybe) on a little breakout board that plugs into the mainboard with a ribbon cable. Then you can just screw that to the top of your (presumably 3D-printed) enclosure. How does that sound?

That sounds like a great approach. A breakout board with a ribbon cable would make enclosure design much more flexible. I wasn't trying to request any design changes; just wanted to confirm what enclosure considerations were on the radar.

I've had a 3D-printed case with 1980s-era aesthetics in the back of my mind, so that setup would work really well down the road. Good luck with the SDIO testing on the next iteration of boards. I am looking forward to seeing how the floppy emulation progresses.

Quote from: coffeemuse on January 12, 2026, 04:54:57 PMGood luck with the SDIO testing on the next iteration of boards. I am looking forward to seeing how the floppy emulation progresses.

Thanks! I really hope I can get it working; it would be nice to have an open-source alternative to the Floppy Emu out there. Granted, mine will probably never support 1.44MB disks, but at least it would do 400K, 800K, and maybe/hopefully even Twiggies.

Is there such a thing as a virtual twiggy?

Quote from: Jacexpo on January 14, 2026, 10:16:44 PMIs there such a thing as a virtual twiggy?

As far as I know, there aren't any Twiggy emulators out there right now. LisaEm is capable of using Twiggy images, but it's pretty hit-or-miss, at least in my experience.

And to be clear, my first priority is Sony emulation, with Twiggy coming later. And that's only if I can even get Sony emulation working to begin with! I just want to set expectations low here so that nobody's disappointed if I fail miserably. Making a floppy emulator isn't quite as easy as a ProFile emulator!

Don't want to hijack Alex's thread, just want to add more info:

I added support for Twiggy disk images in LisaEm last year, it wasn't available before that. It works sufficiently well and supports both Twiggy drives, e.g. I am able to install LOS 1.0 from Twiggy floppies which involves using both drives. More info on how to use it: https://github.com/arcanebyte/lisaem/pull/22

Also, there is already an open source alternative to FloppyEmu: https://github.com/vibr77/AppleIIDiskIIStm32F411 ,  for Apple II only. It is on their roadmap to support Macintosh and Lisa eventually, once Apple II works sufficiently well (it does). You can follow it at https://www.applefritter.com/content/apple-ii-disk-emulator-using-stm32 .

Wow, good to know! I had no clue anybody else was developing an emulator.

I'm getting closer to finishing with the v2 board! I finally got through all the level shifters; upgrading those took forever because it required rerouting pretty significant chunks of the board.

I've also added Twiggy support now, using the breakout idea we discussed earlier. I've attached a pic of what the breakout looks like. I really wish I could've used a shrouded header for the 4-pin connector that carries the extra Twiggy signals, but they just don't have any in stock. And I know it looks really bad, but I decided to just autoroute this board since I don't care about this one that much compared to the main PCB. Maybe I'll go back and manually route it later...

Aside from just checking everything over, I think the v2 board might be done now!

I ended up adding trimpots to all the LEDs instead of fixed series resistors so that I can perfectly dial in the brightness for each one. Right now, some are way too bright and others are on the dimmer side, so this should be a good way to even them out. And then I can measure the pot resistances to swap them out for fixed resistors in the final design.

I also thought that something was wrong with the TL074 audio amp/contrast circuit because it was producing super quiet audio through the built-in speaker, and no contrast signal at all. Not that it mattered a ton in my testing because I'm also doing audio and contrast over HDMI, but many people who will have their board connected to a monitor as opposed to a TV won't be able to get HDMI sound to begin with, so it's still really important for the speaker amp and onboard speaker to work. It turns out that nothing was wrong with it though; I had just forgotten to supply 12V to it and was only sending -12V! The v2 board now has an onboard step-up converter to generate 12V from the 5V USB power instead of requiring 12V to be provided externally from the barrel jack (which has now been removed entirely); not sure why I didn't do it like this before.

Oh yeah, I also added a "scanlines" jumper that will hopefully allow you to enable or disable simulated scanlines in the HDMI output. I accidentally enabled this feature on my RGBtoHDMI and thought it made the Lisa display look pretty cool, so might as well try to add it here. It looks like all it's doing is blacking out every third row (regular Lisa) or every second row (screen-modded Lisa) of pixels in the HDMI framebuffer, so that should be pretty easy to implement!

The v2 board will definitely still be in the prototype phase (although a lot more polished than v1), but hopefully v3 will be the final release board. We'll see!

Of course, if anybody sees any issues or areas for improvement in these pictures of the v2 board, let me know and I'll get it changed!

Quote from: AlexTheCat123 on January 15, 2026, 06:55:07 PMAnd I know it looks really bad, but I decided to just autoroute this board since I don't care about this one that much compared to the main PCB.

tbh I kind-of like it when you find the odd little autorouted (or wire-wrapped or perf-boarded) interposer amidst otherwise thoughtfully-designed hardware --- it says to me "there's a story behind this"...

With the disclaimer that free suggestions are worth what you pay for them... here are two user-interface thoughts for V3, both probably pretty obvious and neither one a showstopper:

(1) It would be nice if it didn't matter which USB port received the mouse and which received the keyboard.
 
(2) The bottom edge of the board as depicted feels like the user-facing side of the machine, so it makes sense for that side to have the stuff the user is most often going to mess with. To me, this would argue for putting the floppy and hard drive SD slots on or near that edge if you can. If you need to free up room along the edge, maybe one of those double-stack USB sockets might help?

QuoteWith the disclaimer that free suggestions are worth what you pay for them...

Ditto

Quote(2) The bottom edge of the board as depicted feels like the user-facing side of the machine, so it makes sense for that side to have the stuff the user is most often going to mess with.

This seems like great advice, and got me thinking, what would I move where... Lisa mouse port to back perhaps and....

Then it occurred to me that the iterations of the layout for ports and ancillary hardware might be separated from the iterations of the core functionality, reducing the cost for incremental changes to one or the other.

ie. determine a suitable boundary (eg. low speed and fewest signals) for separating legacy ports from the FPGA and RAM, and implement a main board/daughterboard. The cost of an interconnect is substantial, but when the cost of new boards is so high.... depends on your confidence level as to how many iterations you expect and if early versions are complete write-offs or still useful. Lowering the cost of changing the legacy ports layout could make it more practical/economical to have different final configurations too.

Interconnects generate problems as well as increased cost, so quite possibly not a good idea (see top paragraph).

For the floppy, consider making the layout compatible with a 26 pin header that has two pins removed so a 20 pin plug will still fit.

... many decisions

Quote from: stepleton on January 16, 2026, 04:28:54 AM(1) It would be nice if it didn't matter which USB port received the mouse and which received the keyboard.

A very good idea! For some reason, I dismissed this as insanely difficult before, but it's really nothing more than muxing a few signals. I'm working on it now.

Quote from: stepleton on January 16, 2026, 04:28:54 AM(2) The bottom edge of the board as depicted feels like the user-facing side of the machine, so it makes sense for that side to have the stuff the user is most often going to mess with. To me, this would argue for putting the floppy and hard drive SD slots on or near that edge if you can. If you need to free up room along the edge, maybe one of those double-stack USB sockets might help?

My only concern there is that, especially once I switch to SDIO, those SD cards could be running at 50+ MHz (I think the ESP can even go up to 100 on SDIO). And I'm worried that the long traces would lead to signal integrity issues. Whereas right now, the slots are just about as close to the ESPs as they can get.

Quote from: sigma7 on January 16, 2026, 01:41:45 PMThen it occurred to me that the iterations of the layout for ports and ancillary hardware might be separated from the iterations of the core functionality, reducing the cost for incremental changes to one or the other.

ie. determine a suitable boundary (eg. low speed and fewest signals) for separating legacy ports from the FPGA and RAM, and implement a main board/daughterboard. The cost of an interconnect is substantial, but when the cost of new boards is so high.... depends on your confidence level as to how many iterations you expect and if early versions are complete write-offs or still useful. Lowering the cost of changing the legacy ports layout could make it more practical/economical to have different final configurations too.

I thought about this way earlier on in the design process, and opted against it just because it was sort of hard to separate what would go on the peripheral board versus the core board. The boundary isn't super clear-cut. Maybe I should have done this, but at this point I think it would require such a substantial redesign that I'll probably opt not to for now.

Quote from: sigma7 on January 16, 2026, 01:41:45 PMFor the floppy, consider making the layout compatible with a 26 pin header that has two pins removed so a 20 pin plug will still fit.

I briefly considered this too, instead of the 20 pin + 4 pin strategy, but it would require making the 26-pin connector incompatible with Twiggies, and I was trying to avoid the situation where someone might get confused and plug a Twiggy straight into the board expecting it to work. Any ideas to prevent this?

Also, even if I were to remove 2 pins to allow a 20-pin connector to plug in, wouldn't the keying slot still be a problem? I don't think the slot on a 26-pin header would line up with the notch on a 20-pin connector that's plugged into one side of the header.

Sorry for the lack of updates; some weird things have been happening with the FPGA lately. Everything was working so great, and then it all just started breaking. First the floppy controller started acting up, and every time I would resynthesize to try and fix it, the problem would either change or go away entirely. And then other things started breaking and acting intermittent too.

But I think I've finally realized what the problem is. Over the course of the project, I've marked a bunch of signals for debugging using the MARK_DEBUG attribute, which causes the signals to be preserved during synthesis and prevents certain optimizations from taking place. I thought I had been unmarking signals whenever I didn't need to debug them anymore, but clearly not, because I checked and there were nearly 1,500 signals that were marked for debugging! With that many signals being excluded from optimization, weird timing things are bound to happen, so I've been going back through and unmarking as many of them as possible now. And as I do that, everything seems to be starting to work properly again!

Clearly there's still something that's not quite right, even as I remove the MARK_DEBUG attributes, because I just tested with a real floppy drive for the first time and things aren't working quite right over there. So obviously, there's some big difference between the real drive and the Floppy Emu that I need to track down.

Whenever I hit a dead end on one issue, I always try to pivot to another issue and then come back to that one later in the hopes that I'll have new ideas to resolve it, and that's exactly what I did here. I pivoted from trying to get a real floppy drive working back over to trying to get overclocking working. Last time I tried it, I didn't understand the physical arrangement of clock buffers and multiplexers on the chip as well as I do now, and my better knowledge the second time around allowed me to successfully implement the clock mux between 10MHz, 20MHz, 40MHz, and 60MHz dot clocks.

This meant that I could pick between the clocks using the switches on the board instead of having to hard-code one at build time like before, but the weird problems at 40MHz and 60MHz that were present the last time I tried it were unfortunately still there. For anyone who didn't catch the posts where I talked about those issues, basically the speaker would just randomly beep while LOS was running, you couldn't read the clock from the COP (LOS would say the date/time was invalid and the Workshop would actually tell you that the procedure call to get_time() failed), and the COP would never turn the Lisa off after the screen dimmed to black during shutdown.

Obviously the last two problems point toward the COP, but I wanted to address the speaker issue first since it seemed a bit more perplexing. So I hooked a virtual logic analyzer to the FPGA and started looking at the 68K bus to see if it was actually commanding the speaker to beep or if there was just some kind of signal noise that was inadvertently causing the beeps. This is why I asked Claude to make that disassembler I mentioned in another thread. And it turns out that the 68K was actually commanding the VIA to beep the speaker, so I dug into the LOS source code to figure out how the NOISE routine worked (LIBHW/MACHINE.TEXT). Working backwards from the value the 68K was putting into the VIA timer 2 register, I was able to determine that the wavelength of the tone was 4545, so now it was just a matter of looking through the entirety of the LOS source to see what called the beep routine with that wavelength.

There were two callers using that wavelength: one in LIBHW/KEYBD.TEXT and one in LIBHW/TIMERS.TEXT. The one in KEYBD will beep the speaker if the keyboard input queue ever fills up, but the one in TIMERS made a lot more sense in this context. That one beeps the speaker if the Lisa ever fails to read the clock from the COP, which lines up perfectly with the clock errors that we were getting!

So now the question is: why are we failing to read the clock? Whatever the reason, it's probably the same reason why we're failing to shut the system down. Both of those operations involve writing a command to the COP, whereas getting keyboard/mouse movements (which both worked fine) only requires reading from the COP, so it sounds like we have some kind of write issue. So I looked at more signals and slowly figured out what was going on.

The COP puts out a signal called READY that goes into either CA1 or CA2 (I forget which) of the keyboard VIA. READY is high most of the time, but goes low briefly every one in a while to signify that the COP is ready to receive a command from the VIA. If the 68K wants to send the COP a command, it's expected to wait for READY to go low, and then shove the command out onto the COP data bus as soon as READY drops.

That all makes sense, but this is where it gets weird. You'd think that it would be safe to remove the command from the COP's bus as soon as it pulls READY high again, but no, apparently you have to leave it there for a little while longer (2 or 3 extra READY-lengths) after READY is deasserted. Otherwise, the COP doesn't see your command and won't respond with any data. At the standard 20MHz dot clock, the 68K was leaving the command on there for long enough for the COP to see it, but at the higher dot clocks, it was removing the command too fast and the COP would never respond with the clock data, hence the beeps and clock errors! Same goes for the power-off command; the COP never received it and the system never turned off.

Luckily, the solution is simple. The VIA register that determines whether the VIA is outputting over the COP bus is DDRA (Data Direction Register A), and the entire issue here is simply that DDRA is being turned back from an output to an input too quickly. So I just wrote some simple logic that extends the falling edge of DDRA a bit; now DDRA stays in output mode for a little while longer even after the 68K commands it to go back to input mode. I know it sounds weird to say "falling edge" since DDRA is a full register with 8 bits in it, but I'm treating all of DDRA as a single bit since all of the data bits on PORTA will always be going in the same direction.

You might wonder why we don't get errors in the boot ROM, given that it also reads the clock and is capable of powering the system off, neither of which caused any problems. Well, the boot ROM uses a slightly different COP communications routine that already keeps the bus set to output mode for a little longer anyway, so even with the faster clock, it's still within tolerance.

Now that I've fixed that COP issue, the 20, 40, and 60MHz DOTCKs all seem to work perfectly. Unfortunately, 10MHz doesn't quite work right, and probably never will. And it's for the opposite reason from the above. Instead of us switching the COP bus from an output to an input too early like before, now the CPU is so slow to react to READY going low that it misses the READY pulse entirely and doesn't set the COP bus to an output until after the pulse is already over. There's not really a way that I can hack around that problem, short of overclocking the COP, but then that introduces more problems related to compatibility at other clock speeds. Not to mention the fact that the real time clock wouldn't be accurate anymore!

So with that in mind, I think I'm going to get rid of the 10MHz DOTCK (not sure why people would really want a 2.5MHz Lisa anyway) and try to replace it with an 80MHz DOTCK. No promises or anything, but I got it going at 60, so perhaps I can get 80 going too! Who knows, maybe even 100MHz is possible...

Thanks for the write-up!

One question comes immediately to mind: does this mean that the clock speed-up is being applied selectively to some components (like the CPU) and not others (like the COP)?

Here's another: what does beeping sound like at 60 MHz? I assume the VIAs are being sped up and so the beep might be very high-pitched!

Quote from: stepleton on January 29, 2026, 04:01:18 AMOne question comes immediately to mind: does this mean that the clock speed-up is being applied selectively to some components (like the CPU) and not others (like the COP)?

Yes! The only thing I'm messing with is the DOTCK. I don't want to speed up the COP because I'd like for the RTC to still be accurate, and I can't really speed up the 16MHz I/O board clock because that would utterly destroy the floppy disk read/write timings.

Quote from: stepleton on January 29, 2026, 04:01:18 AMHere's another: what does beeping sound like at 60 MHz? I assume the VIAs are being sped up and so the beep might be very high-pitched!

Very fast and high-pitched indeed! I guess this would be the one benefit of recreating the 2/10 I/O board (at least as far as pitch is concerned, not speed), but I still think it's better to do the 2/5 I/O board to remain compatible with Twiggies!

I just tried it at 80MHz, and, well, it's at least partially functional!

Initially, it just gave the two low-pitched (although thanks to the overclocking they're actually really high-pitched) beeps indicating that no RAM was detected, so I started looking at some signals and discovered that we're starting to run up against the limits of my RAM chip. Writes were working fine, but reads weren't; by the time the RAM chip had retrieved the data, the 68K had already moved onto the next instruction. But it was really close; if the RAM chip had been selected just a single DOTCK cycle earlier, I figured that the data would probably be ready in time. So I modified the RAM board code to select the chip on the falling edge of RAS instead of waiting for CAS too, which isn't accurate to the original design anymore and breaks things at lower clock speeds, but at least helps me get further along at 80MHz.

After making that change, the Lisa almost makes it all the way through the self-test. I do get an error 54 though (clock error), indicating that the COP sync issues I talked about in the last post are back again. I guess the clock is getting so fast now that even my (rather long) DDRA delay circuit isn't enough. I'll try making it even longer and we'll see if that revives the COP.

I can boot into the Selector, although I always get an error 84 on my first boot attempt. The second time works fine. At that point, no operating systems fully boot.

LOS crashes out super early, not even giving an error or anything and just resetting the entire machine a few seconds after the boot starts.

MacWorks Plus turns the Lisa off the moment it gets to the blinking question mark screen. It's clearly a controlled power-off (the screen dims nicely and everything), so I'm guessing that COP issues are to blame for this.

MacWorks XL actually boots nearly all the way into Mac OS, but it hangs with the menu bar visible and nothing on the desktop.

Xenix reports hard disk errors; I think we're starting to push up against the limits of what ESProFile can handle too. And Xenix is also really picky about disk timings for some reason. Not sure if a real ProFile would work at these speeds; probably not.

With all of this in mind, I'm guessing that I probably won't be able to get things working at 80MHz. Even if I can get the COP issues fixed, there seem to be deeper issues, and even if all the problems could be fixed then we still have the issue of hard disk timing issues and getting the RAM timings to work with all the DOTCK configs. I'll keep trying a little bit more though!

In the very likely reality where 80MHz doesn't work out, then this begs the question: what clock speeds do we want on the selection switches? There are 4 switch combinations, so 4 different clocks we can select. I was hoping to do either 10, 20, 40, and 60MHz or 20, 40, 60, and 80MHz, but we already know that 10 is out and 80 is probably going to be out too, so that just leaves us with 20, 40, and 60. We need to pick one more speed that's within those bounds for the extra switch position. Any preferences? And do we keep 40 or replace it with some other speed between 20 and 60?

One thing I can say with near certainty: 100MHz is ABSOLUTELY NOT going to happen!!!

42, of course. The answer to the Ultimate Question of Life, the Universe and Everything.

Can the switch control something else? Square pixels vs. tall pixels would be very handy, though I'm guessing you're already accommodating that in one way or another.  Otherwise I can't really think of anything. Choose a frequency that makes it easiest to bit-bang an address line so that you can play a tune on an AM radio?

(For v3 move from switches to a rotary encoder that goes from 5 MHz for the 68k to the upper limit...)

If there's any chance, I'd love to see a cheap-and-cheerful video of LisaMandelbrot Solo running on the 80 MHz dot clock Lisa...

Quote from: stepleton on January 30, 2026, 04:15:59 AMCan the switch control something else? Square pixels vs. tall pixels would be very handy, though I'm guessing you're already accommodating that in one way or another.  Otherwise I can't really think of anything. Choose a frequency that makes it easiest to bit-bang an address line so that you can play a tune on an AM radio?

Yep, I already have an H/3A switch for that! Playing music sounds like a good idea though...

Quote from: stepleton on January 30, 2026, 04:15:59 AM(For v3 move from switches to a rotary encoder that goes from 5 MHz for the 68k to the upper limit...)

I wish I could, but unfortunately that's not as easy to implement as it sounds. You can't easily sweep the output frequency of an MMCM across a range, and I guess I could use a variable clock enable on a single high-speed clock to accomplish the same thing, but that would require rewriting significant portions of the code. And it would probably break a lot of stuff, so I'm not sure it would be worth it!

Quote from: stepleton on January 30, 2026, 04:15:59 AMIf there's any chance, I'd love to see a cheap-and-cheerful video of LisaMandelbrot Solo running on the 80 MHz dot clock Lisa...

Here you go!
https://www.youtube.com/watch?v=o00bQq0lx0A

I haven't given up on getting 80MHz working just yet. I've tracked down the COP issue; it's no longer a sync problem with sending the command. That part works fine now. The new issue is that the COP takes "so long" to return the data that the 68K times out before it's ready. At the lower (but still overclocked) clock speeds, the timeout loops were tolerant enough that the CPU was still willing to wait long enough to retrieve the data, but not anymore. Remember, we're running at 4x the stock clock speed now, so the timeout periods are essentially 4x shorter than they should be.

There may not be anything I can do about this. Obviously I can't patch the ROM (and every other piece of Lisa software) to extend the timeout because that's just a really dumb solution, and I also can't overclock the COP because that would mess up the RTC and break the timing of the keyboard interface.

Unless anyone else has any suggestions, my only remaining idea is to try and shorten my "extended" pulse on DDRA that feeds the COP its command. Obviously it needs to be extended some because otherwise the COP will never receive its command at the higher clock speeds, but perhaps (and this is just a total guess) the COP doesn't start processing the command until DDRA goes back to an input again and takes the command off the bus. And given that I'm probably extending the pulse for longer than I need to, maybe I'm wasting some time during which the COP could be processing the command. So what if I just shortened the pulse a bit, in the hopes that the COP starts processing the command quicker and returns the data faster, hopefully within the timeout period? That's what I'm about to try, and hopefully it works! If not, then I think we might be stuck with 60MHz, or maybe I can try 70 and see if I have any better luck there...

Yeah, shortening the DDRA pulse made no change whatsoever, so I don't think there's any way to fix this. I'm going to try stepping the clock down in increments of 5MHz until I can find the highest point at which the COP works, and we'll call that the max speed. Hopefully it's above 60MHz!

By the way, it takes about an hour and 15 minutes to resynthesize the design at this point, so if anyone's wondering why progress is slower now than it used to be, that's your answer. Just changing a single line of code necessitates a full resynthesis, so every little change takes that long to test. And if the new design struggles to reach timing closure, it can take even longer than that!

Wow, thanks for recording that video. 80 MHz is quick! It's also cool to see that you can change the clock while the machine runs.

Maybe it really is a little too soon to give up on 80 MHz. If it's the CPU timing out, are there ways to suspend it or slow it down around critical access to the COP (and maybe other components too)? It looks like you would want to specifically detect clock queries as the mouse seems fine in your video. Maybe there's a pin you can keep (de-)asserted that holds the 68000 in place, or if nothing else you could have the hardware send `foo: BRA.S foo` instructions to the CPU on instruction fetch (you'll need to hold off delivering interrupts too in that case, I suppose).

Or just leave things as they are and say: well, it's not for the software we have now, but maybe people designing new software can write code to take advantage of it! Put a skull and crossbones on the silkscreen around the 80 Mhz setting so that people don't make service enquiries to you when throwing it crashes the machine ("what did you expect?"). Then one day much later someone who does have the urge to hack the software can say "I unlocked pirate mode!!"

In re "dial-a-clock", my inspiration: if you ever find yourself in Cambridge, England, there is a computer museum there that has a computer made from discrete surface-mount transistors and so on. I believe the whole computer (and not just the processor) is made this way; in any case, it is huge, filling up multiple panels the size of tall cubicle walls and stretching out along much of the length of the room. They usually have it set up so you can play Tetris on it. But my favourite part of it is a gigantic forearm-sized rheostat that looks like it came out of a locomotive --- I'm sure it's handling only a couple milliamps its current role, which is letting you select the processor clock speed at any point from 0 to a few tens or hundreds of KHz if memory serves.

Quote from: AlexTheCat123 on January 30, 2026, 10:56:23 PM

Quote from: stepleton on January 30, 2026, 04:15:59 AM(For v3 move from switches to a rotary encoder that goes from 5 MHz for the 68k to the upper limit...)

I wish I could, but unfortunately that's not as easy to implement as it sounds. You can't easily sweep the output frequency of an MMCM across a range, and I guess I could use a variable clock enable on a single high-speed clock to accomplish the same thing, but that would require rewriting significant portions of the code. And it would probably break a lot of stuff, so I'm not sure it would be worth it!

I may be missing something here, so please take this as a naïve observation rather than a proposal.

I completely agree that a potentiometer or swept clock runs into real MMCM and architectural issues. What occurred to me while reading the thread was that some of the "knob" UX might be achievable with a much simpler mechanism: a 2-pole, 4-position detented rotary switch, rather than a pot or encoder.

Electrically it would just be selecting among the existing discrete speed presets (the same thing the two speed-select switches already do today), so there's no clock sweeping or refactoring involved. Mechanically it feels like a single "speed knob," which is very period-appropriate, but logically it's still just fixed presets.

If the speed-select signals were ever exposed on a small header, this could even be entirely optional and external (case-mounted), leaving the current on-board switches and hot-switching behavior untouched. I mention it only because v3 is being finalized now and it seemed like a very low-impact way to split the difference between UX and complexity.

Happy to be corrected if I'm overlooking something.

Quote from: stepleton on January 31, 2026, 07:23:43 AMMaybe it really is a little too soon to give up on 80 MHz. If it's the CPU timing out, are there ways to suspend it or slow it down around critical access to the COP (and maybe other components too)? It looks like you would want to specifically detect clock queries as the mouse seems fine in your video. Maybe there's a pin you can keep (de-)asserted that holds the 68000 in place, or if nothing else you could have the hardware send `foo: BRA.S foo` instructions to the CPU on instruction fetch (you'll need to hold off delivering interrupts too in that case, I suppose).

I didn't really want to do anything like that for the sake of remaining completely cycle-accurate to the original Lisa. Sure, the extension of DDRA isn't accurate, but that's completely invisible to the programmer and to all the hardware except the COP, so it doesn't really matter. But stalling the 68K until the COP data is getting closer to being ready definitely hurts that accuracy. Which doesn't quite sit right with me.

But of course, this project is for everybody, not just me, so if it's what other people want then I'll absolutely give it a shot! I'm not super familiar with how the synchronous 6800-style bus cycles work and whether you're allowed to delay VPA like you can with DTACK without the 68K immediately bus erroring, but maybe I could make it so that, after the CPU sends a command to the COP through the VIA, it doesn't actually see VPA get asserted until the data is ready. That way, whenever it's time to read the data, it's guaranteed to be there!

Some pretty good news: I just tested it at 75MHz and it seems to work just fine, with no COP weirdness or RAM mods needed, so at least we have that to fall back on if 80 doesn't work.

Quote from: coffeemuse on January 31, 2026, 09:34:34 AMI completely agree that a potentiometer or swept clock runs into real MMCM and architectural issues. What occurred to me while reading the thread was that some of the "knob" UX might be achievable with a much simpler mechanism: a 2-pole, 4-position detented rotary switch, rather than a pot or encoder.

Ahhh, I see! That's a really excellent idea. I'll look and see what LCSC has in stock and stick one on the board. That would be a much better interface than two switches.

Quote from: coffeemuse on January 31, 2026, 09:34:34 AMI mention it only because v3 is being finalized now

Just to be clear to everybody, v2 is the one that's being finalized right now, and v3 is probably going to be the first release version. There might still be some really minor issues with v2 that need to be cleared up, and labeling that needs to be changed as the design changes, so I don't want to commit to anything with it.

> But of course, this project is for everybody, not just me, so if it's what other people want then I'll absolutely give it a shot!

That's generous! I'm for it, but sparingly. I think this kind of trick is not uncommon with accelerators (though others on this board can say much more authoritatively). My recollection is that the "fast" Apple IIs inside of the IIGS and maybe also the IIc+ and the Apple II expansion card for Macs might do it this way too. So it's straying a bit from the Lisa tradition but still applying a time-honoured technique.

Here's one way to look at it: it might be handy to have a facility that can delay or suspend the CPU temporarily for a few reasons. There's debugging, and also if there's ever a plan to make a version of this apparatus that has an expansion port or that's used to help make expansion cards, then it could be that existing cards and new cards under development may simply be unable to cope with such a high clock rate. Working out a way to selectively slow the Lisa when it carries out certain accesses could be helpful, especially if you've got a kind of bug where it's helpful for the rest of the system to be fast.

Made-up example: you're working on a networked disk driver for the Office System for a Lisa Fujinet expansion board. The hardware can only go a certain speed, so the slowdown feature is handy. But since it's an OS driver, crashes are frequent, and you're often having to reboot the entire machine and start over. Thankfully it doesn't take all that long to get you back to where you were!

Another thing that might be handy for hardware hacking --- and perhaps an alternative to an 80 MHz switch. What about a 0 MHz switch? Some parts of the Lisa might not like it, but if not, if you could freeze it in its tracks, it could be handy. Maybe even have a pin on the board that's ordinarily pulled down to 0V, but make it logic-high and the Lisa stops right where it is... with another pin right next to it for stepping. If triggerable by a logic analyser then that could be very helpful indeed. OK, this is getting a bit elaborate, but it's fun to think about :-)

So even if not part of the "main" Lisa FPGA programming, it could still be handy to know how to do this well.

Quote from: AlexTheCat123 on January 30, 2026, 10:56:23 PMUnless anyone else has any suggestions

Since you've covered the maximum compatibility option, I suggest aiming for a maximum performance option. eg. a setting for maximum workable clock rate, overclock the COPS by say 2x or 4x so it generally 'works' with the caveats that the RTC is wrong and Lisa keyboard/mouse artifacts will occur until someone tweaks the COPS code to account for the faster COPS clock. I suppose that means having a duplicate COPS ROM that is switched in with the expectation that there will someday be two versions. [shrug]

Quote from: stepleton on January 31, 2026, 01:20:00 PMWhat about a 0 MHz switch? Some parts of the Lisa might not like it, but if not, if you could freeze it in its tracks, it could be handy.

That would be a great way to troubleshoot real Lisa CPU boards. Regrettably, the original NMOS 68000 has a minimum clock speed, so one would need to swap in the CMOS version eg. MC68C000 which will operate down to 0 MHz.

Quote from: stepleton on January 31, 2026, 01:20:00 PMAnother thing that might be handy for hardware hacking --- and perhaps an alternative to an 80 MHz switch. What about a 0 MHz switch? Some parts of the Lisa might not like it, but if not, if you could freeze it in its tracks, it could be handy. Maybe even have a pin on the board that's ordinarily pulled down to 0V, but make it logic-high and the Lisa stops right where it is... with another pin right next to it for stepping. If triggerable by a logic analyser then that could be very helpful indeed. OK, this is getting a bit elaborate, but it's fun to think about :-)

Quote from: sigma7 on January 31, 2026, 02:32:10 PMSince you've covered the maximum compatibility option, I suggest aiming for a maximum performance option. eg. a setting for maximum workable clock rate, overclock the COPS by say 2x or 4x so it generally 'works' with the caveats that the RTC is wrong and Lisa keyboard/mouse artifacts will occur until someone tweaks the COPS code to account for the faster COPS clock. I suppose that means having a duplicate COPS ROM that is switched in with the expectation that there will someday be two versions. [shrug]

Wow, these two answers couldn't be any more different! We've got "so fast that it breaks things" and "literally no clock at all", and between the two, I'm probably going to lean towards the 0MHz clock. Pushing the clock even higher at the expense of the COP worries me a bit because I'm not even sure how to test certain things without a keyboard, and I bet a lot of other things will begin to break as I go past 80MHz. Plus, there's no guarantee that anyone will ever fix the COP, so there's a good chance that most people would never end up using this mode. Whereas 0MHz is pretty darn easy to do and could have a wide set of use cases; just wire a switch to the OE pin on the clock mux, which is currently tied low (always enabled).

Given that 75MHz seems to work okay, I'll probably try and find a 5-position rotary switch, with 0, 20, 40, 60, and 75MHz positions. And then I could add a single step pin too; just run an edge detector off the master 125MHz sysclk, look for rising edges on that pin, and let a single cycle of the DOTCK through the clock mux whenever an edge is detected.

I'm compiling LOS at 75MHz right now to see how long it takes, and so far it's made it through all the apps (including the Desktop Manager) in a little over an hour. A significant improvement from the stock Lisa!

Alright, I think I'm ready to order the v2 boards! I made quite a few changes, and I've attached renderings of the new design. If you're not super familiar with the v1 board (and even if you are), it might be kind of tough to spot the changes visually, but trust me, there are quite a few of them! If you're curious exactly what they all are, go check one of my posts from a couple weeks back where I lay them all out.

The price for the minimum quantity of two fully-assembled boards is about $575, so not horrible, but then shipping (about $100) and tariffs (about $275) come in and raise the price to over $900, so it ends up being a lot. If anyone's still willing to donate anything to cover part of the cost, I would be very grateful! You can find me on PayPal at paypal.me/alexthecat123 if you're interested in contributing anything. Don't feel obligated to though; I wouldn't even be asking if people hadn't already expressed interest in giving some money in the past!

And following up from the previous post: the entirety of LOS (including LisaGuide and running PACKSEG to pack all the files for the installer disks) compiled in 3 hours and 10 minutes, which felt lightning fast to someone who's used to the stock Lisa's compile speeds.

Also, remember how I said that the Lisa would work with the Floppy Emu, but not real floppy drives? Well, I figured out why! My real floppy drive (which I thought was functional) was shorting 12V to the RDA (read data) line, and obviously the Lisa had no idea what to do with this. It's a miracle it didn't fry the electronics on the floppy drive, and even more impressively that it didn't kill the FPGA. 12V is muuuuch higher than the 3.3V limit that the FPGA's datasheet specifies!!! After fixing the floppy drive, real floppies now work perfectly fine!

The main things left to do at this point are:
- Get the serial ports working. I think the SCC is completely dead on the current PCB; some of the changes on the v2 board are really going to help with this!
- Improve floppy drive reliability and get external ProFiles working. Both of these problems can be mostly or entirely blamed on the v1 board's terrible level shifters.
- Upgrade the HDMI subsystem from 1080p30 to 1080p60. This may not be possible; the pixel clocks required for 1080p60 are higher than the maximum supported clock speeds of the OSERDES primitives inside the Artix 7 FPGA, so there's physically a hardware limitation preventing it from working quite right. Whenever I try it, the design obviously fails timing, but sometimes I'm actually able to get a stable image on the screen. It's really flaky though and will randomly start tearing the picture and glitching out the sound with weird clicks and pops, so we're truly pushing it up against its limits. I'll mess with it a bit more, but we might be stuck with 30FPS video. Hopefully people don't mind too much; it really bugs me, but it's likely the best we can reliably do!
- Fix a few reliability issues at higher clocks. MacWorks Plus sometimes randomly shuts down at higher clock speeds (60MHz and above), so we might still have intermittent COP problems of some kind that only show up there.
- Get Xenix working. Xenix will sometimes boot, but it's super picky about ProFile timings and fails ProFile handshakes so often that it frequently hangs. I've gotten to the login prompt once or twice though. And don't even think about running it higher than 20MHz; then the ProFile code completely breaks! My upgrade of the SD card slots from SPI to SDIO on the v2 boards will likely help with this too.
- Get UniPlus working. It always seems to initially boot just fine, but kernel panics right after it shows the "welcome" screen that displays your system's configuration. I'm hoping that this is because of the broken SCC, so I'm not going to worry too much until we get the SCC issues fixed and can try again.
- Get GEM working. I haven't tried booting it from hard disk, but at least when you boot it from floppy, it reads a bunch of tracks and then hangs. It never displays the fish icon or anything, so I guess it's failing pretty early.
- Figure out a better solution to the parity issue. I'm torn between implementing the full parity RAM using the FPGA's internal block RAM versus hard-coding the RAM board to only report bad parity when it detects the boot ROM (or LisaTest) performing the "write wrong parity" test. We'll see.
- Fix a problem with the USB to Lisa keyboard logic where it can only detect the Apple (alt) key when it's pressed in conjunction with another key.
- Get my ESP32-based floppy emulator working! But this is something I can worry about after I've released the LisaFPGA boards; even if I fail; the boards are still perfectly useful as-is.

I think that's it; let me know if there's anything I've promised or mentioned in the past that I'm forgetting. And if you're willing to donate to the PCB order, then thanks again; I really appreciate it!

Wow, I've gotten over $700 in donations since making my post last night. That's way more than I could've ever imagined; thank you so much to everyone who pitched in!

I just placed the order a couple hours ago, but I have some slightly unfortunate news about the timeline of things. Unbeknownst to me until I was about to place the order, JLC just closed down their 6-layer production line for the Chinese Spring Festival, and they won't even start fabricating my board until the 24th. So it probably won't be here until March 10th or so. If only I had placed my order two days earlier; if I had, then they would've put it into production now instead of waiting. But I just didn't know at the time. This is also a really big problem because I ordered a 6-layer board that I need for one of my classes at the same time, and I'm not going to be able to get my assignment done before the deadline if they wait that long!

Having to wait on the LisaFPGA boards is just an inconvenience, but the board I need for school is actually really important, so I paid extra for expedited manufaturing on both boards to get my school one here fast because their site said that it would go into production before the 24th if I did that. But then on my order history page, it ended up saying that it wouldn't go into production until the 24th again!

I reached out to their customer service (who are really good by the way) and it turns out that this was a bug in the site; you weren't supposed to be able to pay extra to get an order in before the holiday if you placed your order after the 2nd. Given that it was a bug on their end, they're going to try their best to honor what the site said and squeeze me in before the factory closes, but if not then they'll just refund me the expedited fee. So we might end up getting the LisaFPGA boards earlier than March, but it's all just going to depend on whether they're able to get me into production quickly.

If only it was a 2-layer or 4-layer board; those production lines are only closed from the 16th to the 19th and if I placed the order now, it would probably be done well before then anyway! But I don't even want to imagine having to design something around a super-dense FPGA with only 4 layers to work with...

Quote from: AlexTheCat123 on February 04, 2026, 05:30:43 PMHaving to wait on the LisaFPGA boards is just an inconvenience, but the board I need for school is actually really important, so I paid extra for expedited manufaturing on both boards to get my school one here fast because their site said that it would go into production before the 24th if I did that. But then on my order history page, it ended up saying that it wouldn't go into production until the 24th again!

Quote from: AlexTheCat123 on February 04, 2026, 05:30:43 PMI reached out to their customer service (who are really good by the way) and it turns out that this was a bug in the site; you weren't supposed to be able to pay extra to get an order in before the holiday if you placed your order after the 2nd. Given that it was a bug on their end, they're going to try their best to honor what the site said and squeeze me in before the factory closes, but if not then they'll just refund me the expedited fee. So we might end up getting the LisaFPGA boards earlier than March, but it's all just going to depend on whether they're able to get me into production quickly.

Fingers crossed that JLC's customer service comes through and gets you squeezed in before the holiday shutdown. That's a rough spot to be in with your school project deadline on the line. Hopefully the fact that it was a bug on their end works in your favor.

At least waiting on the LisaFPGA boards is just a patience test. Here's hoping good luck is on your side and the boards make it out before the factory closes.

Quote from: coffeemuse on February 04, 2026, 05:52:39 PMAt least waiting on the LisaFPGA boards is just a patience test. Here's hoping good luck is on your side and the boards make it out before the factory closes.

Thanks, let's sure hope so! And thank you for your very generous donation!

Quote from: AlexTheCat123 on February 05, 2026, 01:08:17 PMThanks, let's sure hope so! And thank you for your very generous donation!

No thanks needed — just happy to help clear a hurdle.

Thank you for giving this platform the second chance it deserves. This time, no landfills.

The boards look like they're done with manufacturing now, and are about to go into assembly. But they've been stuck on the "final inspection" stage of manufacturing for like 3 days now, whereas this normally only takes a couple hours, so I'm starting to get worried. I sure hope the inspection didn't fail. Then we'd have to wait ANOTHER week for them to remake the boards. And remember, the boards I need for school are caught up in this too!

Good news about the boards! They were stuck on that same production stage until yesterday, at which point they jumped all the way to fully completed. Not just fully completed as far as PCB fabrication is concerned, but fully completed in terms of both fabrication and assembly. Not sure why the tracker hadn't been updating for so long, but the boards have now shipped and should be here on Friday!

The boards arrived today, a day earlier than expected, and so far they seem to be working great!

I haven't tested all of the new board's features and fixes yet, but here's what I've done so far.
- Validated that the external ProFile port works now, unlike on the original board thanks to those weird bidirectional level shifter ICs. This means that my new MOSFET-based level shifter solution seems to work!
- Confirmed that the new +12V supply is good and that the speaker doesn't literally melt anymore (which it would do on the v1 board when you supplied -12V to the board but no +12V).
- Tested all of the stuff that worked on the previous board, and confirmed that it all still works as well as it did on that board, with the exception of the floppy drive port. But this is probably just because I was doing some weird experiments with the floppy drive on the old board and had remapped the pins so that they weren't even pointing to the port anymore!

I haven't been sitting idle while waiting for these boards to arrive; in fact, I've gotten lots of minor (and several major) problems solved over the past couple weeks. These include:
- Getting 60FPS HDMI video working. I've discovered that, while most devices will happily accept the 60FPS video stream, there are a select few (like my HDMI capture device) that don't like it and glitch out, so I've got it set up so that you can switch between 1080p30 and 1080p60 on the fly. Right now it's done with a wire shoved into the GPIO header, but I'll add a proper jumper on the v3 boards.
- Fixing some really annoying reliability issues with a variety of different parts of the Lisa that have been bothering me for months, mainly with the floppy controller, video circuitry, and RAM. The problem manifested as one or more of these systems (most often the floppy controller) randomly breaking when I would change some tiny thing about the design, even something completely unrelated to that part of the system. And I couldn't attach virtual logic analyzer probes to troubleshoot the problem because the very act of attaching the probes would fix it! This issue took me over a month to figure out, but I finally discovered that it was because I was clocking some things off signals that weren't proper clocks running on clock nets. Doing this is really bad because clock nets are special paths inside the FPGA that minimize clock skew, essentially ensuring that the clock arrives everywhere inside the chip at nearly the same time. But if you clock a bunch of stuff off a non-clock net and that signal propagates all across the chip, significant skew can be introduced and one thing will be clocked before another, leading to certain elements latching data too early or too late. And making tiny changes to the design would cause everything to be placed and routed on the chip differently, changing the skew on these non-clock nets that I was using to clock stuff. It seems so obvious in hindsight!
- Getting UniPlus to boot properly. It turns out that this was a problem with my handling of the PRES signal as it comes out of the 6522.
- Fixing the issue where my USB-to-Lisa keyboard logic couldn't detect a modifier key press (like the Alt/Apple key) unless it was accompanied by the press of a non-modifier key. This would mean that, if you wanted to have LOS shut down into the Environments Window, you'd have to hit Alt+Some Key and then let go, which would latch Alt's (Apple's) status as "on" internally, and then you would hit the power button. And to un-latch Alt, you'd have to do it again. This was just a dumb logic bug, but now all the modifier keys can be pressed and registered on their own.
- Implementing a solution to the parity problem. In case you don't remember, the FPGA-based Lisa doesn't have any parity RAM, so it would always fail the "write wrong parity" test in the boot ROM and LisaTest where the CPU board would intentionally force bad parity and try to read it back. I had patched this test out of the ROM for a while, but I went back and added a real solution now where, whenever the RAM board detects that the CPU is trying to do one of these tests, it latches the write address. Then, the next time it sees a read from that address, it sends the parity error (HDER) signal. It'll un-latch the write address whenever the CPU writes to that address again but with the write wrong parity test disabled. Granted, this only lets it remember the address of one parity test operation at a time, but it's good enough for the boot ROM. We'll find out if it's good enough for LisaTest when I get the floppy drive working again...
- Fixing an annoyance with the HDMI video output where my Lisa-to-HDMI framebuffer would start sampling 2 pixels too late on each line. This would cause 2 columns to be cut off on the left side of the image, and two black columns to be inserted on the right side of the image. The fix was as simple as adjusting my delay counters, which figure out how many DOTCKs to wait before reading pixels after the end of HSYNC at the start of a line, and how many DOTCKs to continue reading pixels for after the start of HSYNC at the end of a line. I had them both set to 11 before, but 9 is the correct value. Not sure if anybody had noticed this in any of my pictures, and it's honestly pretty minor, but it sure annoyed me a lot!

My next goal with the v2 boards is to get the floppy port working, and I've also thrown some code into the HDMI interface that should get the new "simulated scanline" jumper working at the same time. Then I need to fix whatever's preventing communications with the SCC, and that's really the last major thing left to do. But the SCC thing could prove to be a big task (I haven't looked into it yet whatsoever), so who knows how long that will take.

I've attached a picture of the new board, and here's a video showing it in action:
https://youtu.be/sAVDWAXoQMQ
 (https://youtu.be/sAVDWAXoQMQ)

Congratulations, Alex! Looking great! It's crazy how fast LOS boots up on that  ;D

Quote from: ried on March 12, 2026, 10:48:16 PMCongratulations, Alex! Looking great! It's crazy how fast LOS boots up on that  ;D

Having that extra speed is really awesome. It feels so terrible every time I switch back to a standard "slow" Lisa now!

Okay, so I just really want to get the SCC working (I've been dying to test out my built in USB-to-Serial B solution), and I've decided I'm going to do that first before getting the floppy controller working again.

So far the progress has been pretty good; I've confirmed that the Lisa can talk to the SCC perfectly fine. I also discovered that the reason why the SCC fails the boot ROM tests is simply because I'm overclocking the Lisa to 4x speed. The ROM tries to do a port loopback test on the SCC, and the 68K sits in a timeout loop waiting for the data that it sent to the SCC to be "received" back again. But given that it's running at 4x speed, the 68K times out 4x faster than it's supposed to, which doesn't give the SCC enough time to return the data! There's nothing we can really do on the SCC side of things to fix this, so I think I'll just have to patch the boot ROM to skip the loopback test. I've already done this on the H ROM anyway, so it's just a matter of doing it on the 3A ROM too.

But we still have the problem where trying to configure a serial port in LOS causes the entire system to hang. This is true both in LisaTerminal and in the Workshop's PortConfig utility. I can't say for sure yet, but current signs are pointing to the RSIR signal (the SCC's interrupt line) becoming permanently asserted the moment that LOS configures the SCC and enables its interrupt capability, causing LOS to constantly service SCC interrupts until the end of time. I'm guessing that I screwed up something in my PCB design such that one of the RS-232 signals going into the SCC is stuck in a bad state, and that's what's causing RSIR to be permanently asserted, but I'll need to do some more digging to find out for sure.

And by the way, my little scanline experiment worked great! The effect does hurt my eyes a bit, but maybe that's just because of how close I'm sitting to such a big monitor. It sure looks cool though, and I'll probably keep it on the final board, especially if I'm able to make it a little easier on the eyes. Clearly it's possible; the RGBtoHDMI pulls it off very nicely!

I need to do some more testing to be completely sure, but I think the serial ports are working now!

It turns out that the problem was a combination of PCB design issues and a bug in my CPU board logic.

I swear that something has to have been wrong with me when I was designing the Serial B section of the board; there were an insane number of mistakes that I found! First up, RX and TX were hooked up backwards. And not only that, but DTR and DSR were also hooked up backwards! There's also an LS157 mux on the board that's used to pick whether Serial B is controlled by the CP2102N USB to serial chip or the physical serial port, and I somehow managed to hook it up wrong too! I genuinely have no idea what could've been going through my mind, but I had signals that were supposed to be outputs from the mux connected to its inputs and vice versa.

With this absolute mess on my hands, I decided to just bodge the board into a hard-wired CP2102N configuration. It would've been a real pain to bodge the mux back into action, so I disabled the actual serial port and opted to just allow USB control over Serial B.

Sorting all of this out got me a bit further; the RSIR interrupt now wouldn't trigger until I tried to send or receive a character over serial. But the moment that it did trigger, the whole system would still lock up! After more investigation, I discovered the cause of the problem: the RSIR interrupt wasn't making it back to the CPU! It turns out that there was a bug in my priority encoder code on the CPU board that takes the Lisa's various interrupt sources and encodes them into the IPL[2:0] interrupt signal that the 68K uses. It was a typo that literally just affected the SCC interrupt and none of the others, which is why it went unnoticed until now. After fixing that, I could transmit and receive data over Serial B through the board's built-in USB to serial interface!

Then it was time to try Serial A. Serial A doesn't have an onboard USB interface like Serial B, so its logic on my PCB is simpler, and luckily I don't think I screwed any of it up because I plugged in a serial cable and it mostly worked on the first try!

I say mostly because I could receive data, but I couldn't transmit. Guess why? There's an LS245 on the PCB that allows the FPGA to directly drive all of the SCC's output pins, which I put there in the hopes that I can eventually integrate the SCC into the FPGA and thus not even need the real SCC at all. But obviously this LS245's outputs should be disabled when a real SCC is installed because otherwise there would be contention between the real SCC and the nonexistent FPGA SCC. Well, I was accidentally setting this output enable pin low in my code, and the 245's OE pin is active-low, so it was enabled and constantly competing with the real SCC to drive the bus! After turning this off and resynthesizing, Serial A worked great! This LS245 was also double-driving all of the Serial B outputs, so I guess the SCC was just strong enough to overpower it in all of the earlier tests, but not for Serial A for some reason.

It's honestly a miracle that the mux, MAX232s, CP2102N, and ESPECIALLY the SCC survived this torture; all of them had at least two (or eight in the case of the SCC) outputs that were being double-driven! Maybe this is why the SCC has been getting so hot that it burns me...

Excellent as usual to hear about this progress! It's interesting that Serial B is the one with the USB gubbins as this is the port you would use for LocalTalk if I'm not mistaken. Is there any relationship between those two things?

I chose Serial B since it seems to be the default port for a lot of things, including BLU, UniPlus, and all of my LOS compilation scripts. Maybe Xenix too; I'm not sure. And I figured that it would be nice to have the convenient USB hardware on the most frequently-used port. That was really the only factor I was taking into consideration!

And by the way, I've thoroughly tested the serial ports at this point (both USB on Serial B and a regular serial cable on Serial A) and they both seem to be rock-solid, including the flow control logic (which is very important if you're going to use my LOS transfer scripts)!

So now I'm moving back to the floppy disk controller issues. One problem I just discovered is that I had the drive select mapped wrong in my code for the new board. I had to reverse the drive select outputs in my code on the old board thanks to getting the drive select lines backwards on the PCB, but that has been fixed on the new one, and I forgot to switch them back around to normal again. Hopefully that's the only problem!

Not sure how I forgot to try this earlier, but now that the SCC is working, we absolutely have to see if MacWorks Plus II runs!

Sure enough, it works great! The one issue is that it only recognizes the PFG at boot if you have the DOTCK set to 20MHz; any higher than that and it thinks it's not there. This could very well just be an issue with my setup though; I'm using an ESP32-based PFG replica that I designed and my code may not like the faster clock. I can't find my original PFG right now, but there's a good chance it would be fine.

Given that MW+II only enforces the PFG's presence during those initial checks and not once Mac OS is booting, you can simply boot at 20MHz and then switch up to the full 75MHz after you see the Happy Mac and things will work fine. Sure, settings won't get saved to the PFG's memory properly at the higher clock speed, but everything else will work great and MW+II won't lock up on you.

Anyway, back to troubleshooting the floppy controller! Synthesis is almost done, so we'll soon find out if my drive select fix was enough to get it working!

Quote from: AlexTheCat123 on March 15, 2026, 07:57:32 PMSure enough, it works great

Since that's the case, it's obvious you'll eventually need to make a third version of the board for use as a drop-in replacement for a Macintosh Plus motherboard!

Quote from: Andrew on March 22, 2026, 05:10:48 PM

Quote from: AlexTheCat123 on March 15, 2026, 07:57:32 PMSure enough, it works great

Since that's the case, it's obvious you'll eventually need to make a third version of the board for use as a drop-in replacement for a Macintosh Plus motherboard!

That is a really neat idea. Coolest mini Lisa ever. I wonder if there's a way to get LOS working with the Mac 9" CRT?

It turns out that there was one other problem still left with the floppy controller, which was related to clock skew. My addressable latches that drive many of the floppy disk interface signals were being directly clocked off the divided-down 2MHz clock (which is a fabric signal, not a clock net) instead of the dedicated 16MHz I/O clock (with the 2MHz as an enable signal), which was introducing so much clock skew that things would occasionally not work. After fixing that issue by moving over to the 16MHz clock, the floppy controller seems rock-solid!

At this point, I'm trying to test things as thoroughly as possible to eliminate all the bugs that I can find, and I've discovered a couple over the past few days.

One is in LOS 2.0, where the Preferences Window refuses to display the Convenience Settings tab or the Connect Devices tab. Whenever you try to choose either tab, it pops up the "Lisa is having trouble displaying this window, do you want to try and redisplay it" error message. I'm saving this one for later though.

The other two issues occur in LisaTest 2.2. The first of these happens during the VIA test, where LisaTest reports an error code of 7 and a test step of 5. The issue is that nobody has any clue what these codes mean, so I decided to try and throw the VIA test binary into Claude to see if it could help me out. And boy, did it deliver! Go check out my thread on that for all the reverse-engineered info it spat out, but the quick summary is that the error 7 and test step 5 means that it was trying to test Timer 1 of the keyboard VIA and discovered that the timer was running too slow. It loads a value into the timer, tells it to start counting down, and waits for a timer interrupt. Meanwhile, the 68K is incrementing a counter that it's using to time how long it takes to receive the interrupt. Once the interrupt is received, it compares the counter value to an "acceptable" range and if it's within that range then the timer is functioning properly, whereas if it's outside that range then the timer is running too fast or too slow. It repeats this for 22 different timer values. And for timer value 000F, it fails and says that the timer is too slow. The expected counter value here is 2 (range is 1-3, exclusive), but we're getting a 3. I have literally no clue why our timer could be running too slow because the CPU and VIA clocks are scaled together even when the system is overclocked, so it just makes no sense at all. Given that it doesn't fail in LisaTest 3, I'm just going to assume that it's a bug in 2.2 and that the range should be bigger or the bounds should be inclusive or something.

The second LisaTest issue is in the CPU error logic test, which I also reverse-engineered with Claude. It reports an error code of 9 on test step 0x18, which apparently means that the "write wrong parity" test failed and triggered an NMI when it wasn't supposed to. That's to be expected since my parity implementation is only good enough to remember one wrong parity address at a time, whereas LisaTest tests thousands of addresses to confirm that the memory error address latch is working properly. So I patched this check out of LisaTest to make sure that it passes all of the subsequent ones, and guess what? It actually fails another one of them. The one it fails is the very last test, which intentionally triggers a bus error by writing to a nonexistent address and then reads the system status latch to confirm that the BUST (Bus Timeout) flag was properly set to indicate the error. But it's returning with an error code of 35 on test step 0x30, which means that the bus error occurred, but the BUST bit wasn't set in the latch. I'm resynthesizing with debug probes on the bus error circuitry right now; hopefully this will be an easy fix!

Hi, congratulations on the magnificent work done.

I think there's little more to add to the project.

However, if we need to expand the RAM due to parity requirements, we could consider adding 4MB of RAM with the LisaRambo card. This would allow us to enjoy 4MB on a Mac system and switch to 2MB for the Lisa system. But I understand that would complicate the project even further. I'm not sure if it would be possible.

In any case, we are interested in the project once it's completed, for a possible group purchase.

I've never heard of a LisaRambo card and Google and DuckDuckGo both just turn up a reality show contestant. What's a LisaRambo card?

Hahaha, you're not kidding; there are a few Lisa Rambos out there.

Thinking he's talking about the LRambo mod as seen here (https://lisalist2.com/index.php/topic,29.0.html).

Hi, as the colleague says, the LRambo card was a mod for a Sun Remarketing 2mb RAM card that supported the 4mb option for use only with the Mac system, not with Lisa OS.

This is a render of a 2MB SUN REMARKETING card. If you look in the center, there's a jumper to convert it to a 4MB card. A mod to the Lisa motherboard is necessary for it to work.

Good suggestion, but I probably won't add 4MB of RAM because of the extra cost of a second RAM chip. The boards are already rather pricey, and another chip just increases that price further. And plus, I think only a select few people would use 4MB to begin with. I'm guessing that most people who want an FPGA Lisa are probably going to be using it to run the unique LOS/Workshop/Xenix/UniPlus OSes as opposed to your generic Mac OS that can be run (and run better, no less) on any old Mac.

Sorry for the slower pace of updates lately! School has really picked up as we near the end of the semester, and I've had a lot less time to work on things than I did before. There's not a whole lot left to do at this point though; the main problems that come to mind are hard disk issues, and they might be ESProFile's fault.

I fixed one hard disk issue, where UniPlus would assert CRES midway through the boot process, which would obviously completely break communications with the ProFile. I had temporarily gotten around this by telling ESProFile to just ignore CRES, but I went in and fixed it for real a few days ago. It turns out that I was operating under the faulty assumption that the CRES pin from the VIA would always be set to an output, so I was ignoring the state of DDRB and just blindly piping the pin out to the CRES logic. But this doesn't work if the VIA sets CRES to an input and then puts a 0 in its output register; this will pull my CRES low even though it should actually be floating (which defaults to the desired state of high). So all I had to do was check the proper bit in DDRB. If the VIA's CRES pin is set to an output, then pass CRES on through, but if it's set to an input, then just force our CRES VIA output high.

This is really interesting because it means that UniPlus is setting the CRES output to an input for some reason. I wonder why?

The other two somewhat-major issues left to solve are also both ProFile-related.

One is that Xenix fails to boot with a bunch of ProFile handshake errors. On very, very rare occasions, it makes it to the login screen, but it's quite uncommon, and you're completely out of luck if you try it at anything higher than a 20MHz DOTCK. I'm thinking that this is an ESProFile issue more than it is a LisaFPGA issue though. Xenix works fine on the regular ESProFile, so perhaps it's some sort of subtle timing thing with porting it from a standard ESP32 to a slightly-faster ESP32-S3?

The second is that your very first attempt to boot from the onboard ESProFile at the 75MHz DOTCK will always result in an error 84, but then all subsequent attempts (until you hit ESProFile's reset button) will work fine. It's just that first attempt that's the problem, and only at the 75MHz DOTCK; all three lower speeds work fine. Looking at it with the logic analyzer, it seems that the problem is that ESProFile is sending its data bytes to the Lisa with a 1-byte delay, so it sends the Lisa status byte 3 when it expects data byte 0, data byte 0 when it expects data byte 1, and so on. I have no idea why this only happens on the first attempt and then never again, but it's clearly some kind of ESProFile issue!

QuoteXenix fails to boot with a bunch of ProFile handshake errors

Reminder that Xenix's ProFile support is known to be problematic and needs patching to work with faster parallel port drives, see:

http://sigmasevensystems.com/xpf_xenix.html (http://sigmasevensystems.com/xpf_xenix.html)

I don't doubt you've just encountered additional bugs .

QuoteI've never heard of a LisaRambo card and Google and DuckDuckGo both just turn up a reality show contestant. What's a LisaRambo card?

Paul Capes devised a modification for the 512K Apple Lisa Memory Board using larger DRAM chips, making it a 2MB board. When I uploaded his design to CompuServe ca. 1986 (the days of 8.3 filenames), the filename was LRamBo.

The relevant part of the upload is shown here:

https://lisalist2.com/index.php/topic,392.msg2916.html#msg2916 (https://lisalist2.com/index.php/topic,392.msg2916.html#msg2916)

The 4MB Modification referenced in the other replies came later. The initial implementation was using two LRamBo boards (hence the overlap in terminology), with a modification to support the AST RamStak boards coming shortly after.

The Sun Remarketing 2MB SIMM memory board was designed after that, and included the undocumented jumper to support the 4MB Modification.

The 4MB Modification does require modifications to the CPU Board, but not the motherboard. The LRamBo modification to make a 512K board into a 2M board doesn't require modifying any other boards.

Quote from: sigma7 on April 10, 2026, 07:31:57 PMWhen I uploaded his design to CompuServe ca. 1986 (the days of 8.3 filenames), the filename was LRamBo.

I love details like this. "Compuserve" is also an important clue, as at least at a certain point it only allowed 6.3 filenames (see PDF page 30 here (https://archive.computerhistory.org/resources/access/text/2024/06/102805861-05-01-acc.pdf)) owing to running TOPS-10 behind the scenes (https://medium.com/@mpnet/trying-to-make-sense-of-compuserve-server-hard-disk-images-posted-on-archive-org-b1c62ce6012b) (see also PDF page 243 here (https://www.bitsavers.org/pdf/dec/pdp10/TOPS10_softwareNotebooks/vol04/AA-0974G-TB_TOPS-10_Monitor_Calls_Manual_Volume_1_Oct88.pdf)). This would explain why it's LRamBo (six letters) and not LisaRamB or LRamBrd or something longer.

The only inconsistency is that the SIXBIT character encoding (https://en.wikipedia.org/wiki/Six-bit_character_code#DEC_SIXBIT_code) used for TOPS-10 filenames didn't have lower case characters, so I would have expected the file to be called LRAMBO instead?

QuoteI would have expected the file to be called LRAMBO instead?

That seems reasonable/likely.

IIRC, the upload contained three documents (Two pages of reverse engineered schematics of the 512K Memory Board, and one page for the modifications), so it was probably a .sit stuffit archive.

The documents were created on and uploaded from a Lisa running MacWorks XL, so the original files had long (guessing System 3.0, so up to 31 characters) mixed case names. I don't recall if the CompuServe upload process required pre-naming the upload or providing a (possibly different) name upon upload, but I don't see any uppercase "LRAMBO" file/folder/archive names here.

A brief look suggests the filenames in the archive were "MD2 Lisa RamBo Part 1", 2, 3, implying MacDraw 2 documents. The misaligned text in the pdf is a consequence of hastily converting the files to MacDraw II and then (I don't recall what steps) to create a pdf. Sometimes WYSInWYG.

IIRC, MacDraw 2 knew that it was running on a Lisa, and (assumed) that meant rectangular pixels, so would adjust the aspect ratio when drawing to the screen to compensate. However, it corrected in the wrong direction, so if one drew a circle for example, the circle would be about twice as tall as wide on the screen (but would print as a circle).

I finally got the idea to try a real ProFile (not sure why I didn't think of that before), and Xenix fails in the same way on there too, so it's looking like a LisaFPGA issue at this point. I wonder what's going on? Maybe another case of a ProFile control pin getting set to an input on the VIA and me making a bad assumption about it, just like on CRES? We'll have to find out!

The semester is finally starting to wrap up, so I'm finally able to get back to work on LisaFPGA again!

Luckily, I've already been able to fix the two bugs that I talked about in the last update, which were:

Quote from: AlexTheCat123 on April 10, 2026, 05:46:20 PMOne is that Xenix fails to boot with a bunch of ProFile handshake errors. On very, very rare occasions, it makes it to the login screen, but it's quite uncommon, and you're completely out of luck if you try it at anything higher than a 20MHz DOTCK. I'm thinking that this is an ESProFile issue more than it is a LisaFPGA issue though. Xenix works fine on the regular ESProFile, so perhaps it's some sort of subtle timing thing with porting it from a standard ESP32 to a slightly-faster ESP32-S3?

The second is that your very first attempt to boot from the onboard ESProFile at the 75MHz DOTCK will always result in an error 84, but then all subsequent attempts (until you hit ESProFile's reset button) will work fine. It's just that first attempt that's the problem, and only at the 75MHz DOTCK; all three lower speeds work fine. Looking at it with the logic analyzer, it seems that the problem is that ESProFile is sending its data bytes to the Lisa with a 1-byte delay, so it sends the Lisa status byte 3 when it expects data byte 0, data byte 0 when it expects data byte 1, and so on. I have no idea why this only happens on the first attempt and then never again, but it's clearly some kind of ESProFile issue!

The Xenix bug ended up being a problem with the 6522 VIA core that I was using. I didn't write the VIA myself, I stole it from the NanoMac project, and up until now I thought it was 100% accurate to the original. But I've discovered several bugs over the past few days, one of which was causing Xenix to fail.

The specific issue that Xenix was having was that it would sometimes ignore the state of the BSY line coming from ESProFile. ESProFile would have BSY low telling the Lisa to wait while it was busy reading/writing to the SD card, but Xenix would sometimes just pretend like it didn't notice and would proceed with sending strobe pulses and expecting the drive to be sending/receiving data in return. And the strange part is that it would only do this sometimes, like once every several hundred ProFile accesses.

After isolating (with some help from Claude) and disassembling the Xenix ProFile driver, I discovered that it operates in an interesting way. During the portions of the code where it's waiting for the drive to raise BSY, there are actually two things that will cause it to move forward with the ProFile transaction. The first is (obviously) the actual raising of BSY, but the other is a timeout on VIA timer 2, which was presumably meant as a watchdog so that the whole computer wouldn't lock up if the ProFile never responded. The odd thing though is that it seems like they never implemented the watchdog; there's seemingly no code that calls the ProFile driver (or within the driver) that actually sets and starts the timer. But I noticed that, despite this, it was still running, timing out, and causing us to proceed before BSY was raised. But why?

Well, it turns out that it was a bug in the VIA like I mentioned earlier! When timer 2 is in one-shot mode (which is the mode that it's in while Xenix is running), you're supposed to load it with a value once, and then it counts down to zero and generates an interrupt when it gets there. After hitting zero, it actually underflows back around to FFFF and keeps counting down again forever, but it only generates the interrupt the very first time it hits zero (hence one-shot mode). But there was a bug in my VIA where, when the timer is in one-shot mode, it actually generates interrupts EVERY TIME it hits zero, not just the first time, which means that an interrupt is generated periodically the entire time that the Lisa is on (although it's masked, so it's just a bit being set in the VIA's IFR, not a physical interrupt going to the 68K).

But since Xenix is constantly polling this bit in the IFR to use alongside BSY as an indicator that it should proceed with the ProFile transaction, these spurious interrupts can cause us to move ahead when we shouldn't if they're timed just right. Which explains why this would only happen sometimes; most of the time, timer 2 would hit 0 at an inconsequential time, but occasionally it would happen while we were waiting for the drive to raise BSY.

Adding one line of code to the VIA fixed the problem so that the timer only generates one interrupt, and now Xenix boots and runs great, including at the full 75MHz DOTCK!

I'm honestly shocked that this hadn't caused a problem in any other OS! I guess none of them use timer 2 in a way in which it's allowed to count without reloading after a timeout, or don't use it in one-shot mode.

Now onto the second issue: the ESProFile thing where it always sends data bytes with a 1-byte skew on the very first transaction after it comes out of reset, but then never again. This turned out to be a caching issue on the ESP32 side of things, nothing wrong with LisaFPGA itself. Basically, the code that handles the really time-sensitive reading of strobe pulses from the Lisa and the sending of data in response isn't loaded into the ESP's instruction cache until it's been executed for the first time, and it takes quite a while to get it loaded in there when it first gets called. In fact, it takes so long that the ESP misses a strobe pulse before the code is loaded in and executed when the Lisa is running at a 75MHz DOTCK, which is what causes all of the data bytes to be sent with a 1-byte skew. But then all subsequent accesses are fine because the code is already cached at that point.

The fix here is simple: add the IRAM_ATTR attribute to all of these time-sensitive sections of code to tell the linker to place them in fast instruction RAM (as opposed to slow flash) from the very start, so that they never have to be loaded from the flash to begin with. Now things work flawlessly!

And one other thing: I got GEM working! It has never worked up until this point, and I thought that there was actually something wrong with my FPGA implementation, but no. It turns out that GEM just doesn't like having 2MB of RAM to play with. Dropping down to 1MB causes it to work great, and it's insanely fast when you're overclocked to 75MHz!

Unfortunately, it's not all good news. There are still several (rather small) problems left that need to be solved, and I just discovered one more that's actually a regression from where we were before.

This newly-discovered problem has to do with BLU, and it's pretty strange. BLU boots from a floppy just fine, but fails to boot from a hard disk or properly read a hard disk from the Hard Disk submenu. It gets data back from the disk, but the data is all shifted out of place (for example, the drive name is "PPROFFILE" or something like that). Upon closer inspection, it seems as if, for every 4 strobe pulses that BLU tries to send to the drive, the VIA actually only outputs 3 of them, one really long one and 2 normal-length ones.

I've always thought that BLU has a really unique strobe pattern compared to other OS's, so maybe that had something to do with what was going on. I decided to disassemble that section of the code to find out, and BLU sure does do things in a unique (and really clever) way!

If you've ever looked at BLU's strobe pulses, you'll notice that it always sends them in really fast groups of 4, with longer gaps between the groups. And the groups themselves seem impossibly fast; even if you sent two instructions immediately after each other, they wouldn't be able to touch the VIA that fast.

Well, that's the trick that BLU is using: it's not actually multiple instructions! Most ProFile drivers just use a series of MOVE.B's to grab each ProFile byte from the VIAs sequentially, but BLU uses a single MOVEP.L to grab 4 bytes at once instead! MOVEP grabs alternate bytes from within a word, and stitches them together into the destination register, and it's intended to allow the 68K to interface with 8-bit peripherals like the VIA that you'd like to read from sequentially but are only hooked up to one half of the 16-bit bus. The .L part is important because it's making the 68K do a longword operation in which it reads 4 bytes (32 bits) from the VIA, returning the next 4 bytes of ProFile data. Each read from the VIA's input register automatically pulses the strobe, so the very execution of each of MOVEP's reads will fetch the next byte without any extraneous instructions having to do anything.

But this might sound like a problem; we're reading from 4 sequential addresses (really 8 addresses since it's a MOVEP that jumps 2 bytes ahead on each read) but want all of our reads to be targeted to one single input register in the VIA. Well this actually works out just fine thanks to the way that the I/O board is designed. The VIA is addressed by address lines 6 down to 3, meaning that each register happens to be mirrored exactly 8 times. So even though we're reading 8 different addresses, they all point to the input register!

That's really clever, but why are our strobe pulses getting messed up? Well, that's the part that I haven't fully figured out yet, but it seems like we're somehow flying through each of the individual reads within the MOVEP too quickly. The VIA needs two clock cycles on the E clock in order to pulse its strobe, one to lower it and another to raise it, but for whatever reason the CPU is going so fast that it's already requesting the next data on that second clock pulse instead of leaving the VIA alone to let it raise the strobe, meaning that the strobe never gets raised for that particular address. I have no clue why the CPU isn't respecting this timing that is clearly respected on a real Lisa (and in some of my older builds), but it probably has something to do with VPA and/or VMA being generated at the wrong times (which could lead back to IOCY or CPUC1 on the CPU board), or perhaps me generating the E clock strobes at the wrong times.

My next step is going to be to pull one of my old working designs from a couple months ago off GitHub (apparently this has been broken for several months and I just haven't noticed) and build both the working and broken designs side by side to compare their logic analyzer traces. Hopefully something obvious shows up!

Thanks for another fascinating and detailed dispatch, and good luck chasing down these last few bugs!

I figured it out! It was indeed a problem with VMA/VPA not being asserted at the right time relative to the INTIO signal, and it ended up being because the CPU board clock counter that generates the CPU board's 8 timing states wasn't synced properly with the CPU.

I have a 2-step reset system where the T-state counter is pulled out of reset before the CPU is since that counter has to be running before the CPU is, but the T counter has to come out of reset exactly 5 cycles before the CPU to ensure that the T states are properly synced with the 68K's internal timing states. And I used to do it that way, but at one point a couple months ago I increased the reset period for the CPU from a few milliseconds to a full second-ish like the original Lisa to fix some COP issues, but failed to increase the counter reset accordingly to be exactly 5 cycles ahead. So making that adjustment was enough to fix it!

Now I'm going to mess around with MacWorks Plus a bit, and see if I can figure out why it just immediately shuts down whenever you run it at a DOTCK speed higher than the Lisa's stock 20MHz. I guess it's not the end of the world if I can't figure it out since it does work at stock speeds, but it would be nice to have a solution. Basically, right after you get the boot beep and the blinking question mark, the screen will immediately fade to black and the COP turns the Lisa off, so I'm guessing it's some kind of COP communications issue at higher speeds.

I figured out the MacWorks Plus issue, and now it can run at the full 75MHz DOTCK! Although it does require a small patch to your MacWorks Plus disk. It turns out that it was indeed a COP issue like I had guessed. MWP sends the COP a 0x02 (read clock) command once every second or so, meaning that even when the Lisa isn't "doing anything" and you aren't moving the keyboard/mouse, it's still going to be talking to the COP. The COP is supposed to respond to the 0x02 command first with an 0x80, followed by an 0xEy where y is the 4-bit year code (this is why the Lisa can only store years from 1980-1995), and then followed by several more bytes for the day, hour, minute, second, and tenth of a second.

But the MWP COP-reading code is really weird; it waits for the 0x80, and then expects all of the subsequent bytes to come quite quickly, enforcing a pretty strict timeout. And for whatever reason, if the next byte is an 0x00, MacWorks not only aborts the COP read operation, but also jumps to its "dim the screen and power-off" routine. I have no clue whatsoever why a 0x00 response from the COP would be grounds for doing something as drastic as turning off the whole computer, but that's what they chose to do. This explains why the Lisa always turns off at the higher clock speeds; it's just always reading a 0 from the COP on those subsequent bytes after the 0x80. But why?

Well, it's because of that timeout period I mentioned earlier. When the Lisa is overclocked, the 68K is running at 4x-ish its standard speed, but the COP is still at normal speed, so the COP effectively has 4x less time to get the data out to the 68K. This is just too fast for the poor COP to handle (it doesn't assert it's DATA_QUEUED signal in time), so the 68K always times out and MacWorks just gets a 0x00, which is the default value that the register that's supposed to contain the COP response is cleared out with. This situation is supposed to be protected against with a timeout flag that MacWorks sets in the 68K's condition code register, so that the caller of the COP routine can differentiate between reading an actual 0 from the COP (which is grounds for a power-off) as opposed to a timeout that just returns 0 incidentally (which isn't grounds for a power-off). But whoever wrote the flag-setting code clearly wasn't thinking straight. They set the flag in the CCR in the event of a timeout, but then on LITERALLY THE NEXT INSTRUCTION they pop the old contents of the CCR off the stack and overwrite the CCR with it before returning to the caller. So if the flag was set, it just gets clobbered every time. No idea how they missed that!

There are two possible fixes here. One is to prevent the CCR from getting overwritten, but I didn't go that route because there's still no guarantee that the rest of MacWorks would handle the flag correctly given that it never showed up in normal operation. The second was to simply increase the timeout period, which was set to 0x108 and then was decremented to 0 in a DBRA loop. I just upped it to some huge number (luckily, the loading of the counter was a MOVE.L, not a MOVE.W, so there was space in the binary to make it really big) and then it worked at the fully 75MHz DOTCK speed!

I also discovered a problem where the Lisa would refuse to work with a real 800K floppy drive, giving an error 57 whenever the drive was plugged in. It turns out that this problem was just me being stupid; I thought I was running the dual 400K/800K I/O board ROM but I was actually just running the plain old 400K version. Switching to the dual version fixed it right up!

After this, I went through and did a big test sweep through all of the Lisa OS's at all of the different clock speeds, and discovered another BLU problem: it fails its self-check when running with a 60MHz or 75MHz DOTCK. It passes the self-check fine when booting from floppy at these speeds, but not from the ProFile; I think I've just hit the limits of what ESProFile (and real ProFiles, for that matter) can keep up with, and we'll just have to accept that. If you really care about the full 75MHz speed when running BLU, just boot from floppy (or boot from the hard disk at 40MHz or less and then switch up to 75 after it's booted) and you'll be fine.

Another thing: I've been having this really weird issue with LOS 2 where it refuses to display Preferences with a "The Lisa is having technical difficulties..." error, and I've been working on it on-and-off for quite a while, not really making any progress at all. Then today I had the brilliant idea to try the disk image on a real Lisa, and guess what? It had the same problem! It turns out that this whole time, it was just a corrupt disk image, and somehow I hadn't considered that as a potential cause until today. Whoops...

Things are seriously quite close to done at this point. I've had a problem where each time I think I'm about done, I think of several more things that I need to mess around with, but this time I think the RTL/FPGA side of things truly might be finished.

The things that are still left to do at this point, in order from most to least annoying, are:
- Make all of the necessary PCB changes for the Rev. 3 board. There are quite a few of these, and most of them aren't too bad, but some of them like redoing all of the SCC stuff that I completely screwed up aren't going to be fun.
- Write a readme for the GitHub repo that explains everything you need to know about building one of these things.
- Make some kind of automated build/flashing script for as many of the board's components as possible. Right now, you have to manually flash the FT232, FPGA, CP2102 (sort of), and ESP32 one by one, and the FPGA requires programming the chip inside the Vivado GUI. I haven't been using the command line based build system since it makes it annoying to have to switch between the GUI and CLI to view reports and logic analyzer traces, but I think we're at a point now where we can do that; having a script that you can run and have it program all three chips with pre-built firmware files for you would be awesome. And then a second script that builds the actual Vivado project for people who actually want to mess with the code, but you definitely don't want to run that one each time you want to program the chip because it takes over an hour!
- Test the board with Twiggy drives. I might have a pair of Twiggies in my possession in a few weeks for an unrelated reason, so this might not be as unachievable of a task as I previously thought it was. They aren't permanently mine or anything, but I'll very likely have them for long enough to fix any LisaFPGA Twiggy issues that crop up.
- Test a real 400K floppy drive. As I mentioned earlier, I've tested an 800K and it works fine after my ROM fix, but I can't test a 400K at the moment because my 400K drive cable is currently inside a pinball machine in another building at the university that I don't have access to right now. Hopefully I can get it back soon!

One other thing to try and mess with is the onboard ESP32-based floppy emulator. I wrote all of the code for it back in November I think, but I haven't tested the code a single time because I wanted to get the rest of the board running and released publicly before worrying about that.

Assuming the PCBs are here in time for VCF Southwest at the end of the month, I was thinking about getting a loan from my parents and potentially ordering a decent-sized run to sell to people who come to the show. I know there there are some people there who would really love to get their hands on one, but I'm a bit nervous about doing this because if the market isn't as big as whatever I predict, then I'm stuck with a bunch of boards. To judge interest on this, is anybody going to be at VCF Southwest who might want one?

I certainly want one but will be nowhere near VCF SW. Consider explaining the situation and asking on 68kmla/TinkerDifferent/VCFed? A link to this thread would help folks who want to know more or who want to confirm that the project is real.

Wow! Amazing work, Alex! Thanks for the update.

Quote from: AlexTheCat123 on May 01, 2026, 08:11:15 PMAssuming the PCBs are here in time for VCF Southwest at the end of the month, I was thinking about getting a loan from my parents and potentially ordering a decent-sized run to sell to people who come to the show. I know there there are some people there who would really love to get their hands on one, but I'm a bit nervous about doing this because if the market isn't as big as whatever I predict, then I'm stuck with a bunch of boards. To judge interest on this, is anybody going to be at VCF Southwest who might want one?

Count me in for one whether that's a bulk run now or further down the road. If the boards arrive in time for VCF, I'd love to pick one up in person and catch your presentation on Saturday. If they don't make it from China in time, no worries at all; I'm happy to pay for shipping whenever they're available.

My current plan is to drive up Friday and head back Saturday evening, but the timing is flexible.

Already preparing on my end: Workshop 3.0 manuals, original M0100 mouse, and a tube of Zilog SCCs in case the external SCC route is the way to go.

(https://s3.us-central-1.wasabisys.com/my-public-share/LisaPrep.jpg)

Quote from: AlexTheCat123 on May 01, 2026, 08:11:15 PMI figured out the MacWorks Plus issue ... it does require a small patch to your MacWorks Plus disk.
...
They set the flag in the CCR in the event of a timeout, but then on LITERALLY THE NEXT INSTRUCTION they pop the old contents of the CCR off the stack and overwrite the CCR with it before returning to the caller.

In what version/range of MW+ did you find this bug?

Quoteanother BLU problem: it fails its self-check when running with a 60MHz or 75MHz DOTCK. It passes the self-check fine when booting from floppy at these speeds, but not from the ProFile

This brings up the issue that some code might want (or need) to know that it is running on your FPGA design and at what speed (and any other options). If you can add some kind of info register in the CPU board address space to expose that sort of thing it would be more reliable than the code trying to decide for itself.

Quote from: AlexTheCat123 on May 01, 2026, 08:11:15 PMI figured out the MacWorks Plus issue

By the sound of your report, your FPGA design has some kind of logic analyzer or code trace feature... if there is a way to make that available to others, it could be a tremendous benefit to anyone working on Lisa code!

Quote from: stepleton on May 02, 2026, 04:21:24 AMConsider explaining the situation and asking on 68kmla/TinkerDifferent/VCFed? A link to this thread would help folks who want to know more or who want to confirm that the project is real.

Good idea, I think I'll do that! And maybe I'll make a YT video going over its capabilities so that people know what they're getting into.

Quote from: coffeemuse on May 02, 2026, 08:01:56 AMAlready preparing on my end: Workshop 3.0 manuals, original M0100 mouse, and a tube of Zilog SCCs in case the external SCC route is the way to go.

Haha, you're all ready to go! I hope to see you at the presentation, and hopefully the boards will be here in time (assuming there's enough demand)!

Quote from: sigma7 on May 02, 2026, 01:08:10 PMIn what version/range of MW+ did you find this bug?

Whoops, I completely forgot to mention that in my last post. I found it in 1.0.18, but it's probably in other versions as well. Notably, it's NOT in MacWorks XL or MW+II. Search for 007C 0300 207C 00FC DD81 243C 0000 0108 and replace the timeout value of 0000 0108 with something big; I just arbitrarily chose 0000 7000 for some reason.

Quote from: sigma7 on May 02, 2026, 01:08:10 PMThis brings up the issue that some code might want (or need) to know that it is running on your FPGA design and at what speed (and any other options). If you can add some kind of info register in the CPU board address space to expose that sort of thing it would be more reliable than the code trying to decide for itself.

Wow, that's a good idea! I think I might just extend the system status latch (the thing that holds the states of INVID, CSYNC, VID, BUST, BTIR, HDER, and SFER) to be 16 bits instead of 8 bits, and put some magic number in there (along with maybe the current DOTCK speed and some other stuff) that identifies the board as an FPGA and not a real Lisa. That's a really easy change to make.

Quote from: sigma7 on May 02, 2026, 02:09:13 PMBy the sound of your report, your FPGA design has some kind of logic analyzer or code trace feature... if there is a way to make that available to others, it could be a tremendous benefit to anyone working on Lisa code!

Yeah, it's incredibly useful, and it's built right in to the Xilinx toolchain. You just mark signals for debugging to keep them from getting optimized away and rebuild your design. Then you can add a logic analyzer core within the FPGA that uses the FPGA's internal block RAM as its sample memory and sends data back to Vivado over JTAG. Once you program the board, you configure your trigger settings and can start capturing data in Vivado! The only catch is that there's not a whole lot of sample memory to play with since it's just running off the FPGA's block RAM, but it hasn't really been much of a problem for me except for when I'm trying to probe really slow stuff like the ProFile interface and the COP's sync signal.

Wow, I uploaded a public YouTube video about this project to my channel last night, and it's gotten about 8,000 views overnight! Most of the reception has been positive (other than a couple guys complaining about the board being ugly and saying that I need to talk to a pro PCB designer and also a few people complaining about my horrible camerawork) and a lot of people have said that they want to buy one. I'm honestly shocked at how much attention it's getting!

https://youtu.be/8jNQDcpHc68 (https://youtu.be/8jNQDcpHc68)

QuoteI uploaded a public YouTube video about this project

Very nice! Congratulations on your continued progress on this ambitious project. You've certainly demonstrated a lot of determination and dedication, not to mention development of some serious troubleshooting finesse.

Thank you James!

I'm blown away by your work on this, Alex.  In terms of unit sales, have you considered working with an existing vendor?  Might help to reduce headaches and hassles.

Thank you! I haven't really considered it up until today. But then one vendor reached out to me a couple hours ago wanting to list some boards on their site. I'm in the middle of final exams right now, but I'm thinking about it and I'll get back to them once I'm done!

Count me in for a board as well.

Spectacular work, Alex! Your knowledge of the platform is incredible. I'm interested in a motherboard. Best regards and congratulations.

Thank you!

Quote from: AlexTheCat123 on May 03, 2026, 12:41:17 PMWow, I uploaded a public YouTube video about this project to my channel last night, and it's gotten about 8,000 views overnight! Most of the reception has been positive (other than a couple guys complaining about the board being ugly and saying that I need to talk to a pro PCB designer and also a few people complaining about my horrible camerawork) and a lot of people have said that they want to buy one. I'm honestly shocked at how much attention it's getting!

https://youtu.be/8jNQDcpHc68 (https://youtu.be/8jNQDcpHc68)

This video is undoubtedly fantastic, and it has already garnered over 20,000 views! That's incredible!

Please disregard the criticisms. For someone who is solely pursuing this as a hobby and a passion for the Lisa, it's an impressive achievement to have successfully created a working Lisa inside an FPGA. I'm quite certain that none of those critics have developed a superior working Apple Lisa-compatible computer, let alone one in less than a year.

I remain in awe of your accomplishment and skills.

Quote from: coffeemuse on May 04, 2026, 06:49:39 PMPlease disregard the criticisms. For someone who is solely pursuing this as a hobby and a passion for the Lisa, it's an impressive achievement to have successfully created a working Lisa inside an FPGA. I'm quite certain that none of those critics have developed a superior working Apple Lisa-compatible computer, let alone one in less than a year.

That's a fair point. I'm a bit of a perfectionist, so I see every bit of their criticism as some genuine thing that I need to improve. But I'm trying to ignore that and focus on all of the positive ones.

Speaking of positive comments, someone named Chris Espinosa commented on the video claiming to be the project manager for MacWorks XL and the square pixels mod. I wonder if it's actually him? That would be amazing!!!

Quote from: AlexTheCat123 on May 05, 2026, 02:09:54 AMChris Espinosa...

That would be Apple employee number 8. Wow!

https://en.wikipedia.org/wiki/Chris_Espinosa

Thanks to a VERY generous loan from my dad, I just placed an order for 50 fully-assembled boards (as well as 10 completely-untested Twiggy breakouts), and I'm planning on bringing them to VCF Southwest to sell. I'm in talks with two well-known distributers in the vintage computing scene, and any boards that don't sell by the end of the weekend at VCF will go to them to be listed on their web stores. Not sure how quickly 50 boards will sell out, but I'm planning on doing more orders in the future once they're gone. I wanted to get more than 50 to start, but JLCPCB only had 54 FPGAs in stock, so the max I could do without having any leftover bare boards was 50.

And of course, if you don't want to buy one from me or them, you can always order some of your own straight from JLC once I put everything on GitHub!

They will sell out quickly.

Hopefully not too quickly!

Did I miss where the price was posted?

JLC just finished manufacturing the boards, so they should be shipped out pretty soon. Hopefully they'll be here by VCF; it's going to be really close!

I just added a neat feature that very few people will probably ever have a use for, but it comes in handy for me sometimes with LOS experimentation, as well as with Xenix's hard drive size limits. If you connect one of the pins on the GPIO header to 3.3V, then the FPGA will intercept any reads to address FCC030 and always return 88 instead of A8, making software think that it's running on a 2/10 instead of a 2/5. Pretty neat, right?

Quote from: bmwcyclist on May 12, 2026, 12:55:58 PMDid I miss where the price was posted?

Sorry, I completely forgot to respond to you! It's looking like about $300. I really wanted it to be cheaper, but the prices of chips have gone up quite significantly since my last order. Take the FPGA for instance. When I placed my first order back in November, it was $20 apiece, but now it's like $50. And many of the other chips have increased by similar proportions too. It sucks!

Quote from: AlexTheCat123 on May 18, 2026, 04:51:39 PMJLC just finished manufacturing the boards, so they should be shipped out pretty soon. Hopefully they'll be here by VCF; it's going to be really close!

I just added a neat feature that very few people will probably ever have a use for, but it comes in handy for me sometimes with LOS experimentation, as well as with Xenix's hard drive size limits. If you connect one of the pins on the GPIO header to 3.3V, then the FPGA will intercept any reads to address FCC030 and always return 88 instead of A8, making software think that it's running on a 2/10 instead of a 2/5. Pretty neat, right?

Sorry, I completely forgot to respond to you! It's looking like about $300. I really wanted it to be cheaper, but the prices of chips have gone up quite significantly since my last order. Take the FPGA for instance. When I placed my first order back in November, it was $20 apiece, but now it's like $50. And many of the other chips have increased by similar proportions too. It sucks!

Will there be any available for shipment to folks who are not planning to attend VCF?

Yep, I'm working with MacEffects and Joe's Computer Museum, and whatever doesn't sell at VCF will be split 50/50 between them for sale on their sites! Once those sell out, I'm planning on doing another batch too.

Some bad news.

JLC finished manufacturing the v3 boards on the 18th as expected, but it's been several days and they still haven't shipped. Normally they ship the day after manufacturing is done, but not this time, presumably because of the large size of the order. It's so late at this point that there's no way they'll be here in time for VCF. So if you were coming in the hopes of getting your hands on a board, then I'm sorry! They'll still be for sale online afterwards though.

Regardless, I'll absolutely have the two v2 boards set up at VCF for anyone to play with, so at least there's that, plus my presentation on the entire project.

VCF went great and my presentation is up on YouTube now! I honestly don't feel like it's quite up to the standards of some of my previous years because of how much content I had to trim to fit it within the hour and a half that I had, but the lecture hall was completely full and everyone said they really liked it, so maybe I'm just being overly critical.

Regardless, here's the link:

https://www.youtube.com/watch?v=2QSP9Qh0PvU (https://www.youtube.com/watch?v=2QSP9Qh0PvU)

It was great! thank you!

I'm finally home to mess with the v3 boards and I've got the first one of the 50 fully configured and tested. It looks like it works perfectly, including the serial port muxing, so that's an excellent sign. Now I just need to repeat everything for the other 49 boards, which is going to take quite a while.

The only roadblock I've encountered so far is that my eBay SCCs might indeed be fake and defective. I've only tested one of them so far, but it's so broken that the Lisa refuses to even display an image on the screen with it installed. Switching to a real SCC fixes things. Luckily, I bought some extra SCCs, so hopefully enough of them work to get through all of the boards...

While I was at VCF, I made a form that people could fill out to be notified when the boards go on sale. If anyone on here wants to be notified, I'd suggest filling out that same form too. Given all of the support that I've gotten on here, you guys get priority and will be notified a bit earlier than all of the VCF people if you fill out the form. To indicate that you're coming from here instead of VCF or any other source, put your name followed by "LisaList2" in the First Name field. So my first name would be "Alex LisaList2".

https://forms.gle/i4vdADcm5yNm8XUk7

I'll keep everyone updated as testing progresses!

Will keep following on with interest and will buy one of your boards at some point soon. I'm in Australia so hopefully there will be economical shipping options somehow.

Still blown away by the depth of functionality you have added into this project, truly amazing!

And takes me back to 1983 when I spent a lot of time on the Lisa as a 15yr old kid, including demonstrating it at a major computer exhibition in Melbourne, Australia.

Hi Alex, just one question: once you submit the form, do you receive a confirmation email?

Greetings from Spain

No, I don't think it'll send you a confirmation email.

Quote from: AlexTheCat123 on June 06, 2026, 02:43:43 PMI'm finally home to mess with the v3 boards and I've got the first one of the 50 fully configured and tested. It looks like it works perfectly, including the serial port muxing, so that's an excellent sign. Now I just need to repeat everything for the other 49 boards, which is going to take quite a while.

The only roadblock I've encountered so far is that my eBay SCCs might indeed be fake and defective. I've only tested one of them so far, but it's so broken that the Lisa refuses to even display an image on the screen with it installed. Switching to a real SCC fixes things. Luckily, I bought some extra SCCs, so hopefully enough of them work to get through all of the boards...

While I was at VCF, I made a form that people could fill out to be notified when the boards go on sale. If anyone on here wants to be notified, I'd suggest filling out that same form too. Given all of the support that I've gotten on here, you guys get priority and will be notified a bit earlier than all of the VCF people if you fill out the form. To indicate that you're coming from here instead of VCF or any other source, put your name followed by "LisaList2" in the First Name field. So my first name would be "Alex LisaList2".

https://forms.gle/i4vdADcm5yNm8XUk7

I'll keep everyone updated as testing progresses!

Hey, Alex. I was at VCF and filled out the form while at VCFSW (scanned the QR you had posted), but, obviously, also a LisaList2 member. Did you want me to resubmit with the "LisaList2" suffix for my first name?

Yeah, maybe resubmit just so I don't miss you!

So very excited by this thanks so much for this wonderful project!

Time for an update on my progress with the boards!

Testing them has been a slow and tedious process combined with all the other stuff that I have to do, but I've confirmed that 46 of the 50 are functional. The other 4 are broken, and all the problems seem to be traced back to shorts in the soldering underneath the FPGA's BGA. I'm talking with JLC right now to arrange a solution (probably refund, rework, or remanufacturing) for those; I don't have the skill to solder BGAs myself!

Out of the other 46, I was only able to get 24 of them fully working because only 24 of the 50 SCCs that I ordered were real. The other 26 were fakes that were completely inert, partially worked but crashed the system sometimes, or were so fake that they prevented the system from even displaying an image on the screen. The seller is going to refund me for the defective ones, but I can't take the risk of ordering more and having them be fakes again, and that also sets the timeline for the boards back by at least another month. So I decided to finally bite the bullet and try to implement the SCC inside the FPGA. I planned ahead and the board already has facilities for disabling the real SCC and putting the FPGA into its place, so it was "simply" a matter of writing the SCC core.

But luckily, I didn't even have to do that! It turns out that a LisaList2 member has been working on an SCC core, and he very kindly PM'ed it to me a couple days ago. The first version I tried had a few bugs, but the version I'm on now seems rock-solid in everything that I've tried so far. So hopefully I'll have a fully tested and working solution here in a few days, and then I can remove the physical SCCs from all the boards and reprogram all 46 of them with the new bitstream. Thank you to the creator of the core once again!

At that point, it shouldn't be too long before I have them shipped out to MacEffects and JCM for resale to anybody who wants one! I'll probably make the GitHub repo public at around this same time, because that's when everything should be finalized for the initial release. The final quantity that'll go on sale is looking to be 41 right now, because I'm keeping two for myself and giving three more to three friends who have been very supportive of me and the entire project from the very beginning, before anyone else even knew about it. Future batches will have the full quantity on sale though!

Thanks for the update! I've been checking the forum regularly out of excitement and this was very welcome. Any chance of an early heads up before it gets posted? I know I signed up in the form but wasn't sure how it was all going to work.

Thanks for the update, you're making impressive progress!

QuoteIt turns out that a LisaList2 member has been working on an SCC core, and he very kindly PM'ed it to me a couple days ago.

That's a very impressive job in itself! If there is an easy way to increase the size of the receive buffer FIFO, that might make a big difference for higher speed transfers.

Quote from: Edge Connector on June 19, 2026, 10:45:51 AMThanks for the update! I've been checking the forum regularly out of excitement and this was very welcome. Any chance of an early heads up before it gets posted? I know I signed up in the form but wasn't sure how it was all going to work.

Yeah, if you put "LisaList2" in your name when filling out the form, you'll get notified early and be able to order before the general public is able to order them!

Alright, the "early access" list is going to close at 5:00PM EST today, so make sure to get your name in there followed by "LisaList2" before that deadline if you want an early notification when the boards go on sale!

I'm downloading the list now, so no more early access signups at this point! Feel free to continue filling out the list if you just want to be notified when they go on sale to the general public though.

I'm looking forward to getting one of these boards. This will be much more convenient than hauling out one of my actual Lisa's and finding one of my working keyboards. It's unbelievable you've been able to do this. I got my first Lisa in 1990 or 1991 and this is just as exciting as that experience. Any idea when the sellers will start contacting those who signed up?

If you're on the early access list (LisaList2 in your first or last name when filling out the form), then you should've already gotten an email! Otherwise, it'll be once MacEffects and JCM actually have the boards on-hand and ready to go live.

Thanks for the reply. I'm looking forward to trying it out with one of my Twiggy drives or a pair of them.

Quote from: slewis1962 on June 23, 2026, 03:19:15 PMThanks for the reply. I'm looking forward to trying it out with one of my Twiggy drives or a pair of them.

I'm curious to see how it goes. I still haven't been able to test with Twiggies yet (although I hope to soon when I borrow a Lisa 1), so it's completely up in the air as to whether it'll work or not!

Just paid for my FPGA board and Twiggy adapter. Anything I need to know about attaching the twiggy drives to test them out?

Not really, the readme in the GitHub repo (which I'll make public once I finish up two more minor things) will tell you everything you need to know.

Just be sure to power the board off a dedicated USB-C charger as opposed to a computer's USB-C port. A computer's port is more than adequate if you don't have a floppy drive connected or if you have an 800K drive, but 400K drives (and presumably Twiggies) require a good bit more power and will brownout the board if you're not powering it from a dedicated charger that can supply the necessary current. This is also mentioned in the readme in case you forget!

I submitted my name early on, but did not see this post about the LisaList2 addon.

My browser stopped liking this forum again.

Loaded Firefox and it is working for now.

My order has been placed!

Hey guys, I have some somewhat unfortunate news about the LisaFPGA boards.

The process of getting the 50 boards that I ordered ready to be shipped out and sold has been absolutely horrible so far. I've been spending at least 6 hours per day on this for nearly the past month now because of defective/marginal boards and chips, and I'm getting pretty burned out over the entire project because of it. It's taken what was once a fun project that I looked forward to working on every day and has started turning it into something that's really stressful and not fun in the slightest. Before this, I was looking forward to designing the Rev. 4 board, the Lisa motherboard replacement version, and the floppy emulator, but after this experience with the 50 PCBs, it feels like something that I have to do instead of something that I want to do.

JLCPCB has agreed to repair the bad BGA soldering on the 4 defective boards (but a 5th one went bad after more testing and will be a total loss), but everyone I've talked to says that it's very unlikely that they'll cover shipping or tariffs when I return the boards to them. So there's a good chance that repair will cost a lot, and perhaps more than the boards are even worth, making it better to just take a loss on the boards than to send them back to be fixed.

And in addition to the 5 fully-defective boards, there are several boards that have marginal and seemingly out-of-spec SRAM chips that I'm having to modify my design around in order to get things to work properly on all of the boards that I have. Which has been really difficult because it has required me to do a lot of optimizations to the design to maximize speed.

Not to mention the whole debacle involving the fake SCCs that required integrating a SystemVerilog SCC into the design, which exacerbated the speed-related issues because the extra logic makes it even harder to make communications with the marginal chips work.

I hate to do this, but because of both the absurd amount of time that I've had to put into getting these 50 boards going and the lost money on the defective boards, I feel like I have to raise the price on the remaining boards to $350, and even that doesn't really make it feel like it's worth my while. The small amount of profit that I'll make off these is already worth far less than the amount of time that I've had to put into them, and the lost money from the dead ones just makes this even more true. If I could go back a month or two, I don't think I would've even chosen to sell them at all.

Anyone who has already preordered and paid won't be affected because I would feel bad to charge you even more after you already paid, but this will go into effect for any future orders starting now.

I'm really sorry about this, but I just don't feel like there's any way around it. I hope you understand; I know that some people are already upset about the $300 asking price. And this price may be subject to change for future batches (if I even feel like doing them at all after this) depending on how many defective boards there are and how much of my time it takes, especially after school starts back up and I have less time to spend on them to begin with.

Hey Alex,

Sorry to hear about the challenges you are facing with this. I'm sure the whole experience will be a valuable lesson for you in the future so it hopefully won't be a total loss in the long term. Probably hard to see that right now I'm sure though.

I've placed my order but am happy to wait until you are comfortable with the quality. And I'm in Australia so wouldn't want you or I to deal with trying to fix stuff after shipping.

Most should be fairly understanding of your predicament.

Very sorry to hear you going through this!

Please don't get burned out you've done so much for our community, it is immeasurable.

I think a lot of people will be willing to pay extra once they understand what you're going through.

If you were to start a GoFundMe just to help you continue this development. I would certainly pitch in what I could.

I know I would be happy and grateful even at the higher price to get this marvelous piece of technology, knowing that you're compensated for your work and your time in such a way that you do not feel that is a a burden.

Of course, from what I understand, you may even run across more challenges and I hope it doesn't get to the point where you actually have to take a loss.

Please take all the time you need with my order; I already have Lisas, and the later I get my unit, the later I'll be on the hook to make a square-pixel-compatible upgrade to the Selector. In fact, feel free send me the board that has the jankiest SRAM: I already have two of the exact same SRAM part sitting around my lab for a 2 MiB Lisa RAM board that I'll probably never design+build (it was a late-night impulse buy). I'll just whack a replacement in there and move on. It's a soldering challenge suited to my skills.

Now, I don't think I have the skills to do my own BGA rework, but I bet the set of people who can do that and who want one of these things is non-empty. Maybe you can sell the faulty stock as-is at a discount instead of dumping it as a total write-off?

Sorry to hear about this hiccup in what is already a legendary achievement (all carried out while pursuing a doctorate, which is plenty on its own; I should know). Please hang in there and work at a sustainable pace: nobody needs to have one of these things tomorrow, and anyone complaining about the price and the speed of fulfilment is welcome to design their own competing offering.

Very sorry to hear all this. Please don't feel obligated to speedrun this; take all the time you need to fulfill the orders to your satisfaction. I'll be patient. :) And anyone complaining about the price can suck a lemon.

I wouldn't blame you if you took some time off to get your bearings before completing the boards. It sounds like you know what needs to be done. I'm in no rush to get my board. It sounds like at least some of the boards have no problems.

Thanks everyone for being so understanding!

Fortunately, I was finally able to get the marginal RAM issues cleared up by optimizing the design so much that it'll run on even the slowest of RAM chips, and I shipped out all of the boards (minus the 5 dead ones) to MacEffects and JCM this morning. They should have them by Monday, and will start fulfilling everyone's preorders at that point. We're still waiting on one or two people who preordered to actually pay for their boards, but after they do (or we decide they're taking too long), the remaining boards will be open for anyone to buy and the Github repo will go public. The reason why I can't make it public yet is because it has a link to the MacEffects order page in the readme, and I can't release that until the preorders are all dealt with.

It's looking like, after all of the preorders are accounted for, MacEffects will have 7 boards and 0 Twiggy breakouts left to sell, and JCM will have 20 boards and 4 Twiggy breakouts left to sell. So still plenty of stock for anyone who wants one.

As I said, this has been such an unpleasent experience that I'm not sure I'll ever want to do it again. But perhaps I can work something out with MacEffects and/or JCM where they handle everything instead of me doing the programming and testing and then shipping it all off to them. Maybe that would be possible now that this first run has hopefully worked out all the kinks.

Now that these are out the door, I'll probably be taking a bit of a break before I get into designing the next board revisions. I just don't want to get so burned out on this project that I never want to look at it again. I promise I'll be getting back to it as soon as I feel like it though.

Quote from: bmwcyclist on July 02, 2026, 05:12:15 PMIf you were to start a GoFundMe just to help you continue this development. I would certainly pitch in what I could.

That's really generous, I just hate to take other people's money because then there's a lot at stake if I fail; not only have I let myself down, but I've also wasted a bunch of peoples' money.

Quote from: bmwcyclist on July 02, 2026, 05:12:15 PMOf course, from what I understand, you may even run across more challenges and I hope it doesn't get to the point where you actually have to take a loss.

I sure hope not; I definitely can't afford to take a loss. That's all going to depend on what happens with the broken boards and whether or not a bunch of people end up receiving defective boards (which they shouldn't because I did extensive testing on each one, but you never know). Only time will tell...

Quote from: stepleton on July 02, 2026, 05:50:33 PMNow, I don't think I have the skills to do my own BGA rework, but I bet the set of people who can do that and who want one of these things is non-empty. Maybe you can sell the faulty stock as-is at a discount instead of dumping it as a total write-off?

That's a really good idea; I've actually been considering it over the past few days. I'm just not sure what I'd set the price to. Maybe $100? Or is that too much?

It's too bad the industry wants to make parts like BGA that are harder to rework especially for hobbyists. I haven't even really done surface mount although I have several practice kits, I just keep putting it off. I started in 1977 when everything was through hole and surface mount was fairly new if available at all.

It looks like the final person preordered, so I can make the GitHub repo public. Here it is!

https://github.com/alexthecat123/LisaFPGA

And with that, both the MacEffects and JCM product pages are live. You can't order yet (not until they actually have the boards on-hand), but you should be able to by sometime next week. Also, I miscounted the number of boards that MacEffects will have on sale after preorders; they will actually have 4 leftover boards to sell, not 7. My JCM figures were accurate though.

https://maceffects.com/products/lisafpga
https://jcm-1.com/product/lisafpga/

Quote from: slewis1962 on July 04, 2026, 12:32:58 PMIt's too bad the industry wants to make parts like BGA that are harder to rework especially for hobbyists. I haven't even really done surface mount although I have several practice kits, I just keep putting it off. I started in 1977 when everything was through hole and surface mount was fairly new if available at all.

Yeah, definitely a shame, but I also see why it's necessary as chips get more and more complex and pin counts increase. I can do a little bit of SMD work, but 0603 packages are about as small as I can go. I did an 0.5mm QFP once, but it took many, many attempts and was NOT fun. BGAs are just a whole different ball game though.

Well, JCM updated the boards to be in stock on his site, and they're already all sold out before I even had time to make a post on here. MacEffects sold out yesterday before I had time to make a post too, but people who were signed up on the mailing list should've at least received an email about the JCM release today.

Hopefully I can do some future batches to fill any additional demand, with more help from MacEffects and JCM this time so that I don't have to do all the work myself!

Quote from: AlexTheCat123 on July 08, 2026, 06:19:58 PMWell, JCM updated the boards to be in stock on his site, and they're already all sold out before I even had time to make a post on here. MacEffects sold out yesterday before I had time to make a post too, but people who were signed up on the mailing list should've at least received an email about the JCM release today.

Hopefully I can do some future batches to fill any additional demand, with more help from MacEffects and JCM this time so that I don't have to do all the work myself!

Hey Alex

That must be a major relief for you to have them out of your hands and also all sold out. You deserve a big break from it all for a while but I know you will now be busy on a different level with your studies.

Look forward to receiving mine in Australia some time soon.

Thank you for the amazing job you have done on this.

Quote from: karmann68 on July 08, 2026, 06:40:46 PMThat must be a major relief for you to have them out of your hands and also all sold out. You deserve a big break from it all for a while but I know you will now be busy on a different level with your studies.

Yeah, it's very nice to be done! But as you said, even with this finished, I still have so much other stuff to do that I really don't get a break...

Quote from: karmann68 on July 08, 2026, 06:40:46 PMLook forward to receiving mine in Australia some time soon.

I hope you enjoy it!

It works! I tried with my DVI monitor with HDMI to DVI but it wouldn't work. I hooked it up to my boys HDMI gaming monitor long enough to verify functionality and it functions perfectly! Alex, this is the greatest piece of electronics gear since I purchased my Lisa 1 in 2002. This is awesome! I booted LOS 2.0 then MacWorks. Can't try my Twiggy drives as they somehow left out my Twiggy adapter board. I've already contacted them and hopefully will hear back next week.
(https://i0.wp.com/applelisa.net/wp-content/uploads/2026/07/IMG_9404-scaled.jpg?resize=1024%2C768&ssl=1)
(https://i0.wp.com/applelisa.net/wp-content/uploads/2026/07/IMG_9405-scaled.jpg?resize=1024%2C768&ssl=1)

In case anyone wants to see it I posted a short post on my blog applelisa.net.
https://applelisa.net/lisa-in-an-fpga/ (https://applelisa.net/lisa-in-an-fpga/)

On another note, does anyone have any plans on a case or backing board for this device? I haven't really given it much thought.

Quote from: slewis1962 on July 12, 2026, 12:52:26 AMOn another note, does anyone have any plans on a case or backing board for this device? I haven't really given it much thought.

I've designed a 3D printable case based on the board's 3D model, but I haven't yet had the opportunity to test it with a real board. I'm tracking my board's delivery and expect it tomorrow. Once I have a chance to test fit and make any necessary adjustments, I'll share my case design with others.

Below are some photos of the prototype case.

(https://s3.us-central-1.wasabisys.com/my-public-share/lisafpgacase/IMG_1066.jpeg)
(https://s3.us-central-1.wasabisys.com/my-public-share/lisafpgacase/IMG_1068.jpeg)
(https://s3.us-central-1.wasabisys.com/my-public-share/lisafpgacase/IMG_1069.jpeg)

Quote from: slewis1962 on July 11, 2026, 10:52:59 PMIt works! I tried with my DVI monitor with HDMI to DVI but it wouldn't work. I hooked it up to my boys HDMI gaming monitor long enough to verify functionality and it functions perfectly! Alex, this is the greatest piece of electronics gear since I purchased my Lisa 1 in 2002. This is awesome! I booted LOS 2.0 then MacWorks. Can't try my Twiggy drives as they somehow left out my Twiggy adapter board. I've already contacted them and hopefully will hear back next week.

I'm so glad it's working for you! Sorry about the Twiggy adapter board; it looks like they accidentally oversold by one and you're the person who bought the extra one that didn't exist. Mark will give you a refund, but Joe still has 3 in stock if you want to grab one from him: https://jcm-1.com/product/twiggy-breakout-for-lisafpga/

Quote from: slewis1962 on July 12, 2026, 12:52:26 AMOn another note, does anyone have any plans on a case or backing board for this device? I haven't really given it much thought.

In addition to @coffemuse's case, some people on TinkerDifferent appear to be working on one too. I'm not great at CAD modeling, so I'm not even bothering to try myself and I'm leaving it up to the pros.

I may just wait on the adapter board until others have tested it out.
I ordered an HDMI monitor from Amazon which will be here Tuesday so I don't have to steal my boys gaming monitor. I'm looking forward to getting more time with the FPGA Lisa.

Quote from: AlexTheCat123 on July 12, 2026, 03:01:20 PMIn addition to @coffemuse's case, some people on TinkerDifferent appear to be working on one too. I'm not great at CAD modeling, so I'm not even bothering to try myself and I'm leaving it up to the pros.

I'm not a CAD professional either, but I have enough knowledge to create boxes with holes and rounded corners (and some additional embellishments). However, after reviewing some of the design concepts they showcased on ThinkDifferent, I would consider my design to be quite "novice-level."

Quote from: slewis1962 on July 12, 2026, 05:02:48 PMI may just wait on the adapter board until others have tested it out.
I ordered an HDMI monitor from Amazon which will be here Tuesday so I don't have to steal my boys gaming monitor. I'm looking forward to getting more time with the FPGA Lisa.

Hopefully he won't mind being without the gaming display until Tuesday. Lisa takes priory, right?

Quote from: coffeemuse on July 12, 2026, 05:12:45 PM

Quote from: slewis1962 on July 12, 2026, 05:02:48 PMI may just wait on the adapter board until others have tested it out.
I ordered an HDMI monitor from Amazon which will be here Tuesday so I don't have to steal my boys gaming monitor. I'm looking forward to getting more time with the FPGA Lisa.

Hopefully he won't mind being without the gaming display until Tuesday. Lisa takes priory, right?

Exactly! Well done on the case design!

I was thinking with this new way of using the Lisa I might try programming. I've wanted to do something for years and never got around to it as I always thought my 40 year old computer was too fragile for extensive use. I used to write programs in Pascal on the Macintosh as a hobby and have programmed the 68000 in assembler so Lisa Pascal shouldn't be too hard. I just need to figure out something worth programming.

Quote from: slewis1962 on July 12, 2026, 05:19:34 PMExactly! Well done on the case design!

Thanks, but it is not much more than box with a lift off lid and holes for the various ports. 

Quote from: coffeemuse on July 13, 2026, 08:12:52 AM

Quote from: slewis1962 on July 12, 2026, 05:19:34 PMExactly! Well done on the case design!

Thanks, but it is not much more than box with a lift off lid and holes for the various ports. 

The important thing is it protects the board.

My LisaFPGA is finally here, and it's truly a work of art.

However, I seem to have made a mistake in my calculations, or the physical boards are larger than the 3D model. The ports align perfectly, but the shell is slightly too small to accommodate the board. I'll need to spend some more time in Fusion360 to refine the design and make it usable.

(https://s3.us-central-1.wasabisys.com/my-public-share/lisafpgacase/IMG_1125.jpeg)

Hey Alex,

Got my board yesterday in Australia, which is a lot quicker than I expected. Well done to MacEffects.


Can you please let me know the specs of the analogue video header (frequency, etc). Hoping to use a mono CRT and have a VGA one and many others.

QuoteCan you please let me know the specs of the analogue video header (frequency, etc). Hoping to use a mono CRT and have a VGA one and many others.

For video signal timing, try here: Lisa Composite Video Characteristics (https://lisalist2.com/index.php/topic,768.msg5586.html#msg5586)

Although note the LisaFPGA header provides digital signal voltages, not analog/composite as described by the linked post.

Great to see the positive reception of the first units - well done Alex!

edit: clarified per Alex's comment that the header is digital.

Quote from: coffeemuse on July 13, 2026, 03:26:57 PMMy LisaFPGA is finally here, and it's truly a work of art.

However, I seem to have made a mistake in my calculations, or the physical boards are larger than the 3D model. The ports align perfectly, but the shell is slightly too small to accommodate the board. I'll need to spend some more time in Fusion360 to refine the design and make it usable.

Glad you like it so far!

Perhaps you specced the outer dimensions of the case to be the same as the board, so then when you expanded the walls inward, it ended up being too small? Just a total guess though.

Quote from: karmann68 on July 13, 2026, 05:32:43 PMCan you please let me know the specs of the analogue video header (frequency, etc). Hoping to use a mono CRT and have a VGA one and many others.

It's the exact same timings that @sigma7 just linked to, except not composite; I expose VSYNC, HSYNC, and VID separately to allow for easy connection to an original Lisa video board (or other non-composite monitor).

Quote from: sigma7 on July 13, 2026, 06:18:20 PMGreat to see the positive reception of the first units - well done Alex!

Thank you!

QuoteI was thinking with this new way of using the Lisa I might try programming.
...
need to figure out something worth programming.

I think LOS needs:

• an xmodem file transfer program (that does binary files); this could be a command line program, but probably/eventually needs some assembly programming to achieve good throughput... the library serial routines have a lot of overhead.
• a GUI hex file/disk editor
• a peek/poke utility for use by EXEC scripts

edit: I realize now that I was thinking the "Workshop" rather than LOS itself.

Quote from: AlexTheCat123 on July 13, 2026, 06:21:19 PM

Quote from: coffeemuse on July 13, 2026, 03:26:57 PMMy LisaFPGA is finally here, and it's truly a work of art.

However, I seem to have made a mistake in my calculations, or the physical boards are larger than the 3D model. The ports align perfectly, but the shell is slightly too small to accommodate the board. I'll need to spend some more time in Fusion360 to refine the design and make it usable.

Glad you like it so far!

Perhaps you specced the outer dimensions of the case to be the same as the board, so then when you expanded the walls inward, it ended up being too small? Just a total guess though.

That is very likely the cause. I created the box walls around the edge of the board, but I now suspect that I may have thickened the walls in the wrong direction. If so, should be a fairly easy fix once I have time to sit down to work on the project, which likely will not be until this weekend when I will have some time without distractions.

That's precisely what transpired. I increased the wall thickness inward, making the cavity smaller than the PCB. I'm currently reviewing every design element and double-checking my measurements before embarking on another 10+ hour print.

Seeing that 3D printed case and reading Alex's comments about battery life on a power brick made me realize that...

The first person to make a LisaBook wins the Internet.

Quote from: sigma7 on July 13, 2026, 06:27:02 PMI think LOS needs:

• an xmodem file transfer program (that does binary files); this could be a command line program, but probably/eventually needs some assembly programming to achieve good throughput... the library serial routines have a lot of overhead.
• a GUI hex file/disk editor
• a peek/poke utility for use by EXEC scripts

edit: I realize now that I was thinking the "Workshop" rather than LOS itself.

It ain't XMODEM, but I did have to write a quick and dirty implementation of UUENCODE/DECODE for the Workshop for a uhh... different project I'm working on. It's not pretty and isn't technically directly compatible with the real UUENCODE/DECODE, as it requires accounting for the weird CR/LF issue with the Workshop, but it does allow you to send binary data over serial to the Transfer utility. And let me tell you, at 19200 baud with the LisaFPGA's improved serial buffer and overclocking, it makes moving files over sooooo nice, but I imagine it's dreadfully slow on actual hardware. I'll clean it up and post it to GitHub this week when I get some downtime in the evenings.

FujiNet for LOS!

A better document converter?

2nd on the xmodem

I have an NEC MultiSync 1980SX, which has a maximum resolution of 1280x720. With the LisaFPGA attached and powered on, I get an "out of range" error on the NEC - presumably because the LisaFPGA is generating a 1080p signal. Is there any way to adjust its output resolution or is that fixed?

It's fixed at 1080p; that's the lowest resolution at which the 720x364 3:2 upscaling works properly. 720*2=1440 and 364*3=1092, so 1920x1080 is what you need in order to fit the frame.

Can the FPGA run a real widget drive?

I worked my way through a bunch of USB keyboards and mice I have on hand and finally found a set that worked, or at least I thought.

Even though my Lenovo mouse fully works in the boot menu, once I get into LOS the pointer moves but I can't seem to click on anything. Does this sound like a mouse compatibility issue or something else?

The HP RGB gaming keyboard works fine.

Quote from: bmwcyclist on July 16, 2026, 11:07:38 PMCan the FPGA run a real widget drive?

Sure, just plug it into the external ProFile port with the appropriate cable and set the ProFile switch to EXT! You'll have to power the Widget separately though; the board doesn't have a Widget power connector on it.

Quote from: karmann68 on July 17, 2026, 01:00:36 AMEven though my Lenovo mouse fully works in the boot menu, once I get into LOS the pointer moves but I can't seem to click on anything. Does this sound like a mouse compatibility issue or something else?

Hmm, I don't see any reason why a mouse would work in the boot menu but not in LOS. Is it just double-click that doesn't work, or is single-click (like pulling down a menu) broken too?

Quote from: karmann68 on July 17, 2026, 01:00:36 AMEven though my Lenovo mouse fully works in the boot menu, once I get into LOS the pointer moves but I can't seem to click on anything. Does this sound like a mouse compatibility issue or something else?

I've encountered a similar issue. My mouse worked until LOS fully loaded, displaying the desktop. However, I couldn't move the cursor or click on anything. I attempted a soft power cycle by with the Lisa soft-power button, but the mouse still didn't function. I had to perform a full power cycle by using the physical power switch located next to the USB power port, and then the mouse worked again. Unfortunately, I haven't been able to reproduce the problem beyond that single instance. In my case, I was using a very inexpensive, generic wireless mouse with a USB receiver dongle when the issue occurred.  I really suspect mine was an issue with the mouse as I have seen it stop working on a modern PC and I'd have to remove the dongle and power-cycle the mouse.

Quote from: coffeemuse on July 13, 2026, 03:26:57 PMMy LisaFPGA is finally here, and it's truly a work of art.

However, I seem to have made a mistake in my calculations, or the physical boards are larger than the 3D model. The ports align perfectly, but the shell is slightly too small to accommodate the board. I'll need to spend some more time in Fusion360 to refine the design and make it usable.

(https://s3.us-central-1.wasabisys.com/my-public-share/lisafpgacase/IMG_1125.jpeg)

look forward to seeing it!

While I agree, the board is a work of art. The problem is there are so many switches and buttons in so many different places on the board. It makes it hard to put it in the case. If you need to access those buttons, I was hoping I could find a nice monitor with a flat back that I could mount the board to, and make it sort of a "all in one situation.

Alex, hats off to you, certainly the project of the year! I hope you have enough $$$ to keep making these beauties! 

Notes seem to say floppy emulator is not implemented.

Ok then that there is no display?

Quote from: bmwcyclist on July 17, 2026, 09:58:05 AMNotes seem to say floppy emulator is not implemented.

Ok then that there is no display?

The small display panel is part of the ESPFloppy Emulation, so there is no code on the board to make it do anything...yet. We have the hardware, but not the firmware to drive it.

I am using the Big Mess o' Wires Floppy Emulator (https://www.bigmessowires.com/floppy-emu/) in the interim.

The ESP Floppy display works, press the Select button and it will light up with a message!

Quote from: joeventura on July 17, 2026, 08:47:11 AMWhile I agree, the board is a work of art. The problem is there are so many switches and buttons in so many different places on the board. It makes it hard to put it in the case. If you need to access those buttons, I was hoping I could find a nice monitor with a flat back that I could mount the board to, and make it sort of a "all in one situation.

Yeah, there were just so many ports, buttons, and switches that I had to squeeze on here and I didn't really see a better way of doing it without making the board absurdly long. And I figured that having ports/buttons on all 4 sides would be better than making it really long and more expensive but with ports on only 2 sides, so that's why I made that decision. Definitely not ideal though.

Quote from: coffeemuse on July 17, 2026, 05:53:45 AMIn my case, I was using a very inexpensive, generic wireless mouse with a USB receiver dongle when the issue occurred.  I really suspect mine was an issue with the mouse as I have seen it stop working on a modern PC and I'd have to remove the dongle and power-cycle the mouse.

I'm honestly surprised that a wireless mouse worked at all! If anyone's still really struggling to find peripherals that work, then check the readme; I put a link in there to a cheap $14 keyboard/mouse combo that you can grab from Amazon that's tested and known-working.

Quote from: AlexTheCat123 on July 17, 2026, 03:55:59 AM

Quote from: bmwcyclist on July 16, 2026, 11:07:38 PMCan the FPGA run a real widget drive?

Sure, just plug it into the external ProFile port with the appropriate cable and set the ProFile switch to EXT! You'll have to power the Widget separately though; the board doesn't have a Widget power connector on it.

Quote from: karmann68 on July 17, 2026, 01:00:36 AMEven though my Lenovo mouse fully works in the boot menu, once I get into LOS the pointer moves but I can't seem to click on anything. Does this sound like a mouse compatibility issue or something else?

Hmm, I don't see any reason why a mouse would work in the boot menu but not in LOS. Is it just double-click that doesn't work, or is single-click (like pulling down a menu) broken too?

After some more testing I realised that the Menus weren't even showing up.

I tried the Macworks image and it worked fine. So then I tried switching the I/O ROM Select switch to the left, rebooted to LOS 2.0 and it now works!

Now re-reading the Readme to understand what that switch does again. (EDIT: OK, got it. 400/800KB Floppy or Twiggy ROM select).

 

Yeah, that explains it! If the switch is flipped to the right (40 position), LOS will hang forever unless you have Twiggies connected.

Quote from: AlexTheCat123 on July 17, 2026, 02:04:09 PMYeah, there were just so many ports, buttons, and switches that I had to squeeze on here and I didn't really see a better way of doing it without making the board absurdly long. And I figured that having ports/buttons on all 4 sides would be better than making it really long and more expensive but with ports on only 2 sides, so that's why I made that decision. Defintiely not ideal though.

Just to reiterate, you are the rockstar in this equation, and I am not worthy to shine your shoes. But if I can humbly suggest that if you ever make another version of this board you add an edge connector that all the buttons run out to that would be awesome and then folks could create a case where they have button control in one centralized location. But again I am merely a mortal.

If you are determined to use an Apple USB keyboard, I have been able to do so by putting the LisaFPGA into Lisa keyboard mode and then using James Denton's usb2Lisa keyboard adapter. It's a bit of a roundabout solution, but it works.

Yeah, the usb2Lisa adapter has a dedicated USB host controller on it instead of bit-banging USB like I'm doing, so it should be able to handle pretty much any keyboard out there.

Can LOS 1.0 used without a Twiggy Drive and just with a floppy emulator or physical Sony drive? And where do I find the twiggies.image file? Thanks

I finally got an appropriate display and had some time to explore the LisaFPGA today. How cool is this thing?!?  8)  A few observations and questions follow. For context, I've only been attempting to boot Lisa Office System 1.2, 2.0, and 3.1 so far.

First, I can get a working LOS 2.0 desktop using the H/A8 ROM configuration. If I attempt to use the H/40 ROM configuration, LOS 1.2 and 2.0 both hang after drawing the desktop icons and before drawing the menu bars at the top of the screen. This is usually when the Twiggy drives "grunt" to reset the mechanism and the floppies are subsequently shown on the desktop, so presumably it's stuck because there's no floppy drive for the 40 ROM to reset.

Using the A8 I/O ROM bypasses this issue.

Attempting to boot LOS 3.1 gives error 10738 no matter what. I'm using the recommended PNY microSD cards, which work properly with a standalone ESProFile attached to a real Lisa. The same LOS 3.1 drive image inevitably fails with the LisaFPGA. I have used multiple PNY cards, and erased / copied over known good drive images many times with the same result. I cannot boot LOS 3.1 on the LisaFPGA at this time.  Edit: This has been resolved by creating a new 10MB disk image and creating a fresh LOS 3.1 installation using the BMOW FloppyEmu. Woohoo!

With LOS 1.2 hanging at the point when Twiggies are supposed to be shown on the desktop, I was tempted to attach the drives via the breakout board and see if that enabled me to fully boot LOS 1.2, so I attached them per Alex's instructions. Everything seems to hook up just fine, but I noticed that the red stripe on the drive connector cable is on the opposite side of the real Lisa's red stripe on it 26-pin cable. On Alex's supplied cable, the connector slots into the keyed port with the red stripe closest to the outside of the Twiggy drive, while the Lisa's own drive cage connector features a red stripe oriented toward the middle of the drive (photos attached for reference). I would like to confirm that there are no issues with this before applying power to the drives. Halp! :P

LOS 1.2 drive image also attached, so others can tinker with it. I made that a couple of years ago using sigma7's BLU to copy the contents of my LOS 1.2 X/ProFile to one of ArcaneByte/James' neat (now unavailable) PocketBeagle-based ProFile emulators. The same disk image works great with Alex's more modern ESProFile, too. Teamwork!

Who's going to jump in first and show their Twiggies working?  :D

Since the pre-existing LOS 3.1 disk images didn't work for me - even those labeled "fresh install" - I went ahead and created a 10MB disk image and installed LOS 3.1 with all of the 7/7 apps. These should work for everyone if the LisaFPGA uses the same Video State ROM on all LisaFPGA builds. Cheers.

Quote from: karmann68 on July 18, 2026, 06:05:25 PMCan LOS 1.0 used without a Twiggy Drive and just with a floppy emulator or physical Sony drive? And where do I find the twiggies.image file? Thanks

From my testing over the past several months (and seemingly from what @ried has found too), it looks like the answer is no. It hangs on the desktop waiting for the nonexistent floppy drives if you have the 40 ROMs selected, and doesn't even get to the desktop at all with the A8 ROMs.

Quote from: ried on July 18, 2026, 06:43:50 PMAttempting to boot LOS 3.1 gives error 10738 no matter what. I'm using the recommended PNY microSD cards, which work properly with a standalone ESProFile attached to a real Lisa. The same LOS 3.1 drive image inevitably fails with the LisaFPGA. I have used multiple PNY cards, and erased / copied over known good drive images many times with the same result. I cannot boot LOS 3.1 on the LisaFPGA at this time.  Edit: This has been resolved by creating a new 10MB disk image and creating a fresh LOS 3.1 installation using the BMOW FloppyEmu. Woohoo!

Was the defective image an image that had previously been used on a 2/10 by chance? Once you boot LOS 3 on a 2/10, if you try and use the same image on a 2/5 again, then you'll get an error 10738. You can get around this by either reinstalling the OS or by making the FPGA trick the OS into thinking it's on a 2/10 by connecting GPIO0 to 3.3V.

Quote from: ried on July 18, 2026, 06:43:50 PMI would like to confirm that there are no issues with this before applying power to the drives. Halp! :P

Yeah, we definitely don't want to fry any Twiggy drives! I think the easiest way to confirm the polarity is to test continuity between pin 1 (12V) on the breakout board's connector and something on the drive that runs on 12V. Looking at the Twiggy schematics, it appears as if some good 12V candidates on the drive would be a leg of C1, C5, C10, C16, or C18. The other leg is ground, so if you don't see continuity, then you're probably on the ground leg (or my connector is backwards and we have a serious problem). Pin 1 on the breakout connector is going to be the pin with the square pad (all the others are circular); it's the one at the bottom-left for the UPPER TWIGGY connector. If you get continuity between the 12V pin and one of those capacitors on the drive, then the polarity should be right and you should be clear to turn things on!

Just in case something does go wrong, I'd suggest starting with just one drive connected so that you're not risking two of them at once.

Quote from: ried on July 18, 2026, 06:43:50 PMWho's going to jump in first and show their Twiggies working?  :D

Hopefully you if we can get to the bottom of the cable situation!

Today I've been tinkering in the workshop. As my original Lisa keyboards need rebuilt I've been using several USB keyboards. Both my USB keyboards repeat keys randomly and even repeat after my fingers are completely off the keyboard. Anyone else have this problem? I'm wondering if I just happen to have two flaky keyboards (both brand new) or if this is some kind of problem with my board?

Quote from: ried on July 18, 2026, 06:43:50 PMI finally got an appropriate display and had some time to explore the LisaFPGA today. How cool is this thing?!?  8)  A few observations and questions follow. For context, I've only been attempting to boot Lisa Office System 1.2, 2.0, and 3.1 so far.

First, I can get a working LOS 2.0 desktop using the H/A8 ROM configuration. If I attempt to use the H/40 ROM configuration, LOS 1.2 and 2.0 both hang after drawing the desktop icons and before drawing the menu bars at the top of the screen. This is usually when the Twiggy drives "grunt" to reset the mechanism and the floppies are subsequently shown on the desktop, so presumably it's stuck because there's no floppy drive for the 40 ROM to reset.

Using the A8 I/O ROM bypasses this issue.

Attempting to boot LOS 3.1 gives error 10738 no matter what. I'm using the recommended PNY microSD cards, which work properly with a standalone ESProFile attached to a real Lisa. The same LOS 3.1 drive image inevitably fails with the LisaFPGA. I have used multiple PNY cards, and erased / copied over known good drive images many times with the same result. I cannot boot LOS 3.1 on the LisaFPGA at this time.  Edit: This has been resolved by creating a new 10MB disk image and creating a fresh LOS 3.1 installation using the BMOW FloppyEmu. Woohoo!

With LOS 1.2 hanging at the point when Twiggies are supposed to be shown on the desktop, I was tempted to attach the drives via the breakout board and see if that enabled me to fully boot LOS 1.2, so I attached them per Alex's instructions. Everything seems to hook up just fine, but I noticed that the red stripe on the drive connector cable is on the opposite side of the real Lisa's red stripe on it 26-pin cable. On Alex's supplied cable, the connector slots into the keyed port with the red stripe closest to the outside of the Twiggy drive, while the Lisa's own drive cage connector features a red stripe oriented toward the middle of the drive (photos attached for reference). I would like to confirm that there are no issues with this before applying power to the drives. Halp! :P

LOS 1.2 drive image also attached, so others can tinker with it. I made that a couple of years ago using sigma7's BLU to copy the contents of my LOS 1.2 X/ProFile to one of ArcaneByte/James' neat (now unavailable) PocketBeagle-based ProFile emulators. The same disk image works great with Alex's more modern ESProFile, too. Teamwork!

Who's going to jump in first and show their Twiggies working?  :D

I'm waiting for feedback from others before ordering a Twiggy breakout board.

Quote from: slewis1962 on July 18, 2026, 08:29:41 PMToday I've been tinkering in the workshop. As my original Lisa keyboards need rebuilt I've been using several USB keyboards. Both my USB keyboards repeat keys randomly and even repeat after my fingers are completely off the keyboard. Anyone else have this problem? I'm wondering if I just happen to have two flaky keyboards (both brand new) or if this is some kind of problem with my board?

Can't say that I've seen that exact symptom or heard or heard it from anyone yet. Clearly the keyboard interface is proving to be the weak point of this whole project...

Quote from: AlexTheCat123 on July 18, 2026, 08:03:49 PMJust in case something does go wrong, I'd suggest starting with just one drive connected so that you're not risking two of them at once.

I am absolutely going to wait for you, or at least someone more technically proficient than I am, to tackle that confirmation!  :D

It is certainly possible that the LOS 3.1 image had been used on a 2/10, which caused error 10738. I just copied it from my repository of Lisa disk images. Glad to know it's that simple.

Nice work on this, Alex! Coolest project ever. Watch out, this battle station is operational!

Quote from: AlexTheCat123 on July 18, 2026, 08:39:39 PM

Quote from: slewis1962 on July 18, 2026, 08:29:41 PMToday I've been tinkering in the workshop. As my original Lisa keyboards need rebuilt I've been using several USB keyboards. Both my USB keyboards repeat keys randomly and even repeat after my fingers are completely off the keyboard. Anyone else have this problem? I'm wondering if I just happen to have two flaky keyboards (both brand new) or if this is some kind of problem with my board?

Can't say that I've seen that exact symptom or heard or heard it from anyone yet. Clearly the keyboard interface is proving to be the weak point of this whole project...

I've seen the same issue with my HP keyboard. Typing slower seems to help I think but will do further testing.

Quote from: karmann68 on July 18, 2026, 08:55:25 PMI've seen the same issue with my HP keyboard. Typing slower seems to help I think but will do further testing.

Interesting. I use an early-2010s HP keyboard with mine and I can type as fast as I want without problems. Might your issue (and yours, @slewis1962) be related to the key repeat rate in LOS? You have to turn it down in Preferences when overclocking or else just tapping a key once will make it repeat several times.

Quote from: AlexTheCat123 on July 18, 2026, 09:03:38 PM

Quote from: karmann68 on July 18, 2026, 08:55:25 PMI've seen the same issue with my HP keyboard. Typing slower seems to help I think but will do further testing.

Interesting. I use an early-2010s HP keyboard with mine and I can type as fast as I want without problems. Might your issue (and yours, @slewis1962) be related to the key repeat rate in LOS? You have to turn it down in Preferences when overclocking or else just tapping a key once will make it repeat several times.

One of mine was doing that but my other would keep repeating after removing my hands from the keyboard. Anybody know if key repeat rate can be adjusted in workshop? This is my first time trying it.

Quote from: AlexTheCat123 on July 18, 2026, 08:39:39 PM

Quote from: slewis1962 on July 18, 2026, 08:29:41 PMToday I've been tinkering in the workshop. As my original Lisa keyboards need rebuilt I've been using several USB keyboards. Both my USB keyboards repeat keys randomly and even repeat after my fingers are completely off the keyboard. Anyone else have this problem? I'm wondering if I just happen to have two flaky keyboards (both brand new) or if this is some kind of problem with my board?

Can't say that I've seen that exact symptom or heard or heard it from anyone yet. Clearly the keyboard interface is proving to be the weak point of this whole project...

Is it safe to assume that if I rebuild my Lisa keyboard I won't have these issues? I'm assuming it's just the USB implementation. I need to order new foam pads from TexElec unless someone has a better source. I've been meaning to do this for years but now with this new board I have a good reason. No more procrastination!

You know, I could try out my USB keyboards with my real Lisa with my USB to Lisa keyboard adapter. That would answer my question. I have a 2/10 with what used to be a working Widget, at least it worked several years ago. My basement is dry and climate controlled so hopefully it still works. I probably need to install the workshop to get an apples to apples comparison. It currently has just LOS 3.1.

Quote from: AlexTheCat123 on July 18, 2026, 09:03:38 PM

Quote from: karmann68 on July 18, 2026, 08:55:25 PMI've seen the same issue with my HP keyboard. Typing slower seems to help I think but will do further testing.

Interesting. I use an early-2010s HP keyboard with mine and I can type as fast as I want without problems. Might your issue (and yours, @slewis1962) be related to the key repeat rate in LOS? You have to turn it down in Preferences when overclocking or else just tapping a key once will make it repeat several times.

Will give that a try in both standard and overclock speed when I get a chance. Thanks.

One more quick question: When I connect the modem emulator to Serial B, LisaTerminal does not see it connected. I've tried flipping the Serial B switch on the LisaFPGA board to from RS-232 to USB and vice versa, but that didn't make a difference. LOS preferences are set correctly. However, when I switched to use Serial A, everything works just fine.

Is this a known limitation with Serial B? Or am I not configuring something correctly?

Bad news, my 2/10 is buried in my storage room. At least two hours or more to dig it out. My shop has two Lisa 2/5's accessible. I need to either hook up my X/Profile or try out my ESProfile that I got last year. Any tips on using the ESProfile or is everything in the GitHub?

Quote from: ried on July 18, 2026, 09:32:28 PMOne more quick question: When I connect the modem emulator to Serial B, LisaTerminal does not see it connected. I've tried flipping the Serial B switch on the LisaFPGA board to from RS-232 to USB and vice versa, but that didn't make a difference. LOS preferences are set correctly. However, when I switched to use Serial A, everything works just fine.

Is this a known limitation with Serial B? Or am I not configuring something correctly?

Does the modem adapter use RS-422? Because if so, then it's a limitation of the board. I couldn't find any 26LS30s (or modern equivalents) in stock anywhere, so the board isn't capable of RS-422 differential transmission, only single-ended transmision. I was able to find a 26C32 though, so it can at least receive RS-422. I figured that this wouldn't really affect anyone at all since most people just use the ports as standard RS-232 ports, but maybe that was a bad assumption on my part.

Quote from: slewis1962 on July 18, 2026, 09:44:10 PMAny tips on using the ESProfile or is everything in the GitHub?

No tips that I can really think of. It should all be right there in the readme!

Quote from: AlexTheCat123 on July 18, 2026, 10:33:42 PMDoes the modem adapter use RS-422?

We'll have to page jamesdenton to confirm that one. It's no biggie, really. Serial A is working fine. I'm just used to using Serial B since it supports higher throughput on a real Lisa.

Quote from: karmann68 on July 18, 2026, 06:05:25 PMCan LOS 1.0 used without a Twiggy Drive and just with a floppy emulator or physical Sony drive? And where do I find the twiggies.image file? Thanks

I am able to run my Lisa 1 with LOS 1.0 WITHOUT the twiggy drives attached, but the LisaFPGA hangs with the hourglass once LOS 1.0 loads.

The BMOW FEMU cannot emulate Twiggy drives. There was a proposed project with Steve Chamberlain a couple years ago to add Twiggy emulation to the FEMU. It could be done, but there was very little interest and the time and cost required was not considered justifiable.

Perhaps Alex can include Twiggy emulation in the ESFloppy?

Quote from: Lisa1 on July 20, 2026, 11:11:28 AM

Quote from: karmann68 on July 18, 2026, 06:05:25 PMCan LOS 1.0 used without a Twiggy Drive and just with a floppy emulator or physical Sony drive? And where do I find the twiggies.image file? Thanks

I am able to run my Lisa 1 with LOS 1.0 WITHOUT the twiggy drives attached, but the LisaFPGA hangs with the hourglass once LOS 1.0 loads.

It's hanging after the desktop icons appear and before the window menus are drawn, correct? If so, that is the same experience I have. It's trying to reset and mount the Twiggies and hanging because they're not attached.

My case design has been updated and now fits the board perfectly. However, my printing experience took a turn for the worse. I ran out of the beige filament halfway through printing the new, resized lid, which is why half of the lid is white. I still need to polish the design a bit, but I'll publish it this weekend for anyone interested in printing their own case.   

(https://s3.us-central-1.wasabisys.com/my-public-share/lisafpgacase/case1.jpg)
(https://s3.us-central-1.wasabisys.com/my-public-share/lisafpgacase/case2.jpg)

yes please

I don't have a 3D printer, so went with a simple clear acrylic panel that uses the board's four holes. Seems to work pretty well.

That's my plan for when I get a round tuit --- a nice acrylic sandwich.

Is my assumption correct that there is no LOS FTP client?

Quote from: bmwcyclist on July 29, 2026, 04:31:12 PMthere is no LOS FTP client?

Correct, there is none (for now at least).

LisaTerminal is the only transfer option that comes to mind.

edit: and IIRC, Stepleton captured some LOS print output recently, and massaged it into text and graphics for a modern system.

Aside: How many of you would prefer a post like this be moved to its own topic, or do you not care if subject titles are less specific?

I have been unsucessful in getting my LISA FPGA to boot into LOS.

I have used a copy that works on my 2/10 "

Any suggestions?

Quote from: bmwcyclist on July 29, 2026, 08:11:58 PMI have been unsucessful in getting my LISA FPGA to boot into LOS.

I have used a copy that works on my 2/10 as well as the GitHub "LOS Compilation Base.image"

Any suggestions?

What brand/model of SD card are you using? Alex mentioned some don't work

[/quote]

What brand/model of SD card are you using? Alex mentioned some don't work
[/quote]

Several models all high speed.

Interestingly, I just got it to boot off of LOS 2.0!

Tim, have you tried downloading and using the LOS 3.1 disk image that I attached to this post?

Quote from: ried on July 18, 2026, 08:03:03 PMSince the pre-existing LOS 3.1 disk images didn't work for me - even those labeled "fresh install" - I went ahead and created a 10MB disk image and installed LOS 3.1 with all of the 7/7 apps. These should work for everyone if the LisaFPGA uses the same Video State ROM on all LisaFPGA builds. Cheers.

Quote from: ried on July 29, 2026, 09:28:25 PMTim, have you tried downloading and using the LOS 3.1 disk image that I attached to this post?

Quote from: ried on July 18, 2026, 08:03:03 PMSince the pre-existing LOS 3.1 disk images didn't work for me - even those labeled "fresh install" - I went ahead and created a 10MB disk image and installed LOS 3.1 with all of the 7/7 apps. These should work for everyone if the LisaFPGA uses the same Video State ROM on all LisaFPGA builds. Cheers.

No, I missed that. Thank you. I'll give it a try tomorrow!

Quote from: bmwcyclist on July 29, 2026, 08:11:58 PMI have used a copy that works on my 2/10 "

That's probably why! Either use an LOS image that was made on a 2/5, or install a jumper wire between GPIO0 and 3V3 on the board to trick it into thinking that it's a 2/10.

Quote from: AlexTheCat123 on July 29, 2026, 11:54:21 PM

Quote from: bmwcyclist on July 29, 2026, 08:11:58 PMI have used a copy that works on my 2/10 "

That's probably why! Either use an LOS image that was made on a 2/5, or install a jumper wire between GPIO0 and 3V3 on the board to trick it into thinking that it's a 2/10.

Thanks! I love this thing, I am learning quite a bit I never knew about LISA and the LOS!

ried's build works great! Thanks!

Still not getting the LOS Compilation Base.image to work even with the sm fcc180 00ff 0055 00aa PRAM reset.

Going to try the jumper next...

Compilation image DOES work once 2/10 jumper is installed on the FPGA!  ;D

During my efforts to get Twiggy emulation working on ESFloppy, I discovered that the hang in LOS 1.0 is NOT because Twiggy drives aren't connected and was actually because of a bug in the LisaFPGA floppy controller. The 6504's stack page was set to the wrong place in the FDC's memory and was clobbering actual FDC data as more and more stuff got pushed onto the stack, causing the FDC to get stuck in weird infinite loops, randomly reset itself, and sometimes fail to respond to the 68K. Moving the stack page to where it was supposed to be fixed the problem, and now LOS 1.0 will boot regardless of whether or not Twiggies are connected! Make sure you have the 40 ROMs selected though; LOS 1.0 will still crash with the A8 ROMs and that's by design.

Oddly enough, this bug didn't expose itself with the A8 ROMs for whatever reason; only with the 40 ROMs. I guess 40 either pushes more stuff onto the stack or stores more sensitive info near the invalid stack location. Who knows?

The updated core is now available on GitHub, so go ahead and flash that to your board if you want to get LOS 1.0 running and unlock full Twiggy support!

Quote from: AlexTheCat123 on August 03, 2026, 02:31:27 PMThe updated core is now available on GitHub, so go ahead and flash that to your board if you want to get LOS 1.0 running and unlock full Twiggy support!

Will that update also give Sony 400/800k support under the other ROMs?

Thanks for all of the great work!

No, the 40 ROMs are designed specifically for Twiggies and the A8 ROMs are for Sony drives. You can't use Sony drives with the 40 ROMs.

Quote from: AlexTheCat123 on August 03, 2026, 02:31:27 PMThe updated core is now available on GitHub, so go ahead and flash that to your board if you want to get LOS 1.0 running and unlock full Twiggy support!

Thanks for the update! I had a look at the updater script, and I decided that it was a bit too presumptuous about installing things for my old-fashioned tastes: I wasn't going to run it on my Linux box directly. (I draw the line at curl'ing a script and piping it into a UID 0 shell without asking, even though that's fashionable these days. Actually I draw the line back quite some ways behind that.)

Since just running the script directly was a non-starter for me, I was hoping it would be possible to do in a virtual machine. I'm happy for the script to do whatever it wants in a VM; my actual permanent installation won't be altered. Here's how I got on:

• Using virt-manager on linux, I made a fresh VM and installed debian from an iso.
• While installing, I went to the instance's virtual hardware details tab and added a whole bunch of USB redirectors, since to Linux, a LisaFPGA is about four separate USB devices. (Actually it's five... forshadowing...)
• Once booted into my fresh new debian system, I installed git (and curl, make, and gcc, which are also needed) via apt and cloned the LisaFPGA repo.
• I plugged my LisaFPGA into my computer, then used "Redirect USB device" from the Virtual Machine menu to redirect four visible LisaFPGA devices (two Espressif devices and two devices with LisaFPGA in the name) into the VM.
• I did `sudo ./program_board.sh` and things were plain sailing until it attempted to find out which serial ports were the ESProFile and the ESFloppy, where it complained it couldn't find the CH334 USB hub ("is the board plugged in?"). It appears that there's no way to redirect the hub itself into the VM. But since the script only seems to use this to identify the serial ports, I eventually just decided to YOLO a guess that the ESProFile would be ACM0 and the ESFloppy would be ACM1. If I got it wrong, could it be all that bad? Aren't they the same ESP32 devices and couldn't I just swap them around and try again?
• So I `sudo ./program_board.sh`ed again and it all seemed to go fine.
• I undid the four USB redirects and restarted the LisaFPGA. All is well; looks like I guessed right about ACM0 and ACM1!

So it started well, then turned into one of those experiences I call "some Linux or something (https://www.youtube.com/watch?v=Az49aNuYeJs)", and then all worked out in the end. (NB: I am not casting aspersions at the script, which is written for a different setup and system of preferences than my own; I essentially blame these kinds of experiences on the OS.)

For future VM-based upgrades, it looks like I'm going to have to do that same serial port YOLO unless there's a different device identification method that doesn't need the USB hub to be there. I'm a bit out of my depth to suggest something; I'm guessing you can't rename the "Espressif USB JTAG/serial debug unit" that you find in an `lsusb` listing, but I wonder if there's a way to match the corresponding bus and device addresses in the listing to a /dev/ device without involving the hub.

Either way, I'm probably a special case for wanting to upgrade from inside of a VM, so there are probably better things to do than to fix this.

Meanwhile, who remembers the mysterious, marvelous pablo_marx (https://lisalist2.com/index.php?action=profile;u=769)? This wizard came out of the woodwork in early 2025 and hacked the Monitor OS to boot from a ProFile instead of from floppies... then went from that to get the Apple Lisa Smalltalk demo from that Bitsavers twiggy disk image to run on the Lisa 2 from a hard-drive bootable Monitor. It all happened in this thread (https://lisalist2.com/index.php/topic,87.30.html), and after these accomplishments our Marx vanished to start another revolution somewhere else.

I mention this because LisaFPGA rejects this form of Marxism by pitching an Error 75 when attempting to boot one of these Monitor drive images, or at least it does for me. I'm not sure why this would happen, and it's possible the problem is on my end, so I wonder: does it happen for anyone else?

Quote from: stepleton on August 13, 2026, 06:45:44 PMI'm guessing you can't rename the "Espressif USB JTAG/serial debug unit" that you find in an `lsusb` listing, but I wonder if there's a way to match the corresponding bus and device addresses in the listing to a /dev/ device without involving the hub.

There wasn't any way I could come up with to discriminate between the two ESP32s that didn't involve looking at the hub. They look indistinguishable from each other, and any method of changing the device's name (which I'm not even sure you can do on an ESP32) would require you to know which is which so that you know what device needs to be named what in the first place.

Quote from: stepleton on August 13, 2026, 07:13:51 PMI mention this because LisaFPGA rejects this form of Marxism by pitching an Error 75 when attempting to boot one of these Monitor drive images, or at least it does for me. I'm not sure why this would happen, and it's possible the problem is on my end, so I wonder: does it happen for anyone else?

Wow, that's not good! Come to think of it, I'm not sure that I ever tested the Monitor on it, which is a huge oversight on my part. I'll take a look once I'm done with ESFloppy and see if I can replicate those problems.

Okay, as part of my ESFloppy testing, I just booted several of the Twiggy Monitor images, both versions 11 and 12, and they all worked great. I was even able to start up Smalltalk. So whatever your problem is, it probably has something to do with the ProFile mod.

One other thing though: have you tried running with 1MB of RAM instead of 2MB? Smalltalk refused to load until I downgraded to 1MB, so perhaps you're having the same problem (just with more extreme symptoms) on your setup?

Quote from: AlexTheCat123 on August 13, 2026, 10:19:44 PMThere wasn't any way I could come up with to discriminate between the two ESP32s that didn't involve looking at the hub. They look indistinguishable from each other, and any method of changing the device's name (which I'm not even sure you can do on an ESP32) would require you to know which is which so that you know what device needs to be named what in the first place.

I wonder if you could change the ESProFile and ESFloppy firmware so that each device identifies itself on the serial port, perhaps in response to a challenge byte. The script could then connect to each /dev/ttyACM* device in order, trying to find one that says "how do you do I am an ESProFile on a LisaFPGA".

It would be a bit impolite if people had other serial port devices on their computer, but since the script is already somewhat brash, maybe it's okay. As a conservative choice of challenge byte, how about $11, the "XON" byte for serial port software flow control. It's one that literally means "go ahead and send data", and if I were writing a serial port program, I'd avoid giving the XON and XOFF bytes any other interpretation. So it seems more likely to be harmless if you send it to some bystander device.

One question: my YOLO assumption that it's not the end of the world if the ESProFile gets ESFloppy firmware or vice versa --- is this actually a safe assumption or could it break things? (Assume no real ProFile or floppy drives are connected to the LisaFPGA.)

QuoteOne other thing though: have you tried running with 1MB of RAM instead of 2MB? Smalltalk refused to load until I downgraded to 1MB, so perhaps you're having the same problem (just with more extreme symptoms) on your setup?

Good thought... I gave it a try (on both 01 and 10 RAM jumper settings) and no dice, unfortunately!

Quote from: stepleton on August 14, 2026, 04:02:18 AMI wonder if you could change the ESProFile and ESFloppy firmware so that each device identifies itself on the serial port, perhaps in response to a challenge byte. The script could then connect to each /dev/ttyACM* device in order, trying to find one that says "how do you do I am an ESProFile on a LisaFPGA".

That's an option, but it doesn't solve identification of the devices when they're still fresh from the factory and haven't been programmed with anything yet. In that situation you're still stuck with the hub, and while some people will be using the script to upgrade existing firmware, many others will be using it to install firmware for the first time. And in the event that you have to hold the BOOT button to get your ESP32 to program (which happens from time to time on ESP32s for inexplicable reasons), it wouldn't output that identity data anyway, even if it IS properly programmed.

Quote from: stepleton on August 14, 2026, 04:02:18 AMGood thought... I gave it a try (on both 01 and 10 RAM jumper settings) and no dice, unfortunately!

Darn! So clearly whatever it is, it's something to do with the ProFile version in particular. Can you attach or email me the exact image you're using so I can test with an identical config?

I guess one other thing you can try too if you haven't already: mess with the clock speed and see if it works at certain speeds and not others. Perhaps it's incompatible with the overclock for some reason but works fine at stock speed...

Quote from: AlexTheCat123 on August 14, 2026, 04:18:59 PMThat's an option, but it doesn't solve identification of the devices when they're still fresh from the factory and haven't been programmed with anything yet.

I'll live with just YOLOing port assignments as described provided you think it's low-risk. If I accidentally put ESFloppy firmware on the ESProFile or vice versa, is there any chance of bricking the board or causing hardware damage?

Quote from: AlexTheCat123 on August 14, 2026, 04:18:59 PMI guess one other thing you can try too if you haven't already: mess with the clock speed and see if it works at certain speeds and not others. Perhaps it's incompatible with the overclock for some reason but works fine at stock speed...

My experiments were all at stock speed, unfortunately! I wanted to remove acceleration as a factor.

Quote from: stepleton on August 14, 2026, 04:33:09 PMI'll live with just YOLOing port assignments as described provided you think it's low-risk. If I accidentally put ESFloppy firmware on the ESProFile or vice versa, is there any chance of bricking the board or causing hardware damage?

Yeah, you should be fine. I've accidentally uploaded the wrong one to the wrong chip several times and nothing bad has happened. Although there is a trick you can use to identify which is which. Just press and hold the RESET button of one of the ESP32s and check to see which port disappears on your computer. The one that vanished is the one whose button you're holding down.

Quote from: stepleton on August 14, 2026, 04:33:09 PMMy experiments were all at stock speed, unfortunately! I wanted to remove acceleration as a factor.

That's a shame! Send me the image and I'll take a look as soon as I have time.

Quote from: AlexTheCat123 on August 15, 2026, 04:49:14 AMThat's a shame! Send me the image and I'll take a look as soon as I have time.

No need --- it looks like it might be an issue with the "raw" images that pablo_marx included in zip files on that thread. (I was getting Error 75 on my real Lisa 2/10 as well.) I found working images sitting on one of my Cameo/Aphids, and they are attached here. They work on the LisaFPGA and on a real Lisa from an ESProFile without a problem, even in accelerated mode. I think I may have made them by dumping pablo_marx's .dc42 files to raw images by myself. At last, Smalltalk on a Lisa feels snappy.

One thing I have found since upgrading my firmware is that the Selector doesn't recognise the LisaFPGA's ESProFile as being Selector-compatible on first boot. It gives the option to go ahead and use the ESProFile anyway, and everything works fine; sometimes on reboots, the recognition also works as normal.

I looked at the $FFFFFF block in NeoWidEx and the magic bytes marking Selector compatibility were indeed present, so I'm not certain what the issue could be.

Nice, that's good news!

Strange about the Selector issue. I can't replicate it on my end; it catches it as Selector-compatible on the first and all subsequent boots.

I'm having trouble loading new firmware on my board. I tried with Mac OS 10.10 on my Mac Mini 2012 and with my 2 year old MacBook Pro running the latest Mac OS and I get the same error:
Scotts-Mac-mini:LisaFPGA-main mainuser$ ./program_board.sh
[INFO]  Platform: macos

══ Checking / Installing Dependencies ══
[ OK ]  git: git version 2.24.3 (Apple Git-128)
[INFO]  Installing pyusb...

Usage:   
  pip3 install [options] <requirement specifier> [package-index-options] ...
  pip3 install [options] -r <requirements file> [package-index-options] ...
  pip3 install [options] [-e] <vcs project url> ...
  pip3 install [options] [-e] <local project path> ...
  pip3 install [options] <archive url/path> ...

no such option: --break-system-packages
Scotts-Mac-mini:LisaFPGA-main mainuser$

I then tried on Debian and get the following error:
scott@debian:~/Documents/LisaFPGA-main$ sudo ./program_board.sh
[INFO]  Platform: linux

══ Checking / Installing Dependencies ══
[ OK ]  git: git version 2.39.5
[ OK ]  pyusb: 1.2.1-2
[ OK ]  ftdi_eeprom: v0.17
[INFO]  Installing arduino-cli...
./program_board.sh: line 151: curl: command not found
scott@debian:~/Documents/LisaFPGA-main$

I'm going to have to research what each of these errors mean unless someone has a quick fix. On all three systems I downloaded the zip file and unzipped into my downloads or documents folders.

I figured out I had to update pip. After the update I ran it again on my MacBook Pro and now I get this:
scottlewis@Scotts-MacBook-Pro LisaFPGA-main % ./program_board.sh     
[INFO]  Platform: macos

══ Checking / Installing Dependencies ══
[ OK ]  git: git version 2.50.1 (Apple Git-155)
[ OK ]  pyusb: 1.3.1
[ OK ]  ftdi_eeprom: v0.17
[ OK ]  arduino-cli: arduino-cli  Version: 1.5.1 Commit: Homebrew Date: 2026-06-05T09:39:33Z
[ OK ]  ESP32 Arduino core: esp32:esp32 3.3.11    3.3.11 esp32
[INFO]  Installing SDFat Arduino library...
Already installed SdFat@2.3.0
[ OK ]  SDFat:
[ OK ]  Adafruit SH110X: Adafruit SH110X
[ OK ]  openFPGALoader: openFPGALoader v1.1.1
[ OK ]  cp210x-cfg: /tmp/cp210x-cfg-n/cp210x-cfg

══ Program FT323H USB-to-JTAG Interface EEPROM ══
Current FT232H: manufacturer='Xilinx'  board_description='LisaFPGA JTAG Interface'  serial='000000'
[ OK ]  FT232H already programmed correctly, skipping!

══ Program CP2102N Serial Interface Name Descriptor ══
[INFO]  CP2102N current product: 'LisaFPGA Serial B'
[ OK ]  CP2102N already programmed correctly, skipping!

══ Discover ESP32 Serial Ports ══
[FAIL]  Failed to find serial port for ESProFile (hub port 2)!
scottlewis@Scotts-MacBook-Pro LisaFPGA-main %

Any ideas?

I have turned the board off and on several times as the instructions say and run the script again but it always fails with the same error. This is what my system is reporting for the USB:
USB 3.1 Bus:

  Location ID:   0x00000000
  Connection Type:   Built-in
  Driver:   AppleT8132USBXHCI

USB HUB:

  Location ID:   0x00100000
  Connection Type:   Removable
  Serial Number:   Not Provided
  Link Speed:   480 Mb/s
  USB Vendor ID:   0x1a86
  USB Product ID:   0x8091
  USB Product Version:   0x1320

LisaFPGA JTAG Interface:

  Location ID:   0x00110000
  Connection Type:   Removable
  Manufacturer:   Xilinx
  Serial Number:   000000
  Link Speed:   480 Mb/s
  USB Vendor ID:   0x0403
  USB Product ID:   0x6014
  USB Product Version:   0x0900

USB JTAG/serial debug unit:

  Location ID:   0x00130000
  Connection Type:   Removable
  Manufacturer:   Espressif
  Serial Number:   AC:A7:04:04:78:68
  Link Speed:   12 Mb/s
  USB Vendor ID:   0x303a
  USB Product ID:   0x1001
  USB Product Version:   0x0101
  Power Allocated:   2.5 W (500 mA)

USB JTAG/serial debug unit:

  Location ID:   0x00120000
  Connection Type:   Removable
  Manufacturer:   Espressif
  Serial Number:   AC:A7:04:04:78:70
  Link Speed:   12 Mb/s
  USB Vendor ID:   0x303a
  USB Product ID:   0x1001
  USB Product Version:   0x0101
  Power Allocated:   2.5 W (500 mA)

LisaFPGA Serial B:

  Location ID:   0x00140000
  Connection Type:   Removable
  Manufacturer:   Silicon Labs
  Serial Number:   9621c27ad41bf111899dafc40f0f12f8
  Link Speed:   12 Mb/s
  USB Vendor ID:   0x10c4
  USB Product ID:   0xea60
  USB Product Version:   0x0100

Quote from: slewis1962 on August 15, 2026, 11:10:53 PMon Debian and get the following error:
...
./program_board.sh: line 151: curl: command not found

Going through this now on a fresh install of ubuntu jammy jellyfish (this variant selected for Vivado compatibility) -- not to the finish line yet, but so far I found the need to
sudo apt install curl
and a bit later I found I needed to
sudo apt install libftdi1-devHaving done those, program_board.sh gets to the point of looking for the board

I had already installed Vivado 2026-1 on this system, so some other dependencies might have been covered. Alex reported development was done on Vivado 2025-2, but it seems to me that 2026-1 is looking workable. Note that the Vivado 'free' node-locked license available at the moment does not support versions prior to 2026-1, which suggests that some future license may not work on 2026-1, so you might get a license now if you think you may want to modify the FPGA design someday.

Quote from: slewis1962 on August 16, 2026, 01:09:16 AMI figured out I had to update pip. After the update I ran it again on my MacBook Pro and now I get this:
scottlewis@Scotts-MacBook-Pro LisaFPGA-main % ./program_board.sh   
[INFO]  Platform: macos

══ Checking / Installing Dependencies ══
[ OK ]  git: git version 2.50.1 (Apple Git-155)
[ OK ]  pyusb: 1.3.1
[ OK ]  ftdi_eeprom: v0.17
[ OK ]  arduino-cli: arduino-cli  Version: 1.5.1 Commit: Homebrew Date: 2026-06-05T09:39:33Z
[ OK ]  ESP32 Arduino core: esp32:esp32 3.3.11    3.3.11 esp32
[INFO]  Installing SDFat Arduino library...
Already installed SdFat@2.3.0
[ OK ]  SDFat:
[ OK ]  Adafruit SH110X: Adafruit SH110X
[ OK ]  openFPGALoader: openFPGALoader v1.1.1
[ OK ]  cp210x-cfg: /tmp/cp210x-cfg-n/cp210x-cfg

══ Program FT323H USB-to-JTAG Interface EEPROM ══
Current FT232H: manufacturer='Xilinx'  board_description='LisaFPGA JTAG Interface'  serial='000000'
[ OK ]  FT232H already programmed correctly, skipping!

══ Program CP2102N Serial Interface Name Descriptor ══
[INFO]  CP2102N current product: 'LisaFPGA Serial B'
[ OK ]  CP2102N already programmed correctly, skipping!

══ Discover ESP32 Serial Ports ══
[FAIL]  Failed to find serial port for ESProFile (hub port 2)!
scottlewis@Scotts-MacBook-Pro LisaFPGA-main %

Any ideas?

Strange, both ESP32s seem to be showing up there. Are you able to connect to ESProFile at 115200 baud using terminal software? And if so, does it print any messages?

Quote from: sigma7 on August 16, 2026, 01:52:08 AM

Quote from: slewis1962 on August 15, 2026, 11:10:53 PMon Debian and get the following error:
...
./program_board.sh: line 151: curl: command not found

Going through this now on a fresh install of ubuntu jammy jellyfish (this variant selected for Vivado compatibility) -- not to the finish line yet, but so far I found the need to

Code Select Expand

sudo apt install curl
and a bit later I found I needed to

Code Select Expand

sudo apt install libftdi1-devHaving done those, program_board.sh gets to the point of looking for the board

I had already installed Vivado 2026-1 on this system, so some other dependencies might have been covered. Alex reported development was done on Vivado 2025-2, but it seems to me that 2026-1 is looking workable. Note that the Vivado 'free' node-locked license available at the moment does not support versions prior to 2026-1, which suggests that some future license may not work on 2026-1, so you might get a license now if you think you may want to modify the FPGA design someday.

I'm shocked that curl wasn't installed by default!

You only need to install Vivado if you want to build the entire project from source, not if you're simply programming your board. I'm sure that @sigma7 knows this, but I just want to clarify in case someone else reads this and thinks that they need to download a 100+ GB piece of software just to program/update their board.

I've checked out a real Twiggy drive with qualified success.

I updated the LisaFPGA to the 2b2e72e version from August 2, 2026.

I also double checked the cabling/connector orientation was going to present the +12 voltage at the correct pins of the Twiggy (mostly because of the anomaly in the Lisa 1 chassis wiring harness where the red stripe is not at pin 1 of the Twiggy connector, but also being cautious to minimize risk to the rare hardware - AFAIK, there haven't been any prior reports on connecting real Twiggies).

My first issue was using a USB-C power source that could supply enough current. It looks like 18 Watts is drawn when a single Twiggy drive is connected and running.

With the Twiggy drive connected to the "Lower" connector, the carriage would move to clamp the disk, then to the home/idle position, and eject when commanded, but the spindle motor did not run.

I tried with the drive connected to the "Upper" connector, and the motor does run. So with this version and no other changes, I think that (but have not fully tested) a Twiggy drive does work connected to the Upper connector. (Thanks Alex!)

I speculated the issue with the Lower connector might be related to the Lite Adapter not being switched out for the version 40 of the I/O ROM, so tried the following change in the last section of Lite_Adapter.sv, after which the motor worked when connected as the Lower drive.

(I don't recommend using this modification as shown, as Alex might know of a more appropriate/efficient way to implement the removal of the Lite_Adapter function when Twiggies are used, so you should wait for Alex to investigate and apply whatever changes are warranted)

    // PWM is latched in a flip-flop clocked by the 5MHz clock by the way
    always_ff @(posedge clk) begin
        if (~IO_ROM_SEL) begin // Use 40 ROM when IO_ROM_SEL is high
            PWM <= MT;
        end else begin
            if (shiftreg < counter) begin
                PWM <= 1'b0;
            end else begin
                PWM <= 1'b1;
            end
        end
    end

Well that's some great news; I was concerned that I had screwed something up much worse than that! I just checked and confirmed that sure enough, I somehow forgot to route MT1 over PWM like I should've done. It's only a problem on the external connector and not the ESFloppy connection since MT1 has its own direct connection there and doesn't have to share the PWM line. I'll try and get it fixed tonight or tomorrow.

@sigma7, let me know if the drives actually work properly and can read/write disks when you get the chance!

I'm happy to announce that the ESFloppy repo is now public and the emulator is fully-functional for both Sony and Twiggy drives! I haven't updated the LisaFPGA readme to reflect this, and program_board.sh doesn't program your board with the new code yet, but you can install the firmware manually using the Arduino IDE if you want to try it out right now. I'm hoping to have the program_board script updated by tonight or tomorrow, along with the Twiggy fix.

https://github.com/alexthecat123/ESFloppy/

Okay, program_board.sh is updated with the new ESFloppy firmware, so clone the latest version of the LisaFPGA repo, connect your LisaFPGA to your computer, run the script, and full floppy emulator functionality will be added to your board!

I still need to do the Twiggy fix that @sigma7 discovered, but that's taking a bit longer than expected because one of the fans in my Linux laptop that I run Vivado on completely killed itself and sounds like a jet engine. It's been a little weird for a while, but it just got 100x worse...

Quote from: AlexTheCat123 on August 18, 2026, 05:47:35 PMOkay, program_board.sh is updated with the new ESFloppy firmware, so clone the latest version of the LisaFPGA repo, connect your LisaFPGA to your computer, run the script, and full floppy emulator functionality will be added to your board!

I jumped in an all went well until:

══ Discover ESP32 Serial Ports ══
[FAIL]  Failed to find serial port for ESProFile (hub port 2)!
justin@MacBookPro LisaFPGA-main %

Eep! What did I do?  The built-in ESProFile still works fine (boots the Lisa normally) and its ACT LED lights up and remains lit. Hmmm...

P.S. https://www.ebay.com/itm/278293940405

 :-X

Quote from: ried on August 18, 2026, 09:45:04 PMEep! What did I do?  The built-in ESProFile still works fine (boots the Lisa normally) and its ACT LED lights up and remains lit. Hmmm...

Try pressing and holding the RESET and BOOT buttons for ESProFile simultaneously, and then releasing RESET, followed by BOOT a second or two later. And then right after you do that, run the script again and see if you have better luck. If ESFloppy fails the same way, try the same trick with it.

Quote from: ried on August 18, 2026, 09:45:04 PMP.S. https://www.ebay.com/itm/278293940405

 :-X

Wow, that's expensive! I wonder if anyone will be willing to pay that much?

Quote from: AlexTheCat123 on August 19, 2026, 12:18:11 AMTry pressing and holding the RESET and BOOT buttons for ESProFile simultaneously, and then releasing RESET, followed by BOOT a second or two later. And then right after you do that, run the script again and see if you have better luck.

First, thank you for the lightning fast reply. Unfortunately, however, no change here. Still fails at that step. Trying a backup laptop just in case.

Edit: My old backup machines are Intel-based and while they installed Xcode properly when prompted, the remaining arguments and utilities called by the script did not install. They're just too old, I'm afraid (Big Sur 11.7.11 and Monterey 12.7.6).

Back to my Apple Silicon MBP, same result after trying different laptop ports and USB cables. Hmmmm.

Quote from: AlexTheCat123 on August 19, 2026, 12:18:11 AM

Quote from: ried on August 18, 2026, 09:45:04 PMP.S. https://www.ebay.com/itm/278293940405

 :-X

Wow, that's expensive! I wonder if anyone will be willing to pay that much?

Sold!

In my opinion these should be trading in the $1500 range..  ;) 

I'm still failing to install the new firmware on my board. On Debian I installed CURL then I had to install Arduino-CLI. After that it still couldn't find Arduino-CLI. I gave up on Debian and installed Ubuntu on a second partition. Same failures as Debian although after installing CURL and Arduino-CLI it was able to get a lot further before failing. Don't remember what failed but then I noticed you updated again with the new floppy firmware. Downloaded that and now this is the error I get:
scott@scott-ThinkPad-T520:~/Downloads/LisaFPGA-main$ sudo ./program_board.sh
[INFO]  Platform: linux

══ Checking / Installing Dependencies ══
[ OK ]  git: git version 2.17.1
[ OK ]  pyusb: 1.0.0
[ OK ]  ftdi_eeprom: v0.17
[ OK ]  arduino-cli: arduino-cli  Version: 1.5.1 Commit: 01f3d4f2b Date: 2026-06-05T10:22:17Z
[ OK ]  ESP32 Arduino core: esp32:esp32 3.3.11    3.3.11 esp32
[ OK ]  SdFat: SdFat 2.3.0
[ OK ]  U8g2: U8g2 2.36.19
[INFO]  Installing openfpgaloader...
Reading package lists... Done
Building dependency tree       
Reading state information... Done
[INFO]  Building openFPGALoader from source...
Cloning into '/tmp/tmp.TbY2rt7ha4'...
remote: Enumerating objects: 299, done.
remote: Counting objects: 100% (299/299), done.
remote: Compressing objects: 100% (257/257), done.
remote: Total 299 (delta 54), reused 167 (delta 36), pack-reused 0 (from 0)
Receiving objects: 100% (299/299), 3.92 MiB | 15.55 MiB/s, done.
Resolving deltas: 100% (54/54), done.
CMake Error: The source directory "/tmp/tmp.TbY2rt7ha4/build" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
scott@scott-ThinkPad-T520:~/Downloads/LisaFPGA-main$

I googled the error and it told me to create that directory. Simple enough. Ran again and it chose another directory to claim it didn't exist. Do I just keep creating directories manually or is there something I'm doing wrong earlier in the process to cause those errors?
Also, I haven't tried to connect via terminal on my MacBook pro yet. Any tricks to that?

Is this a simple case of me not having the right operating systems or computer hardware? Or is it I don't have the right applications installed as in the failure with CURL and Arduino-CLI that I had to manually install?

Quote from: slewis1962 on August 19, 2026, 01:32:20 PMI'm still failing to install the new firmware on my board. On Debian I installed CURL then I had to install Arduino-CLI. After that it still couldn't find Arduino-CLI. I gave up on Debian and installed Ubuntu on a second partition. Same failures as Debian although after installing CURL and Arduino-CLI it was able to get a lot further before failing. Don't remember what failed but then I noticed you updated again with the new floppy firmware. Downloaded that and now this is the error I get:
scott@scott-ThinkPad-T520:~/Downloads/LisaFPGA-main$ sudo ./program_board.sh
[INFO]  Platform: linux

══ Checking / Installing Dependencies ══
[ OK ]  git: git version 2.17.1
[ OK ]  pyusb: 1.0.0
[ OK ]  ftdi_eeprom: v0.17
[ OK ]  arduino-cli: arduino-cli  Version: 1.5.1 Commit: 01f3d4f2b Date: 2026-06-05T10:22:17Z
[ OK ]  ESP32 Arduino core: esp32:esp32 3.3.11    3.3.11 esp32
[ OK ]  SdFat: SdFat 2.3.0
[ OK ]  U8g2: U8g2 2.36.19
[INFO]  Installing openfpgaloader...
Reading package lists... Done
Building dependency tree       
Reading state information... Done
[INFO]  Building openFPGALoader from source...
Cloning into '/tmp/tmp.TbY2rt7ha4'...
remote: Enumerating objects: 299, done.
remote: Counting objects: 100% (299/299), done.
remote: Compressing objects: 100% (257/257), done.
remote: Total 299 (delta 54), reused 167 (delta 36), pack-reused 0 (from 0)
Receiving objects: 100% (299/299), 3.92 MiB | 15.55 MiB/s, done.
Resolving deltas: 100% (54/54), done.
CMake Error: The source directory "/tmp/tmp.TbY2rt7ha4/build" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
scott@scott-ThinkPad-T520:~/Downloads/LisaFPGA-main$

I googled the error and it told me to create that directory. Simple enough. Ran again and it chose another directory to claim it didn't exist. Do I just keep creating directories manually or is there something I'm doing wrong earlier in the process to cause those errors?
Also, I haven't tried to connect via terminal on my MacBook pro yet. Any tricks to that?

On my Linux install, cmake automatically makes the build directory for you when you run it. But perhaps that doesn't happen on your distro for whatever reason. And I bet the reason why manually creating it and then rerunning doesn't work is because it chooses another temp directory the next time around, not the old one that had the build directory in it.

Try adding the line mkdir "$TMP_OFL/build" in between the git clone --depth 1 https://github.com/trabucayre/openFPGALoader.git "$TMP_OFL" and the cmake -S "$TMP_OFL" -B "$TMP_OFL/build" -DCMAKE_BUILD_TYPE=Release in the script. If that helps, then I'll add it to the official version of the script.

Quote from: slewis1962 on August 19, 2026, 01:32:20 PMAlso, I haven't tried to connect via terminal on my MacBook pro yet. Any tricks to that?

No, not really. Just make sure the SERIAL B SOURCE switch is set to USB and make sure that whatever OS you're running on the Lisa is properly configured for serial communications. And that that point it should pretty much just work.

Quote from: ried on August 19, 2026, 12:29:04 AMFirst, thank you for the lightning fast reply. Unfortunately, however, no change here. Still fails at that step. Trying a backup laptop just in case.

Can you try running the command system_profiler SPUSBDataType in your terminal (with the board connected and turned on) and sharing the results? We can check to make sure that your computer is seeing the ESP32 devices properly.

Quote from: Lisa2 on August 19, 2026, 10:27:49 AMSold!

In my opinion these should be trading in the $1500 range..  ;)

Shows how little I know about pricing things!

Quote from: AlexTheCat123 on August 19, 2026, 02:10:12 PMCan you try running the command system_profiler SPUSBDataType in your terminal (with the board connected and turned on) and sharing the results?

Emailed you the results.

Quote from: ried on August 18, 2026, 09:45:04 PMI jumped in an all went well until:

══ Discover ESP32 Serial Ports ══
[FAIL]  Failed to find serial port for ESProFile (hub port 2)!
justin@MacBookPro LisaFPGA-main %

Eep! What did I do?  The built-in ESProFile still works fine (boots the Lisa normally) and its ACT LED lights up and remains lit. Hmmm...

P.S. https://www.ebay.com/itm/278293940405

I am having the same issue on macOS Tahoe 26.5.2. 

MacStudio LisaFPGA % system_profiler SPUSBDataType -json
{
  "SPUSBDataType" : [

  ]
}

It looks like system_profiler is not returning results to locate the devices.  I was able to work around it using ioreg to enumerate the devices.  After making changes listed in the following patch, I successfully programmed my LisaFPGA under macOS.

diff --git a/program_board.sh b/program_board.sh
index b1cfc4c..61840b2 100755
--- a/program_board.sh
+++ b/program_board.sh
@@ -310,69 +310,64 @@ PYEOF
 
 # ── macOS: find /dev/cu.* for ESP32 at hub port N ────────────────────────────
 # We use locationID: each nibble encodes a hub port level.
+# Reads the USB tree from ioreg instead of system_profiler, because
+# SPUSBDataType sometimes returns an empty list even while every device
+# is enumerated and visible in ioreg.
 macos_tty_for_hub_port() {
     local port="$1"   # 2 or 3
     python3 - "$HUB_VID" "$HUB_PID" "$port" <<'PYEOF'
-import subprocess, sys, re, json
+import subprocess, sys, plistlib
 
-hub_vid_str = "0x" + sys.argv[1].upper()
-hub_pid_str = "0x" + sys.argv[2].upper()
+hub_vid = int(sys.argv[1], 16)
+hub_pid = int(sys.argv[2], 16)
 target_port = int(sys.argv[3])
 
 try:
     raw = subprocess.check_output(
-        ['system_profiler', 'SPUSBDataType', '-json'],
-        text=True, stderr=subprocess.DEVNULL
+        ['ioreg', '-a', '-r', '-c', 'IOUSBHostDevice', '-l'],
+        stderr=subprocess.DEVNULL
     )
-    data = json.loads(raw)
+    roots = plistlib.loads(raw)
 except Exception:
     sys.exit(1)
 
-def hub_port_from_location(hub_loc_str, child_loc_str):
-    """Derive the physical hub port from location IDs.
-    macOS encodes each port level as a nibble: hub at 0x01100000 has
-    children at 0x0111xxxx (port 1), 0x0112xxxx (port 2), etc.
-    system_profiler does NOT list _items in port order, so we must
-    compute the port from the location_id rather than using the array index."""
-    try:
-        hub_loc   = int(hub_loc_str.split()[0], 16)
-        child_loc = int(child_loc_str.split()[0], 16)
-        trailing  = (hub_loc & -hub_loc).bit_length() - 1  # trailing zero bits
-        return (child_loc >> (trailing - 4)) & 0xF
-    except Exception:
-        return -1
-
-def scan(items):
-    for item in items:
-        vid = item.get('vendor_id', '').upper().replace('0X', '0x')
-        pid = item.get('product_id', '').upper().replace('0X', '0x')
-        if hub_vid_str in vid and hub_pid_str in pid:
-            hub_loc_str = item.get('location_id', '')
-            for child in item.get('_items', []):
-                child_loc_str = child.get('location_id', '')
-                if hub_port_from_location(hub_loc_str, child_loc_str) != target_port:
-                    continue
-                child_serial = child.get('serial_num', '')
-                if child_serial:
-                    try:
-                        out = subprocess.check_output(
-                            ['ioreg', '-r', '-c', 'IOUSBHostDevice', '-l'],
-                            text=True, stderr=subprocess.DEVNULL
-                        )
-                        m = re.search(
-                            r'"IOCalloutDevice"\s*=\s*"(/dev/[^"]+)"',
-                            out[out.find(child_serial):]
-                        )
-                        if m:
-                            print(m.group(1))
-                            sys.exit(0)
-                    except Exception:
-                        pass
-        sub = item.get('_items', [])
-        if sub:
-            scan(sub)
-
-scan(data.get('SPUSBDataType', []))
+def walk(node):
+    yield node
+    for child in node.get('IORegistryEntryChildren', []):
+        yield from walk(child)
+
+def port_nibble_shift(hub_loc):
+    """macOS locationIDs encode one hub level per nibble. A child on
+    port N of a hub at 0x08320000 sits at 0x0832N000. The port nibble
+    is the one just below the hub's lowest nonzero nibble. Working in
+    whole nibbles (not trailing zero bits) keeps the math right when
+    the hub's own port number is even."""
+    shift = 0
+    while shift < 32 and ((hub_loc >> shift) & 0xF) == 0:
+        shift += 4
+    return shift - 4
+
+for root in roots:
+    for hub in walk(root):
+        if hub.get('idVendor') != hub_vid or hub.get('idProduct') != hub_pid:
+            continue
+        hub_loc = hub.get('locationID')
+        if hub_loc is None:
+            continue
+        shift = port_nibble_shift(hub_loc)
+        if shift < 0:
+            continue
+        want_loc = hub_loc | (target_port << shift)
+        for child in walk(hub):
+            if child is hub or child.get('locationID') != want_loc:
+                continue
+            if 'idVendor' not in child:
+                continue
+            for sub in walk(child):
+                dev = sub.get('IOCalloutDevice')
+                if dev:
+                    print(dev)
+                    sys.exit(0)
 sys.exit(1)
 PYEOF
 }




If opened PR #2 with my changes if it helps.

Quick question Alex, what Linux Distro are you running? My Thinkpad T520 is running an i7 with 4GB RAM so I'm not running the latest Debian or Ubuntu. I thought I'd install a VM in my M4 Apple Silicon Mac and have better luck. Should the script complete properly if I'm running the latest version of Linux? I'll have to try tomorrow as I'm currently at work. If none of that works I'll try some of the other suggestions. I'll probably try them anyway as I'm curious. I suppose I should give up trying to compile on my old Thinkpad.

Quote from: coffeemuse on August 19, 2026, 03:02:37 PM

Quote from: ried on August 18, 2026, 09:45:04 PMI jumped in an all went well until:

══ Discover ESP32 Serial Ports ══
[FAIL]  Failed to find serial port for ESProFile (hub port 2)!
justin@MacBookPro LisaFPGA-main %

Eep! What did I do?  The built-in ESProFile still works fine (boots the Lisa normally) and its ACT LED lights up and remains lit. Hmmm...

P.S. https://www.ebay.com/itm/278293940405

I am having the same issue on macOS Tahoe 26.5.2. 

Code Select Expand

MacStudio LisaFPGA % system_profiler SPUSBDataType -json
{
  "SPUSBDataType" : [

  ]
}

It looks like system_profiler is not returning results to locate the devices.  I was able to work around it using ioreg to enumerate the devices.  After making changes listed in the following patch, I successfully programmed my LisaFPGA under macOS.

Code Select Expand

diff --git a/program_board.sh b/program_board.sh
index b1cfc4c..61840b2 100755
--- a/program_board.sh
+++ b/program_board.sh
@@ -310,69 +310,64 @@ PYEOF
 
 # ── macOS: find /dev/cu.* for ESP32 at hub port N ────────────────────────────
 # We use locationID: each nibble encodes a hub port level.
+# Reads the USB tree from ioreg instead of system_profiler, because
+# SPUSBDataType sometimes returns an empty list even while every device
+# is enumerated and visible in ioreg.
 macos_tty_for_hub_port() {
     local port="$1"   # 2 or 3
     python3 - "$HUB_VID" "$HUB_PID" "$port" <<'PYEOF'
-import subprocess, sys, re, json
+import subprocess, sys, plistlib
 
-hub_vid_str = "0x" + sys.argv[1].upper()
-hub_pid_str = "0x" + sys.argv[2].upper()
+hub_vid = int(sys.argv[1], 16)
+hub_pid = int(sys.argv[2], 16)
 target_port = int(sys.argv[3])
 
 try:
     raw = subprocess.check_output(
-        ['system_profiler', 'SPUSBDataType', '-json'],
-        text=True, stderr=subprocess.DEVNULL
+        ['ioreg', '-a', '-r', '-c', 'IOUSBHostDevice', '-l'],
+        stderr=subprocess.DEVNULL
     )
-    data = json.loads(raw)
+    roots = plistlib.loads(raw)
 except Exception:
     sys.exit(1)
 
-def hub_port_from_location(hub_loc_str, child_loc_str):
-    """Derive the physical hub port from location IDs.
-    macOS encodes each port level as a nibble: hub at 0x01100000 has
-    children at 0x0111xxxx (port 1), 0x0112xxxx (port 2), etc.
-    system_profiler does NOT list _items in port order, so we must
-    compute the port from the location_id rather than using the array index."""
-    try:
-        hub_loc   = int(hub_loc_str.split()[0], 16)
-        child_loc = int(child_loc_str.split()[0], 16)
-        trailing  = (hub_loc & -hub_loc).bit_length() - 1  # trailing zero bits
-        return (child_loc >> (trailing - 4)) & 0xF
-    except Exception:
-        return -1
-
-def scan(items):
-    for item in items:
-        vid = item.get('vendor_id', '').upper().replace('0X', '0x')
-        pid = item.get('product_id', '').upper().replace('0X', '0x')
-        if hub_vid_str in vid and hub_pid_str in pid:
-            hub_loc_str = item.get('location_id', '')
-            for child in item.get('_items', []):
-                child_loc_str = child.get('location_id', '')
-                if hub_port_from_location(hub_loc_str, child_loc_str) != target_port:
-                    continue
-                child_serial = child.get('serial_num', '')
-                if child_serial:
-                    try:
-                        out = subprocess.check_output(
-                            ['ioreg', '-r', '-c', 'IOUSBHostDevice', '-l'],
-                            text=True, stderr=subprocess.DEVNULL
-                        )
-                        m = re.search(
-                            r'"IOCalloutDevice"\s*=\s*"(/dev/[^"]+)"',
-                            out[out.find(child_serial):]
-                        )
-                        if m:
-                            print(m.group(1))
-                            sys.exit(0)
-                    except Exception:
-                        pass
-        sub = item.get('_items', [])
-        if sub:
-            scan(sub)
-
-scan(data.get('SPUSBDataType', []))
+def walk(node):
+    yield node
+    for child in node.get('IORegistryEntryChildren', []):
+        yield from walk(child)
+
+def port_nibble_shift(hub_loc):
+    """macOS locationIDs encode one hub level per nibble. A child on
+    port N of a hub at 0x08320000 sits at 0x0832N000. The port nibble
+    is the one just below the hub's lowest nonzero nibble. Working in
+    whole nibbles (not trailing zero bits) keeps the math right when
+    the hub's own port number is even."""
+    shift = 0
+    while shift < 32 and ((hub_loc >> shift) & 0xF) == 0:
+        shift += 4
+    return shift - 4
+
+for root in roots:
+    for hub in walk(root):
+        if hub.get('idVendor') != hub_vid or hub.get('idProduct') != hub_pid:
+            continue
+        hub_loc = hub.get('locationID')
+        if hub_loc is None:
+            continue
+        shift = port_nibble_shift(hub_loc)
+        if shift < 0:
+            continue
+        want_loc = hub_loc | (target_port << shift)
+        for child in walk(hub):
+            if child is hub or child.get('locationID') != want_loc:
+                continue
+            if 'idVendor' not in child:
+                continue
+            for sub in walk(child):
+                dev = sub.get('IOCalloutDevice')
+                if dev:
+                    print(dev)
+                    sys.exit(0)
 sys.exit(1)
 PYEOF
 }




If opened PR #2 with my changes if it helps.

Yeah, I think I can explain why that's the case! I'm still running Sequoia and never tested with Tahoe, so I bet they changed how system_profiler returns the results in between the two. I'll test your code here in a few minutes. Let's just hope that this fix doesn't break things for me on Sequoia. I wanted to hold out for as long as possible, but perhaps this is my cue to upgrade...

Quote from: slewis1962 on August 19, 2026, 04:25:20 PMQuick question Alex, what Linux Distro are you running? My Thinkpad T520 is running an i7 with 4GB RAM so I'm not running the latest Debian or Ubuntu. I thought I'd install a VM in my M4 Apple Silicon Mac and have better luck. Should the script complete properly if I'm running the latest version of Linux? I'll have to try tomorrow as I'm currently at work. If none of that works I'll try some of the other suggestions. I'll probably try them anyway as I'm curious. I suppose I should give up trying to compile on my old Thinkpad.

I'm running Linux Mint 22 on actual x86 hardware (no VM). Mint should be pretty much identical to Ubuntu, so either of those should work fine. Hopefully we can get the Mac problems solved and you won't even need to worry about this though!

@coffeemuse's modified script seems to work great, so I went ahead and pushed it. Hopefully that solves everyone's problems; give it a try and let me know. I also added the line that we talked about earlier that might fix the openFPGALoader build problems on Linux, but this of course hasn't been tested yet. It can't hurt to be added though, so might as well.

Works for me now, woohoo! Thanks gang.

Edit: Trying out the new ESFloppy now. Is it intentional that it remains powered on by the current coming from the attached HDMI display? If I pull the LisaFPGA's USB-C power cable, the ESFloppy remains on unless I also remove the power cable from the attached monitor.

Edit 2: This is wild. Twiggy emulation totally works! I used Selector to create a new 5MB drive image and am now installing LOS 2.0 from the Twiggy disk images using the ESFloppy. Super cool.

Edit 3: The second Twiggy disk threw an error during the installation process ("The Lisa Office System startup software could not be installed because of difficulties reading the master diskette. Try running the disk drive diagnostic or using another Office System diskette. Refer to the Lisa Owner's Guide, Section G, Troubleshooting, under LisaTest."). The disk image should be fine, as its physical source disk worked just fine to install LOS 2.0 on a real Lisa 1. Hmmm.

Edit 4: The issue was resolved after rebooting the LisaFPGA. I wonder if this is an issue with the microSD card? The one in the ESFloppy is a SanDisk card but it's over 10 years old, so that may have been the cause. LOS 2.0 is now up and running after the Twiggy installation. ESProFile image attached in case it's helpful to someone (no apps installed yet).

Nice, I'm glad that was the problem!

That behavior is not intentional, but it aligns with what other people have told me. There's a 5V power line on the HDMI connector that's supposed to be supplied to the HDMI sink (the monitor) by the HDMI source (us). From what I understand, the monitor isn't supposed to supply any power of its own on this line, and mine doesn't which is why I didn't discover this during testing, but it appears as if a lot of other peoples' monitors do and that backflow is keeping the 5V and 3.3V rails just alive enough to keep the OLED and a few LEDs on. Don't worry about it though; it's not going to break anything.

Who's ready for some Twiggy COBOL? "Here we go..." :D

Pretty awesome to be able to experiment with Twiggy disk images without exercising and potentially damaging the original media. Thank you, Alex!

P.S. COBOL Workshop 1.0 ESProFile 5MB drive image attached, just in case someone wants to get down like that.

At last a chance to come back from that time in 1999 when some hoser sniped me on a Cobol Workshop 1.0 auction on eBay!

Quote from: stepleton on August 20, 2026, 03:35:44 AMAt last a chance to come back from that time in 1999...

And your implementation is free! He who laughs last, laughs best  :P

I know this is probably irrelevant at this point but I wanted to try one of your suggestions before I gave up on Linux.

"Try adding the line mkdir "$TMP_OFL/build" in between the git clone --depth 1 https://github.com/trabucayre/openFPGALoader.git "$TMP_OFL" and the cmake -S "$TMP_OFL" -B "$TMP_OFL/build" -DCMAKE_BUILD_TYPE=Release in the script. If that helps, then I'll add it to the official version of the script."

I did this on the version of the script posted several days ago. I get this error:
══ Checking / Installing Dependencies ══
[ OK ]  git: git version 2.17.1
[ OK ]  pyusb: 1.0.0
[ OK ]  ftdi_eeprom: v0.17
[ OK ]  arduino-cli: arduino-cli  Version: 1.5.1 Commit: 01f3d4f2b Date: 2026-06-05T10:22:17Z
[ OK ]  ESP32 Arduino core: esp32:esp32 3.3.11    3.3.11 esp32
[ OK ]  SdFat: SdFat 2.3.0
[ OK ]  U8g2: U8g2 2.36.19
[INFO]  Installing openfpgaloader...
Reading package lists... Done
Building dependency tree       
Reading state information... Done
[INFO]  Building openFPGALoader from source...
Cloning into '/tmp/tmp.EHNiBrMpCc'...
remote: Enumerating objects: 299, done.
remote: Counting objects: 100% (299/299), done.
remote: Compressing objects: 100% (257/257), done.
remote: Total 299 (delta 54), reused 167 (delta 36), pack-reused 0 (from 0)
Receiving objects: 100% (299/299), 3.92 MiB | 15.02 MiB/s, done.
Resolving deltas: 100% (54/54), done.
mkdir: cannot create directory 'TMP_OFL/build': No such file or directory
scott@scott-ThinkPad-T520:~/Downloads/LisaFPGA-main$

Anyway, I gave up on Linux and pulled out my MacBook Pro and ran the latest script posted last night. It was successful! Now this weekend I'll try out my Twiggy drives. Thanks again for a great device!

Quote from: stepleton on August 20, 2026, 03:35:44 AMAt last a chance to come back from that time in 1999 when some hoser sniped me on a Cobol Workshop 1.0 auction on eBay!

What did it go for back then? I wasn't buying Twiggy stuff at that time, I got my Lisa 1 around May 2002, but I did get quite a bit of Twiggy software during the mid 2000's. I may even have Cobol. I know I have Basic plus the Workshop. I also bought Fortran on Twiggy plus Xenix on Twiggy. I'll have to look and see if I have Cobol.
Has anyone archived any of those Twiggy disks that you know of?

Quote from: slewis1962 on August 20, 2026, 01:52:35 PMI may even have Cobol. I know I have Basic plus the Workshop. I also bought Fortran on Twiggy plus Xenix on Twiggy. I'll have to look and see if I have Cobol.
Has anyone archived any of those Twiggy disks that you know of?

I archived COBOL 1.0 last year, and it's available here on LisaList2 (https://lisalist2.com/index.php/topic,671.0.html). That is the first time anyone has done so and made it available to the community.

BASIC Plus 1.0 on Twiggy has yet to be archived. If you have that set of disks, we would sure love to archive those.  :)

According to the Apple Lisa - Software Release List (https://docs.google.com/spreadsheets/d/1STG0Le_8dMHRLf026x6YfXzRQm2hD0igeZVb2Hx0Lxo/edit?gid=0#gid=0), Fortran '77 was mentioned in a brochure as a potential Apple product but has never been seen publicly. There was, however, an SVS FORTRAN release for UniPlus+ in 1983 (by UniSoft). There may have also been an RM/FORTRAN release for UniPlus+ and XENIX by Ryan-McFarland Corp. I am not aware of any Twiggy disk archives of any of these.

Quote from: slewis1962 on August 20, 2026, 01:52:35 PMplus Xenix on Twiggy

Did anyone else know that this existed? I had no clue that there was ever a Twiggy Xenix release! Please archive it!!!

Quote from: slewis1962 on August 20, 2026, 01:52:35 PMWhat did it go for back then? I wasn't buying Twiggy stuff at that time, I got my Lisa 1 around May 2002, but I did get quite a bit of Twiggy software during the mid 2000's. I may even have Cobol. I know I have Basic plus the Workshop. I also bought Fortran on Twiggy plus Xenix on Twiggy. I'll have to look and see if I have Cobol.
Has anyone archived any of those Twiggy disks that you know of?

I think it was a bit over $200. I was a college student at the time, so it would have been quite dear, but even then it was more the sniping than the price that shut me out.

One of my goals had been to archive the disks, but obviously I couldn't do that. I was also excited to be able to write code for the Lisa 1, as at the time there was no widely available Workshop of any kind, and I didn't really think about writing bare-metal assembly like I do now (it would have been a steep learning curve for me back then, I think). I wasn't thrilled about having to write Cobol, but you take what you can get. Or can't get as the case may be.

But I got a chance later on to achieve a similar goal. I remain proud that the 1.0 images of the Pascal Workshop on Bitsavers are from my own copy, purchased still shrink-wrapped about fifteen years later. That was a lucky find!

Quote from: AlexTheCat123 on August 20, 2026, 03:44:51 PM

Quote from: slewis1962 on August 20, 2026, 01:52:35 PMplus Xenix on Twiggy

Did anyone else know that this existed? I had no clue that there was ever a Twiggy Xenix release! Please archive it!!!

Here are photos of some of my Twiggy disks.
(https://i0.wp.com/applelisa.net/wp-content/uploads/2022/10/IMG_5749-scaled.jpg?resize=768%2C1024&ssl=1)
Xenix Payroll, Xenix Accounts Payable, Xenix Accounts Receivable, and Xenix General Ledger.
(https://i0.wp.com/applelisa.net/wp-content/uploads/2022/10/IMG_5748-scaled.jpg?resize=768%2C1024&ssl=1)
Xenix Team Manager Programs, Xenix Team Manager Date Files, Xenix Version 2.3 Boot Diskette, and Xenix Version 2.3 Backup Boot Diskette.
These photos were taken in October 2022 so I'll have to dig out the disks from my storage area in the basement.

Here's some more Alpha pre release software.
(https://i0.wp.com/applelisa.net/wp-content/uploads/2022/10/IMG_5743-scaled.jpg?resize=768%2C1024&ssl=1)
Basic 0 and Basic 1 A5 release, Cobol 0 and Cobol 1 A5 release, and another set of Basic 0 and Basic 1 A5 release.

Any ideas about this one?
(https://i0.wp.com/applelisa.net/wp-content/uploads/2022/10/IMG_5747-scaled-e1666844409310.jpg?resize=768%2C1024&ssl=1)
An Apple /// diskware program diskette.

Here in the lower right corner is an A5 pre-release of Lisa List along with other various disks.
(https://i0.wp.com/applelisa.net/wp-content/uploads/2022/10/IMG_5740-scaled.jpg?resize=768%2C1024&ssl=1)
I have other disks also along with I think more A5 pre-release disks but I'm not positive on that. Everything is boxed up in my storage area not easily accessible.

I actually used BLU about 20 years ago to archive my Basic disks but one had several bad sectors. Since then I found another set of Basic, other than the A5 release disks, but have not had the time or area to set everything up to archive. I'm hoping with the new FPGA board that I can start archiving sooner than later.
Also, when I first got my Lisa 1 it had no working boot disks. I bought the entire set of tools including Lisa Terminal but the Office System diskettes didn't work. I found a copy of Fortran on Ebay along with the manual and that bootable diskette was how I verified my system worked. Shortly after that I was able to get a working set of the OS disks. This was all in mid 2002.
I guess I also need to figure out how to set up a serial transfer in order to use BLU again. In the old days I made a cable and used HyperTerminal on windows 95 or 98.

*EDIT - I guess I was wrong with my dates. I guess it was released in 2011. My bad! I archived some disks in June of 2012.

Holy macaroni.  :o  You even have the Twiggy Alignment Disk. Would you consider allowing one of us to archive these? Where are you located?

I have the Pascal A5+ release (which is also available for download (https://lisalist2.com/index.php/topic,665.0.html) in the Files section) and you have both BASIC and COBOL. That is incredible.

sigma7 has developed a a new version of BLU (https://lisalist2.com/index.php/board,13.0.html) that can use multiple damaged Twiggy disks to "fill in" the bad sectors of a disk with data from another to create a complete image. It worked well when I backed up the BPI System Install (https://lisalist2.com/index.php/topic,412.msg4941.html#msg4941) disk (I had two copies, each with a couple of bad sectors).

We would love to archive these.

Quote from: slewis1962 on August 21, 2026, 11:21:43 AMAny ideas about this one?

An Apple /// diskware program diskette.

I suspect this is related to the Apple ///'s Twiggy disk drive controller card, meant to be used with the Apple ///'s unreleased external UniFile and DuoFile Twiggy disk drives. These never shipped commercially, though a few examples are now in private hands. Note the Z8 with its piggyback ROM in the top-left.

Bad news, I just looked at what I thought were a second set of Basic diskettes and they had no diskettes in the binders. These binders must be what the non working copies came from. Maybe the other set of binders which I'm fairly certain I saw several years ago in storage have another set of diskettes. I'll post when and if I find the other set.
(https://i0.wp.com/applelisa.net/wp-content/uploads/2026/08/IMG_9458-scaled.jpg?resize=768%2C1024&ssl=1)

Quote from: ried on August 21, 2026, 11:39:04 AMHoly macaroni.  :o  You even have the Twiggy Alignment Disk. Would you consider allowing one of us to archive these? Where are you located?

I have the Pascal A5+ release (which is also available for download (https://lisalist2.com/index.php/topic,665.0.html) in the Files section) and you have both BASIC and COBOL. That is incredible.

sigma7 has developed a a new version of BLU (https://lisalist2.com/index.php/board,13.0.html) that can use multiple damaged Twiggy disks to "fill in" the bad sectors of a disk with data from another to create a complete image. It worked well when I backed up the BPI System Install (https://lisalist2.com/index.php/topic,412.msg4941.html#msg4941) disk (I had two copies, each with a couple of bad sectors).

We would love to archive these.

Can the alignment disks be archived? Or are you talking about the other disks? I'll fire up my system eventually once I get the twiggies working with the FPGA board and try to archive them locally. I have to locate the disks again. I have several rooms in the basement packed to the ceiling with storage. Not too well organized at the moment. We need to clean out and get rid of all my boys stuff, they're 21 now so we have quite a bit of old toys and clothes that we should have gotten rid of years ago.
If I can't find a second set of the BASIC diskettes it may be a moot point. I will try and archive the original set again once I locate them. I have no idea if my A5 release disks are working or not.

Quote from: ried on August 21, 2026, 11:55:36 AM

Quote from: slewis1962 on August 21, 2026, 11:21:43 AMAny ideas about this one?

An Apple /// diskware program diskette.

I suspect this is related to the Apple ///'s Twiggy disk drive controller card, meant to be used with the Apple ///'s unreleased external UniFile and DuoFile Twiggy disk drives. These never shipped commercially, though a few examples are now in private hands. Note the Z8 with its piggyback ROM in the top-left.

I have two of those.
(https://i0.wp.com/applelisa.net/wp-content/uploads/2023/10/AIII-IC-both-boards-scaled.jpg?resize=1024%2C311&ssl=1)
One is dated 1982 and the other is dated 1983.

(https://i0.wp.com/applelisa.net/wp-content/uploads/2023/10/AIII-IC-1982_2-scaled.jpg?resize=1024%2C575&ssl=1)
(https://i0.wp.com/applelisa.net/wp-content/uploads/2023/10/AIII-IC-1983_1-scaled.jpg?resize=768%2C442&ssl=1)
Here are some better photos.

Quote from: ried on August 21, 2026, 11:39:04 AMHoly macaroni.  :o  You even have the Twiggy Alignment Disk. Would you consider allowing one of us to archive these? Where are you located?

I have the Pascal A5+ release (which is also available for download (https://lisalist2.com/index.php/topic,665.0.html) in the Files section) and you have both BASIC and COBOL. That is incredible.

sigma7 has developed a a new version of BLU (https://lisalist2.com/index.php/board,13.0.html) that can use multiple damaged Twiggy disks to "fill in" the bad sectors of a disk with data from another to create a complete image. It worked well when I backed up the BPI System Install (https://lisalist2.com/index.php/topic,412.msg4941.html#msg4941) disk (I had two copies, each with a couple of bad sectors).

We would love to archive these.

I'm pretty sure I have some BPI disks although that may be from the 3.5" systems. I bought a Lisa 2/10 from my former employer in 1993 or 1994 which had the full 7/7 plus Xenix on 3.5" disks. I think that may be where I remember seeing the BPI disks.

Quote from: slewis1962 on August 21, 2026, 12:06:08 PM

Quote from: ried on August 21, 2026, 11:39:04 AMHoly macaroni.  :o  ...
We would love to archive these.

Can the alignment disks be archived? Or are you talking about the other disks?

I mean all of them. You have quite a few disks that have never been archived, at least publicly, and these would go a long way toward preservation of the platform. If we can be of any assistance in archiving these, there are a few folks here who would be more than happy to lend a hand. (https://lisalist2.com/index.php/topic,99.0.html)

Quote from: ried on August 21, 2026, 12:16:24 PM

Quote from: slewis1962 on August 21, 2026, 12:06:08 PM

Quote from: ried on August 21, 2026, 11:39:04 AMHoly macaroni.  :o  ...
We would love to archive these.

Can the alignment disks be archived? Or are you talking about the other disks?

I mean all of them. You have quite a few disks that have never been archived, at least publicly, and these would go a long way toward preservation of the platform. If we can be of any assistance in archiving these, there are a few folks here who would be more than happy to lend a hand. (https://lisalist2.com/index.php/topic,99.0.html)

I just need to figure out how to set up a serial connection from the FPGA to my desktop computer. Of course I need to test out my Twiggy drives with the board. Did Alex get the changes done to allow both drives to work?

Quote from: slewis1962 on August 21, 2026, 01:08:20 PMI just need to figure out how to set up a serial connection from the FPGA to my desktop computer. Of course I need to test out my Twiggy drives with the board. Did Alex get the changes done to allow both drives to work?

I have a newer version with YModem and other features... FYI

It will work through a USB cable and Tera Term

Quote from: slewis1962 on August 21, 2026, 12:09:07 PMI have two of those

No way, you have TWO Apple /// Twiggy cards? That's actually insane!

Quote from: ried on August 21, 2026, 12:16:24 PMI mean all of them. You have quite a few disks that have never been archived, at least publicly, and these would go a long way toward preservation of the platform. If we can be of any assistance in archiving these, there are a few folks here who would be more than happy to lend a hand. (https://lisalist2.com/index.php/topic,99.0.html)

Agreed, we need to get all of these disks backed up if possible. The Twiggy alignment disks may not be possible if they have data written outside the normal readable area of the disk or if it's not standard GCR-encoded sector data, but they're definitely worth a try. Unless you have Twiggy archival experience, it's probably a good idea to collaborate with someone like @ried, @sigma7, or @stepleton to maximize the chances of recovering the data from all of the disks.

Quote from: slewis1962 on August 21, 2026, 01:08:20 PMDid Alex get the changes done to allow both drives to work?

Sorry, I haven't gotten around to that quite yet! School just started back up and I've been busy. Hopefully I'll get it done today or tomorrow.

Quote from: slewis1962 on August 21, 2026, 11:33:27 AMI actually used BLU about 20 years ago to archive my Basic disks but one had several bad sectors.

I have a set of Basic disks, one had a bad sector in the catalog area that I think is repaired (see https://lisalist2.com/index.php/topic,558.msg3940.html (https://lisalist2.com/index.php/topic,558.msg3940.html)), but I haven't got around to testing it. Now that it can be tested with the ESFloppy, I'll upload it for someone else to try. If that fails, perhaps it is the same as yours and the bad sectors can be merged.

QuoteDid Alex get the changes done to allow both drives to work?

I'm hoping that one will have the option (without cutting traces) of emulating either one or both Twiggies with the ESFloppy. It will be much faster to archive Twiggies if they can be read with the LisaFPGA using a real drive, then writing to an image on the ESFloppy.

Quote from: sigma7 on August 21, 2026, 02:53:26 PMI'm hoping that one will have the option (without cutting traces) of emulating either one or both Twiggies with the ESFloppy. It will be much faster to archive Twiggies if they can be read with the LisaFPGA using a real drive, then writing to an image on the ESFloppy.

I think the easiest way to do this would be to simply leave everything as it is right now and then use the FLOPPY DRIVE SOURCE switch to accomplish something like this. Flip it to the EXT position to select your real Twiggy drives and back them up to RAM using BLU. Then flip it to the ESFLOPPY position (without rebooting the board or anything) and copy everything to an emulated image.

Quote from: AlexTheCat123 on August 18, 2026, 12:52:14 PM@sigma7, let me know if the drives actually work properly and can read/write disks

It looks like reading is working, but not writing. As writing could be a problem with my drive, someone else should confirm.

When reading a Twiggy with BLU, the rate of progress is dramatically improved at the two high speeds of the Lisa FPGA... it is actually very impressive.

Twiggies have a 2:1 interleave, and at the normal speed IRL, reading consecutive sectors results in having to wait a full rotation of the disk. At the regular speed and next higher of the LisaFPGA, this is still the case, but at the two higher speeds, it looks like consecutive sectors can be read without the full rotation, so reading a full Twiggy is much much faster.

As a result, archiving and using Twiggies can be much faster than before, and archiving will be faster still if the serial transfer can be eliminated by writing the image to the ESFloppy.

The current symptom when trying to format a Twiggy with BLU using the LisaFPGA is usually an immediate failure with error code 1C "Unable to Write Calibration". Switching to a different CPU frequency and retrying sometimes results in it getting further, stepping through a few tracks then failing with error code 15 "Unable to Verify". Once I saw error 1A "Unable to Find Calibration". Changing the CPU frequency might not be relevant, but it seems like it reduces the number of retries to see it get past the first track.

I observed the supply voltages at the drive are well below spec, partially due to the USB-C supply drooping, and part from resistive drop getting power over to the drive. About half of the resistive drop was in the provided cabling and half from routing across the board.

I tried using very short cables (about 5" each), and when there was still no success, I provided power to the drive separately, still without success. So I still don't know if any power supply improvements are required for writing to work.

It looks to me that the spec for USB-C power provision maxes out at 3A when 5V is configured, so (to use real Twiggies) one might need either a non-standard +5V power supply with a USB-C connector or an alternate power connector (eg. holes to solder wires or a 4 pin molex or a terminal block).

I'm supposing the drop in +12V is partially due to the internal layer trace resistance and the small vias. If revising the design, I suggest that a wider +12 trace and redundant vias would help (on both the LisaFPGA and the Twiggy breakout). I'd widen the internal +5 traces and add redundant vias there too; I expect the copper of the inner layers is pretty light.

I'll try to extract some further detail about how the writing is failing in due course.

Quote from: sigma7 on August 21, 2026, 05:09:50 PMI'll try to extract some further detail about how the writing is failing

Switching back to A8 I/O ROM:

Using a real Sony SuperDrive MP-F75W-12G (original to a Quadra 700 I think), I was able to format SS and DS.

However, using a real Sony SS 400k drive OA-D34V (actually original to my Lisa 2), there are numerous misbehaviours, ranging from often not recognizing a disk is in place, not making any progress formatting when it finally does, not being able to read, thinking it has ejected when it hasn't. I tested the drive In a Real Lisa (IRL) and it is fine, failing with the LisaFPGA before and after the successful test IRL.

I'm supposing there are numerous 400k drives about so hoping this might be reproduced rather than remaining in my imagination.

DC supply voltages appear ok with the 3.5" drives (didn't check for ripple/noise).

I've also observed an issue with slow xmodem transfers to a modern computer from LisaFPGA running BLU. The packet data seems to go quickly, but there is a long delay before the packet is recognized and another is sent. This occurs with both the USB option and the DB25 option. The transfer goes the other way fine, and its the same software I've used before IRL. Any similar/differing experiences to report?

IIRC the old 400k OA-D34V required a PWM signal on pin 20 to set the motor speed. The later slimline drives ignored pin 20 and derived the motor speed internally from the head position.

This could be something worth looking after.

Okay, things are updated to fix the Twiggy MT/PWM bug, so anyone with Twiggy drives should be able to update their boards and have both the upper and lower drives work (or at least attempt to work).

Quote from: sigma7 on August 21, 2026, 05:09:50 PMIt looks like reading is working, but not writing. As writing could be a problem with my drive, someone else should confirm.

That's really strange. Can someone else test and confirm with their Twiggy drives so we can confirm that this isn't just an isolated issue with @sigma7's Twiggies?

Quote from: sigma7 on August 22, 2026, 03:15:37 AMHowever, using a real Sony SS 400k drive OA-D34V (actually original to my Lisa 2), there are numerous misbehaviours, ranging from often not recognizing a disk is in place, not making any progress formatting when it finally does, not being able to read, thinking it has ejected when it hasn't. I tested the drive In a Real Lisa (IRL) and it is fine, failing with the LisaFPGA before and after the successful test IRL.

I just tested with one of my 400K drives (also pulled straight out of a Lisa) and things work just fine. I can read, write, and format without issue. I do recall having some issues similar to yours when using a particular cable. When I use the cable that came with my Floppy Emu (I use it a lot because it's really long), things work fine, but I believe that when I used the cable that went between an 800K drive and the Lite Adapter on one of my Lisas, I had symptoms that were really similar to yours. I'm not exactly sure what the difference is between the two cables, but there's a note on top of that 800K drive that says "this drive MUST be used with the cable that was included with the drive", so clearly there is some kind of difference. Perhaps try a different cable?

Quote from: patrick on August 22, 2026, 04:37:54 AMIIRC the old 400k OA-D34V required a PWM signal on pin 20 to set the motor speed. The later slimline drives ignored pin 20 and derived the motor speed internally from the head position.

I'm already generating the PWM signal, and things work with my real 400K drive, so this shouldn't be a problem.

Here are some of the Twiggy images I made starting in 2012. If anyone is interested how should I post them? Zip archive? As is?
I have more but these were all I copied to my current computer. I'll have to find the others or re-create them from the original disks.
(https://applelisa.net/wp-content/uploads/2026/08/Twiggies.png)

Quote from: slewis1962 on August 21, 2026, 01:08:20 PM

Quote from: ried on August 21, 2026, 12:16:24 PM

Quote from: slewis1962 on August 21, 2026, 12:06:08 PM

Quote from: ried on August 21, 2026, 11:39:04 AMHoly macaroni.  :o  ...
We would love to archive these.

Can the alignment disks be archived? Or are you talking about the other disks?

I mean all of them. You have quite a few disks that have never been archived, at least publicly, and these would go a long way toward preservation of the platform. If we can be of any assistance in archiving these, there are a few folks here who would be more than happy to lend a hand. (https://lisalist2.com/index.php/topic,99.0.html)

I just need to figure out how to set up a serial connection from the FPGA to my desktop computer. Of course I need to test out my Twiggy drives with the board. Did Alex get the changes done to allow both drives to work?

I successfully connected to both the LisaFPGA and the ESProfile today over serial. I tried the other day with a program called CoolTerm but wasn't able to find the boards. Today I used the built in screen command via the terminal which worked. I'll have to do some tinkering to see what all I can do. First I need to connect my Twiggy drives which it sounds like the new firmware will work with both.

Quote from: ried on August 20, 2026, 03:31:18 PM

Quote from: slewis1962 on August 20, 2026, 01:52:35 PMI may even have Cobol. I know I have Basic plus the Workshop. I also bought Fortran on Twiggy plus Xenix on Twiggy. I'll have to look and see if I have Cobol.
Has anyone archived any of those Twiggy disks that you know of?

I archived COBOL 1.0 last year, and it's available here on LisaList2 (https://lisalist2.com/index.php/topic,671.0.html). That is the first time anyone has done so and made it available to the community.

BASIC Plus 1.0 on Twiggy has yet to be archived. If you have that set of disks, we would sure love to archive those.  :)

According to the Apple Lisa - Software Release List (https://docs.google.com/spreadsheets/d/1STG0Le_8dMHRLf026x6YfXzRQm2hD0igeZVb2Hx0Lxo/edit?gid=0#gid=0), Fortran '77 was mentioned in a brochure as a potential Apple product but has never been seen publicly. There was, however, an SVS FORTRAN release for UniPlus+ in 1983 (by UniSoft). There may have also been an RM/FORTRAN release for UniPlus+ and XENIX by Ryan-McFarland Corp. I am not aware of any Twiggy disk archives of any of these.

As you can see in my above post I archived RM-Fortran June 23, 2012. If I am remembering correctly I was able to use that Twiggy diskette to test out my Lisa way back in mid 2002 as my OS diskettes bought with my Lisa 1 did not work.
Some of my images were I believe RAW. I looked at one with a Hex Editor and it looks like a BLU header at the top. I'm assuming that should work. I'll have to try on my FPGA board tomorrow sometime.

Quote from: AlexTheCat123 on August 21, 2026, 02:34:05 PM

Quote from: slewis1962 on August 21, 2026, 12:09:07 PMI have two of those

No way, you have TWO Apple /// Twiggy cards? That's actually insane!

Quote from: ried on August 21, 2026, 12:16:24 PMI mean all of them. You have quite a few disks that have never been archived, at least publicly, and these would go a long way toward preservation of the platform. If we can be of any assistance in archiving these, there are a few folks here who would be more than happy to lend a hand. (https://lisalist2.com/index.php/topic,99.0.html)

Agreed, we need to get all of these disks backed up if possible. The Twiggy alignment disks may not be possible if they have data written outside the normal readable area of the disk or if it's not standard GCR-encoded sector data, but they're definitely worth a try. Unless you have Twiggy archival experience, it's probably a good idea to collaborate with someone like @ried, @sigma7, or @stepleton to maximize the chances of recovering the data from all of the disks.

Quote from: slewis1962 on August 21, 2026, 01:08:20 PMDid Alex get the changes done to allow both drives to work?

Sorry, I haven't gotten around to that quite yet! School just started back up and I've been busy. Hopefully I'll get it done today or tomorrow.

I bought the Twiggy Apple /// cards somewhere around 15 or 20 years ago in separate auctions from a former Apple employee.
As you can see from my above post I archived quite a few disks starting in 2012. I think I have more archived but they are not on my current computer. No idea why only these were copied to my Macintosh.

Quote from: slewis1962 on August 22, 2026, 09:48:20 PMHere are some of the Twiggy images I made starting in 2012. If anyone is interested how should I post them? Zip archive? As is?
I have more but these were all I copied to my current computer. I'll have to find the others or re-create them from the original disks.
(https://applelisa.net/wp-content/uploads/2026/08/Twiggies.png)

I just compressed the folder on my Macintosh. It shows as a 3MB .zip file.

Quote from: slewis1962 on August 22, 2026, 10:36:13 PMI just compressed the folder on my Macintosh. It shows as a 3MB .zip file.

Super cool, thank you. You're welcome to attach the .zip file to a post here. When you hit "preview" you'll see the option to attach a file below the text editor. Most of the software titles are kept over in the Files section (https://lisalist2.com/index.php/board,3.0.html).

In case anyone is interested I recorded a 35 minute video on July 12, 2012 of me showing how to use service mode to format a Twiggy disk sent to me that the OS could not repair or format. Sorry about the length. This is my first video uploaded to YouTube so I apologize in advance if it's cringe. Any feedback would be greatly appreciated.

Great video, thanks for sharing. That's the first time I've watched anyone controlling Twiggies via service mode.

Quote from: ried on August 22, 2026, 11:25:32 PMGreat video, thanks for sharing. That's the first time I've watched anyone controlling Twiggies via service mode.

I can't believe how much sharper I was back then! Anyway, I was repairing a set of drives for a customer. I can't remember what all I replaced but I did have to adjust the speed POT in order to get it to work. I learned a lot repairing Twiggy drives back then. This set was nearly a decade after the first drives I repaired. My original drives that came with my Lisa 1 only needed cleaning. I got lucky.
Anyone know how to repair a video like that? Or is that not possible. As you can see there was no editing, that was one straight shot. Can't remember what kind of camera that was either.

I was just downstairs visiting my workshop and found a bunch more Twiggy disks. I believe I found another set, although not as complete as the set I posted pictures of previously, of Xenix. I'll try and get pictures and post tomorrow.
I also found several copies of LisaTest including a few owned by an Apple employee. But then again, was it ever released to the public?

Quote from: ried on August 22, 2026, 10:39:32 PM

Quote from: slewis1962 on August 22, 2026, 10:36:13 PMI just compressed the folder on my Macintosh. It shows as a 3MB .zip file.

Super cool, thank you. You're welcome to attach the .zip file to a post here. When you hit "preview" you'll see the option to attach a file below the text editor. Most of the software titles are kept over in the Files section (https://lisalist2.com/index.php/board,3.0.html).

I want to try out the disk images on my Lisa FPGA before I upload them. I want to verify that the Fortran is in fact bootable. I'll make an SD card tomorrow and try out the new ESFloppy function.

I've connected an upper Twiggy drive to the LisaFPGA, wired as described on GitHub (https://github.com/alexthecat123/LisaFPGA#twiggy-specific-stuff), but flipping the LisaFPGA power switch on with the drive connected does not power on the LisaFPGA. It remains off, with no LED or display activity.

Disconnected the Twiggy drive and flipped the power switch again, nothing.

Disconnecting the Twiggy drive, unplugging the USB-C power cable, then reconnecting the USB-C power cable enables the LisaFPGA to switch on again.

What am I doing wrong here, friends?

P.S. No damage to the Twiggy drives. They're back in the Lisa operating as normal.
P.P.S. Using the Apple 20W USB-C power brick to power the LisaFPGA. I figured that would be plenty of power.

I've got some good news and some not so good news. First, I made an SD card for ESFloppy on the LisaFPGA board. I discovered that the Twiggy images I had that were not DC42 would not boot even when I added .image to the end. I changed them all to DC42 and most of them booted or were available in LOS 1.0.
Here is what I get when I booted BASIC, I didn't try to install to a profile but I'll do that in a day or two.
(https://applelisa.net/wp-content/uploads/2026/08/IMG_9461-scaled.jpg)
It actually boots!
Here is what I get when I boot Fortran.
(https://applelisa.net/wp-content/uploads/2026/08/IMG_9462-scaled.jpg)
No Boot file on disk. When I insert the virtual disk in LOS it says it is not a Lisa disk. I'll have to try it in the workshop. I could have swore it booted in 2002. I didn't archive it until 2012 so maybe it lost a few bits.

P.S. I love ESFloppy! Great job once again Alex! Can't wait for the standalone!

In case anyone is interested here is the Twiggy image for RM-Fortran. Does anyone know how the file system works? For example, does anyone know how to tell if it should be bootable? I looked at it with a hex editor and it's not empty but I don't know enough about the file system to know which block(s) determine if it's bootable.

Quote from: ried on August 23, 2026, 04:50:24 PMI've connected an upper Twiggy drive to the LisaFPGA, but flipping the LisaFPGA power switch on with the drive connected does not power on the LisaFPGA.
...
P.P.S. Using the Apple 20W USB-C power brick to power the LisaFPGA. I figured that would be plenty of power.

I'd suppose the 20W rating of that specific brick isn't at 5V (USB-C devices negotiate the voltage from the power source, so one may be 20W at 20V, so only capable of 1A, thus 5W at 5V).

Try some other USB-C power sources.

Quote from: sigma7 on August 23, 2026, 05:48:17 PMTry some other USB-C power sources.

Will do. Is there any harm in using my MacBook Pro USB-C power brick? It outputs various voltages, one of which reads 3.0A at 5.2V. I assume USB and the LisaFPGA are smart enough not to send too much power into the Twiggy drive in any case.

Quote from: slewis1962 on August 23, 2026, 05:46:31 PMdoes anyone know how to tell if it should be bootable?

The first block is what is loaded by the ROM. In a DC42 file, the first block starts at offset 0x54. Although this image has some data in the first block, it is mostly blank, and what is there does not seem to be executable 68K code.

A LOS1.0 DC42 disk image, for example, has 4EFA000A at offset 0x5C (4EFA is a jump instruction, so is a common thing to see at the beginning of executable code).

edit: corrected offset value

Quote from: ried on August 23, 2026, 05:54:41 PMIs there any harm in using my MacBook Pro USB-C power brick? It outputs various voltages, one of which reads 3.0A at 5.2V. I assume USB and the LisaFPGA are smart enough not to send too much power into the Twiggy drive in any case.

That should work.

The 5V from the brick is passed directly to the Twiggy drive (which is why the Twiggy may partially spring to life even before Lisa Power is pressed). 5.2V is safe as the spec is +/- 5%. The 12V is generated on board the LisaFPGA and is well regulated.

A USB-C brick is supposed to only output a higher voltage than 5V after negotiating with the device.

Just tried using the MacBook Pro power brick. Same exact behavior as before. The LisaFPGA simply will not power up with the Twiggy drive connected. Hmmm...

Quote from: slewis1962 on August 23, 2026, 05:38:36 PMP.S. I love ESFloppy! Great job once again Alex! Can't wait for the standalone!

Thank you! I'm actually working on the standalone board right now!

Quote from: ried on August 23, 2026, 06:37:45 PMJust tried using the MacBook Pro power brick. Same exact behavior as before. The LisaFPGA simply will not power up with the Twiggy drive connected. Hmmm...

Your ribbon cable connections look fine, so I'd suggest trying yet another power brick. Perhaps @sigma7 can tell us what he used to successfully power up his Twiggy drives?

Quote from: AlexTheCat123 on August 23, 2026, 06:53:54 PM

Quote from: slewis1962 on August 23, 2026, 05:38:36 PMP.S. I love ESFloppy! Great job once again Alex! Can't wait for the standalone!

Thank you! I'm actually working on the standalone board right now!

Quote from: ried on August 23, 2026, 06:37:45 PMJust tried using the MacBook Pro power brick. Same exact behavior as before. The LisaFPGA simply will not power up with the Twiggy drive connected. Hmmm...

Your ribbon cable connections look fine, so I'd suggest trying yet another power brick. Perhaps @sigma7 can tell us what he used to successfully power up his Twiggy drives?

Maybe the next iteration of the Twiggy breakout can have its own power input and just the data signals and ground can come from the FPGA board. But that's only if it's discovered the FPGA board can't supply enough power. Just a thought. I need to try and hook up my Twiggy drives soon.

Quote from: AlexTheCat123 on August 23, 2026, 06:53:54 PMYour ribbon cable connections look fine, so I'd suggest trying yet another power brick...

I tried an old 5W iPhone power adapter and as soon as I plugged it in, the LisaFPGA made quiet ticking sounds - like it was trying to start up and didn't have enough power. So that's a start.

Then I tried one of the Ubio Labs battery power banks that you could see in the top-left corner of the video and it worked! Well, it died halfway through the boot process, presumably because I need to charge it fully, but it did boot the LisaFPGA and the Twiggy drive came alive. Progress!

Quote from: slewis1962 on August 23, 2026, 07:17:27 PMMaybe the next iteration of the Twiggy breakout can have its own power input and just the data signals and ground can come from the FPGA board. But that's only if it's discovered the FPGA board can't supply enough power. Just a thought. I need to try and hook up my Twiggy drives soon.

Yeah, I think that might be a good idea. Either that or add a recommendation for a known-good power supply to the readme.

Quote from: ried on August 23, 2026, 07:18:50 PMThen I tried one of the Ubio Labs battery power banks that you could see in the top-left corner of the video and it worked! Well, it died halfway through the boot process, presumably because I need to charge it fully, but it did booth the LisaFPGA and the Twiggy drive came alive. Progress!

That's great news! Let us know what happens once you get the bank charged back up!

Quote from: AlexTheCat123 on August 23, 2026, 07:21:19 PMThat's great news! Let us know what happens once you get the bank charged back up!

It cuts power after LOS 1.2 and 2.x get to the desktop, while the Twiggy drive mechanism resets itself. I suspect the battery can't supply enough power for the Twiggy to do its thing, and the LisaFPGA shuts off.

So yeah, it seems like only certain USB power sources will allow full functionality with Twiggy drives attached... and I don't have the right one handy.

Quote from: AlexTheCat123 on August 23, 2026, 06:53:54 PMPerhaps @sigma7 can tell us what he used to successfully power up his Twiggy drives?

This "atomi AT1080" gets me far enough to boot BLU from the built-in ESProFile, and runs the drive well enough to read:

https://www.bestbuy.com/site/reviews/atomi-power-adapter-black/5857606 (https://www.bestbuy.com/site/reviews/atomi-power-adapter-black/5857606)

The "high power" blue USB-A outlet doesn't supply as much current as the USB-C connector.
I'm connecting with a 3' / 1m Tripp-Lite USB-C cable rated at 5A.

I've kind of hit a roadblock. Someone else look at this and tell me what you think. I tried to install BASIC 1.0 onto a profile image when it asked if it's attached to paraport (built in port) or SLOT2CHAN1 or SLOT2CHAN2. I chose paraport as I assume the FPGA board is mapping the ESProfile to the built in port. Then it asked to insert A5WORKSHOP.BASIC.1 into the other slot. I inserted workshop disk 1 which it didn't like. So maybe this version of BASIC requires the A5 release which I don't have at the moment.
(https://applelisa.net/wp-content/uploads/2026/08/IMG_9463-scaled.jpg)

*EDIT
Does anyone know if I need to install the workshop from the 3 diskettes before adding BASIC to it? I've never installed the workshop before or any of the other languages.

*EDIT 2
I need to learn to read. It is asking for BASIC 1 which is what I booted from, not for workshop disk 1. I'll RTFM which I just happen to have!

Sorry about posting so much lately. Has anyone installed the Twiggy Wokshop? I tried tonight with some images I downloaded from Macintosh Repository. I get through disks one and two then it ejects disk two and asks for three. I insert it, hit y for yes then return then it asks if I want to continue. I hit y for yes then return and it aborts. This happened three times in a row. Not sure what I'm doing wrong or maybe something is wrong with disk three.

Quote from: slewis1962 on August 23, 2026, 09:31:50 PM*EDIT 2
I need to learn to read. It is asking for BASIC 1 which is what I booted from, not for workshop disk 1. I'll RTFM which I just happen to have!

In the screenshot above it is asking you for Basic Workshop Disk 2, which, confusingly, has volume name "A5Workshop.BASIC.1". You booted and started the installation from disk 1 with volume name "A5Workshop.BASIC.0".

The way I installed Basic Workshop 1.0 (in LisaEm but it should be same elsewhere) at https://lisalist2.com/index.php/topic,825.msg6258.html#msg6258 :
- Booted LOS 1.0 twiggy Disk 1 and installed it on a blank 50MB profile image file on parallel port "PARAPORT". This is optional but nice to have if you will be developing LOS applications.
- Booted Pascal Workshop 1.0 twiggy Disk 1 and installed it from the 3 Twiggy disk images (don't remember where I downloaded them from, but you can get them at https://www.compu85.net/stuff/Lisa/Software/Workshop/Twiggy/ ) onto the PARAPORT, without wiping the disk. It went just fine.
- Booted Basic Workshop 1.0 twiggy Disk 1 and installed it from the 2 disks onto PARAPORT, without wiping the disk.
- Strangely, the Pascal compiler gives an error after this, I expected that Basic and Pascal can co-exist fine.

Quote from: TorZidan on August 24, 2026, 01:57:22 AM

Quote from: slewis1962 on August 23, 2026, 09:31:50 PM*EDIT 2
I need to learn to read. It is asking for BASIC 1 which is what I booted from, not for workshop disk 1. I'll RTFM which I just happen to have!

In the screenshot above it is asking you for Basic Workshop Disk 2, which, confusingly, has volume name "A5Workshop.BASIC.1". You booted and started the installation from disk 1 with volume name "A5Workshop.BASIC.0".

The way I installed Basic Workshop 1.0 (in LisaEm but it should be same elsewhere) at https://lisalist2.com/index.php/topic,825.msg6258.html#msg6258 :
- Booted LOS 1.0 twiggy Disk 1 and installed it on a blank 50MB profile image file on parallel port "PARAPORT". This is optional but nice to have if you will be developing LOS applications.
- Booted Pascal Workshop 1.0 twiggy Disk 1 and installed it from the 3 Twiggy disk images (don't remember where I downloaded them from, but you can get them at https://www.compu85.net/stuff/Lisa/Software/Workshop/Twiggy/ ) onto the PARAPORT, without wiping the disk. It went just fine.
- Booted Basic Workshop 1.0 twiggy Disk 1 and installed it from the 2 disks onto PARAPORT, without wiping the disk.
- Strangely, the Pascal compiler gives an error after this, I expected that Basic and Pascal can co-exist fine.

Cool! Thanks! Yeah, the volume name didn't click at first as when I created the images a long time ago I named them 1 and 2, not 0 and 1. I'll give it a try sometime this week.

Quote from: sigma7 on August 23, 2026, 08:44:09 PM

Quote from: AlexTheCat123 on August 23, 2026, 06:53:54 PMPerhaps @sigma7 can tell us what he used to successfully power up his Twiggy drives?

This "atomi AT1080" gets me far enough to boot BLU from the built-in ESProFile, and runs the drive well enough to read...

I noticed that there are a few high-powered USB-C power bricks made for the Raspberry Pi platform, including this one that claims a total output of 27W @ 5A and up to 45W, depending on what device it's connected to. I thought for sure this would supply enough power to run one Twiggy drive.

It did get further along and booted to the LOS 2.x desktop, and read the Twiggy disk that I inserted into the drive. This disk came from an LOS 1.2 machine, so it prompted me to update the disk format. When I affirmed the decision to format the disk, it tried to write to the disk and died as before. Not enough power once again, it seems.

Here's the power adapter I used: https://www.amazon.com/dp/B07H125ZRL

Quote from: ried on August 25, 2026, 04:44:42 PMthis one that claims a total output of 27W @ 5A and up to 45W, depending on what device it's connected to

One of the reviews on the amazon listing says:

QuoteI found out what the issue was. You have to add a line to the config.txt file and rpi-eeprom-config file to tell the Pi5 that it is indeed powered by a compliant PSU. That line is "PSU_MAX_CURRENT=5000".

Which to me means that a USB-C PD current higher than 3A needs to be negotiated by the device... I guess.

Perhaps Alex can have the FPGA negotiate with the power source?

edit: I'm now thinking that it may have been the Pi5 that was limiting the current for that reviewer, not necessarily the supply.

Are you using a cable rated for 5A? Apparently they have some electronics in them that tell the supply if they are capable of more than 3A.

Quote from: ried on August 25, 2026, 04:44:42 PMIt did get further along and booted to the LOS 2.x desktop, and read the Twiggy disk that I inserted into the drive. This disk came from an LOS 1.2 machine, so it prompted me to update the disk format. When I affirmed the decision to format the disk, it tried to write to the disk and died as before. Not enough power once again, it seems.

Well that's progress I guess! It means that the Lisa successfully read the disk's filesystem.

Do you have a bench power supply that you could connect straight to the board instead of using a USB-C cable? If so, set it to 5V, set the current limit as high as you can, and then connect it between any 5V pad on the board and GND. The center leg of the POWER switch would be a great 5V pad to attach it to, because then you'd still preserve the functionality of the switch. That should give you more than enough current to drive the Twiggies.

Quote from: AlexTheCat123 on August 25, 2026, 05:43:11 PMDo you have a bench power supply that you could connect straight to the board instead of using a USB-C cable?

Unfortunately, no.

Quote from: ried on August 25, 2026, 05:46:50 PMUnfortunately, no.

Darn. Well I guess my only suggestion is to keep trying other USB power supplies until you find one that works. I can't really think of anything else to try!

Quote from: sigma7 on August 25, 2026, 04:57:08 PMAre you using a cable rated for 5A? Apparently they have some electronics in them that tell the supply if they are capable of more than 3A.

The cable is part of the power adapter (permanently attached). It's very sturdy, more so than any other USB cable I have.

Quote from: AlexTheCat123 on August 26, 2026, 02:43:37 AMDarn. Well I guess my only suggestion is to keep trying other USB power supplies until you find one that works. I can't really think of anything else to try!

Just ordered an Anker 140W GaN charger. This one has to work, right?
https://www.amazon.com/dp/B0DFCFTNXM

Quote from: ried on August 26, 2026, 03:16:06 AMThis one has to work, right?

Of course it does! :P

For a low-tech alternative I'm wondering about:
https://www.amazon.com/cablecc-Repair-Solderless-Connector-Terminal/dp/B0FY2GW4YN (https://www.amazon.com/cablecc-Repair-Solderless-Connector-Terminal/dp/B0FY2GW4YN)

With something like:
https://www.amazon.com/HPMN-5V-10A-50W-Transformer/dp/B0FQTP9R12 (https://www.amazon.com/HPMN-5V-10A-50W-Transformer/dp/B0FQTP9R12)
However, some of the random named power adapters I've tested only deliver 1A in spite of being rated 3A or 5A, so maybe Amazon isn't the right place to get such a thing.

This might be more likely to work:

https://www.jameco.com/z/GST60A05-P1J-MEAN-WELL-5-Volt-6-Amp-30-Watt-3-Wire-Regulated-Switching-Desktop-Power-Adapter-2-1mm-Plug-Level-VI_2224358.html (https://www.jameco.com/z/GST60A05-P1J-MEAN-WELL-5-Volt-6-Amp-30-Watt-3-Wire-Regulated-Switching-Desktop-Power-Adapter-2-1mm-Plug-Level-VI_2224358.html)

If one is going to assemble something like this, a voltmeter is required to confirm it is correct before connecting it to something valuable like a LisaFPGA.

edit: A preferred power source would be adjustable and display the voltage and current, but those tend to be more than $100 (some much more depending on features).

Quote from: sigma7 on August 26, 2026, 04:26:07 AMFor a low-tech alternative I'm wondering about:
https://www.amazon.com/cablecc-Repair-Solderless-Connector-Terminal/dp/B0FY2GW4YN (https://www.amazon.com/cablecc-Repair-Solderless-Connector-Terminal/dp/B0FY2GW4YN)

With something like:
https://www.amazon.com/HPMN-5V-10A-50W-Transformer/dp/B0FQTP9R12 (https://www.amazon.com/HPMN-5V-10A-50W-Transformer/dp/B0FQTP9R12)
However, some of the random named power adapters I've tested only deliver 1A in spite of being rated 3A or 5A, so maybe Amazon isn't the right place to get such a thing.

This might be more likely to work:

https://www.jameco.com/z/GST60A05-P1J-MEAN-WELL-5-Volt-6-Amp-30-Watt-3-Wire-Regulated-Switching-Desktop-Power-Adapter-2-1mm-Plug-Level-VI_2224358.html (https://www.jameco.com/z/GST60A05-P1J-MEAN-WELL-5-Volt-6-Amp-30-Watt-3-Wire-Regulated-Switching-Desktop-Power-Adapter-2-1mm-Plug-Level-VI_2224358.html)

If the Anker charger doesn't work, then this would definitely be the next thing to try. It's basically the same thing as my bench power supply idea, but more elegant.

The CanaKit for Raspberry Pi would at least allow the Twiggy disk to be read. The Anker doesn't even get that far. Ugh.

When booting LOS 2.x, the Anker's built-in display indicates around 6W of power being drawn by the USB-C port. When the desktop appears and the Twiggy drive starts to move, the display briefly indicates 10W being drawn, and the LisaFPGA shuts off.

Quote from: ried on August 26, 2026, 08:12:24 PMWhen booting LOS 2.x, the Anker's built-in display indicates around 6W of power being drawn by the USB-C port. When the desktop appears and the Twiggy drive starts to move, the display briefly indicates 10W being drawn, and the LisaFPGA shuts off.

Yeah, I think @sigma7's suggestion is going to be the only solution here. I had no idea that a single Twiggy would draw so much current!

Quote from: sigma7 on August 26, 2026, 04:26:07 AMWith something like:
https://www.amazon.com/HPMN-5V-10A-50W-Transformer/dp/B0FQTP9R12 (https://www.amazon.com/HPMN-5V-10A-50W-Transformer/dp/B0FQTP9R12)

Good news, everyone! In today's episode of "Testing Random Amazon Power Bricks" we found a winner.

This suggestion from sigma7 allows the upper Twiggy to work just fine. No issues with reading, writing, or ejecting. This encouraged me to try the lower Twiggy drive also, just to see if it'd work. The spindle motor still does not run in that drive when it's connected... However everything else seems to work. The carriage moves, and eject works. The spindle motor not spindling was previously discovered by sigma7 (https://lisalist2.com/index.php?msg=6148) and seems to remain that way with current firmware.

In any event, the upper Twiggy works just fine with that particular power brick.

That's great!!! One drive confirmed to be fully-working. I wonder what's going wrong with the lower drive though? You are running the latest firmware that's supposed to fix the bug, right?

Quote from: AlexTheCat123 on August 28, 2026, 01:17:59 AMYou are running the latest firmware that's supposed to fix the bug, right?

Yep, running the August 22nd release. Hmmm...

Quote from: ried on August 28, 2026, 01:50:25 AM

Quote from: AlexTheCat123 on August 28, 2026, 01:17:59 AMYou are running the latest firmware that's supposed to fix the bug, right?

Yep, running the August 22nd release. Hmmm...

Can you probe the MT signal going to the lower Twiggy with a scope and show what it looks like while a disk is being inserted and clamped?

I don't have a scope, but am happy to give it a try. What kind of scope should I use (any suggestions?) and how would I probe that particular signal?

When I received my LisaFPGA board the first thing I wanted to try was get it connected to the modern internet.  I was hoping to use Localtalk (MacIP), but then I learned that the hardware for Localtalk was not implemented on LisaFPGA.  :(

So for plan "B", I am using a PPP connection over RS232 at 56K baud.  I am running MW+II, System 6.08, MacTCP, MacPPP.  Connecting to a PPP server running on a Raspberry Pi 3.

With this setup I can run NCSA telnet and have multiple terminal sessions running at the same time.  NCSA telnet also supports FTP file transfers. The TCP/IP stack is running directly on the LisaFPGA hardware.  Works great!

Rick

Quote from: ried on August 29, 2026, 10:58:29 AMI don't have a scope, but am happy to give it a try. What kind of scope should I use (any suggestions?) and how would I probe that particular signal?

If you've got a logic analyzer, that would work too. I wouldn't want you to buy a whole scope just for this, especially since the problem is almost certainly my fault not yours! You'd want to probe the PWM line on the Sony floppy connector (J3), which happens to carry MT0 when it's in Twiggy mode. PWM is pin 20 on the floppy connector, so if you find the text on the PCB that reads J3, it's the connector pin that's immediately above there, on the inner column of pins.

I would just probe it myself on my board, but the Twiggy floppy controller won't emit pulses on MT unless it detects a disk in place, and since I don't have any real Twiggy drives, I have no good way to spoof disk in place without screwing up the other SNS registers too.

I've looked over my code again and I don't see any problems, so it's got to be something stupid that I'm overlooking. Just to rule out the drive, can you swap things around and plug your upper drive into the lower connector and your lower drive into the upper connector and see if the problem switches drives? And @sigma7, if you could confirm whether or not both of your Twiggies spin with the new LisaFPGA code, that would be great too.

Quote from: Lisa2 on August 30, 2026, 10:43:23 PMWhen I received my LisaFPGA board the first thing I wanted to try was get it connected to the modern internet.  I was hoping to use Localtalk (MacIP), but then I learned that the hardware for Localtalk was not implemented on LisaFPGA.  :(

Yeah, unfortunately I couldn't find a good modern source for the differential driver ICs that you need. So I left that functionality off the board, under the assumption that practically nobody would actually use it. Clearly I was wrong; sorry!!!

As a side note, how did you get your PFG working in the SCC socket? Did you revert to my old code that uses the external SCC, or did you modify the new code to make it switchable between internal/external? Either way, it's really cool to see someone use a PFG with the board; I think you're the first person besides me to actually try it!

When using a USB keyboard with the FPGA, what key is the "CLEAR" key?

Quote from: Lisa2 on August 30, 2026, 10:43:23 PMWhen I received my LisaFPGA board the first thing I wanted to try was get it connected to the modern internet.  I was hoping to use Localtalk (MacIP), but then I learned that the hardware for Localtalk was not implemented on LisaFPGA.  :(

I was always confused about that. Is it true that the LISA/LOS had some precursor to AppleTalk?

It would be phenomenal to get LOS on GlobalTalk, even if just a client!

Quote from: bmwcyclist on August 31, 2026, 01:39:41 PMWhen using a USB keyboard with the FPGA, what key is the "CLEAR" key?

It's NumLock.

Quote from: AlexTheCat123 on August 31, 2026, 02:01:35 PM

Quote from: bmwcyclist on August 31, 2026, 01:39:41 PMWhen using a USB keyboard with the FPGA, what key is the "CLEAR" key?

It's NumLock.

Thanks!

Quote from: bmwcyclist on August 31, 2026, 01:47:32 PMIs it true that the LISA/LOS had some precursor to AppleTalk?

There was something called AppleNet, for which there was a dedicated expansion card. It never saw production use. During his experiments compiling the Office System, Alex reported finding some vestigial code for what looked like networked fileshares (if I recall correctly), but it obviously didn't work without the hardware, and enabling it led to some breakage.

Quote from: stepleton on August 31, 2026, 05:30:10 PMThere was something called AppleNet, for which there was a dedicated expansion card. It never saw production use. During his experiments compiling the Office System, Alex reported finding some vestigial code for what looked like networked fileshares (if I recall correctly), but it obviously didn't work without the hardware, and enabling it led to some breakage.

Yep, and I think it was only 20 lines of code or so, all in the Desktop Manager. Basically enough to show the icon for the fileshare and break the OS, and that's about it.

I tried hooking one of my Twiggy drives up to the LisaFPGA but it crowbarred my power brick. My power brick can supply 3A @5v so it should be adequate. The LisaFPGA was not damaged as it worked after I unhooked the Twiggy drive and reset the power brick. I need to check and see if any of the tantalum's are shorted as that is one of the components that I've had to replace in the past when troubleshooting Twiggy drives. My drives have been sitting on a shelf for 6 years so I need to get a real Lisa out to test them before I go further. They literally have not been used in that time so anything could have happened. I did extensive testing to make sure my cables were correct and not backwards. I'll update when I get time to troubleshoot these drives.
I even had my scope out to check the motor signal. Oh well.

Yeah, I used several USB-C chargers, battery banks and power bricks. All delivered the standard 5Vx3A=15W of power and it's simply not enough to drive a Twiggy.

Quote from: ried on August 31, 2026, 11:56:37 PMYeah, I used several USB-C chargers, battery banks and power bricks. All delivered the standard 5Vx3A=15W of power and it's simply not enough to drive a Twiggy.

My power brick is a 65W laptop power supply. It only supplies 15W at 5v though. I'm not going to buy any other power supplies, I'll use the FPGA board with ESFloppy and ESProfile and use my real Lisa if I need to use the Twiggy drives. I may redesign the Twiggy breakout board to accept external 12v at some point in the future if I get a wild hair...
I still need to test my Twiggy drives in a real Lisa at some point in the near future.

I have an update to my earlier post. I found the one drive I initially tried has the 12v rail shorted to ground. I found one of the tantalum's was shorted. I tried the other drive in both the upper and lower positions on the twiggy breakout board. Upon initial power to the FPGA board the motor spins for several seconds. Once booted into LOS 1.0 the drive no longer responds. I inserted a Twiggy but the drive fails to clamp down or spin the motor. I may investigate further later or I may just use this board without connecting any drives. I was all set up to test the signals with my scope but didn't get that far.

I do have a bench power supply that can deliver 0-30v at 0-5A. Is 5v at 5A, or 25W, enough? I'd rather not fry my FPGA board though. What is the absolute safest way to connect it to the board?

Quote from: slewis1962 on September 01, 2026, 02:03:49 AMI do have a bench power supply that can deliver 0-30v at 0-5A. Is 5v at 5A, or 25W, enough? I'd rather not fry my FPGA board though. What is the absolute safest way to connect it to the board?

Yeah, I think that's a good next step. Clip your ground lead to one of the ground lugs on one of the serial ports, the mouse port, or the ProFile port, and then connect the 5V lead to the center terminal of SW1, the power switch. That should be perfectly safe; just make sure you've got the voltage dialed in first and that you've fixed the short on your Twiggy drive!

Quote from: AlexTheCat123 on August 30, 2026, 11:04:52 PM

Quote from: Lisa2 on August 30, 2026, 10:43:23 PMWhen I received my LisaFPGA board the first thing I wanted to try was get it connected to the modern internet.  I was hoping to use Localtalk (MacIP), but then I learned that the hardware for Localtalk was not implemented on LisaFPGA.  :(

As a side note, how did you get your PFG working in the SCC socket? Did you revert to my old code that uses the external SCC, or did you modify the new code to make it switchable between internal/external? Either way, it's really cool to see someone use a PFG with the board; I think you're the first person besides me to actually try it!

I am using your last bitstream before you switched to FPGA based SCC.  I plan add Localtalk support using a daughter board plugged into the SCC socket.  I Will not need the PFG to use Localtalk.
Rick

Quote from: Lisa2 on September 01, 2026, 12:40:33 PM

Quote from: AlexTheCat123 on August 30, 2026, 11:04:52 PM

Quote from: Lisa2 on August 30, 2026, 10:43:23 PMWhen I received my LisaFPGA board the first thing I wanted to try was get it connected to the modern internet.  I was hoping to use Localtalk (MacIP), but then I learned that the hardware for Localtalk was not implemented on LisaFPGA.  :(

As a side note, how did you get your PFG working in the SCC socket? Did you revert to my old code that uses the external SCC, or did you modify the new code to make it switchable between internal/external? Either way, it's really cool to see someone use a PFG with the board; I think you're the first person besides me to actually try it!

I am using your last bitstream before you switched to FPGA based SCC.  I plan add Localtalk support using a daughter board plugged into the SCC socket.  I Will not need the PFG to use Localtalk.
Rick

Definitely share the result with us once you get Localtalk working. That's going to be really cool to see!

I have been thinking that my LisaFPGA would be a good place to store my spare SCC, so I'm also interested in setups that use the real McCoy...

Quote from: AlexTheCat123 on August 30, 2026, 11:04:52 PMIf you've got a logic analyzer, that would work too.

This might be an opportunity to see if the low cost 8 bit logic analyzers are useful for this sort of issue.

eg. SparkFun TOL-18627
https://www.digikey.com/en/products/detail/sparkfun-electronics/18627/15842546 (https://www.digikey.com/en/products/detail/sparkfun-electronics/18627/15842546)

In addition to the device itself, you'll need the pulseview software (https://sigrok.org/wiki/Downloads) suited for your modern computer, and some clips to connect to your target device such as https://www.digikey.com/en/products/detail/digilent-inc/240-137/9916326 (https://www.digikey.com/en/products/detail/digilent-inc/240-137/9916326) (as that's a set of 5, you might want two sets to have 10 clips).

Having used it for a few minutes, I expect most will have some questions getting started.

Quote from: Lisa2 on September 01, 2026, 12:40:33 PM

Quote from: AlexTheCat123 on August 30, 2026, 11:04:52 PMAs a side note, how did you get your PFG working in the SCC socket? Did you revert to my old code that uses the external SCC, or did you modify the new code to make it switchable between internal/external?

I am using your last bitstream before you switched to FPGA based SCC.

Is the external SCC interface (to use a physical Z8530) still included (albeit disabled) in the LisaFPGA design files on GitHub? If not, is it practical to put it back in so it becomes an optional configuration, or if not, add a branch with the old code?

Quote from: AlexTheCat123 on August 30, 2026, 11:04:52 PMprobe the PWM line on the Sony floppy connector (J3), which happens to carry MT0
...
I would just probe it myself on my board, but the Twiggy floppy controller won't emit pulses on MT unless it detects a disk in place, and since I don't have any real Twiggy drives
...
And @sigma7, if you could confirm whether or not both of your Twiggies spin with the new LisaFPGA code, that would be great too.

I'm observing a problem with controlling rotating floppies which makes me wonder if there is a problem with my particular LisaFPGA.

I previously reported problems formatting or writing to a Twiggy drive and a 400k drive.

This is the sort of scenario I'm seeing with build 555dcf7, Sony 400K drive, using full 20 conductor cable, A8 I/O ROM, stock CPU speed:

• Switch on USB power. If a disk was already inserted, the drive runs briefly then stops (which is normal).
• Press Lisa Control Power on, arrives at Startup From menu (normal)
• Apple-3 to boot from ESProFile, boots BLU 0.90, all normal
• Insert floppy, runs briefly then stops (normal)
• Select Floppy - Format - Yes erase
• Drive starts, head steps, speed changes, seems normal, completes normally (sometimes).
• Assuming formatting completed: Select Floppy - Read
• Drive starts, progress counts normally, completes normally.
• Select Floppy - Write - Yes overwrite
• Drive starts, a few sectors appear to write properly, then a floppy drive error is reported
• The drive continues to rotate (it should stop)
• Select Fail to return to the BLU menu, drive continues to rotate
• Select Floppy - Eject
• Floppy is ejected, but spindle motor continues to rotate.
• Insert disk and eject again, spindle continues to rotate.
• Press Lisa Control Reset, sometimes self-test shows I/O Board error 57 (probably because FDC is non-responsive)
• Boot into BLU again
• can still insert floppy and eject and motor continues to run.
• Selecting Floppy - Read and first sector generates error
• Press Lisa Control Power off, Powers down but drive continues to rotate
• Lisa Control Power on, Lisa powers up, but floppy drive remains unresponsive aside from ejecting on command.

Switch off and on main power, and drive is again responsive until the hiccup is triggered again.

On my setup this is reliable, so I think unlikely that others would not have seen such floppy failures, making me think it has something to do with this particular unit.

Given the inscrutability (or at least un-probe-ability) of an FPGA, I wonder if there is a hardware test suite for the LisaFPGA to help confirm or disprove this suspicion?

Quote from: sigma7 on September 02, 2026, 03:27:15 AM

Quote from: Lisa2 on September 01, 2026, 12:40:33 PM

Quote from: AlexTheCat123 on August 30, 2026, 11:04:52 PMAs a side note, how did you get your PFG working in the SCC socket? Did you revert to my old code that uses the external SCC, or did you modify the new code to make it switchable between internal/external?

I am using your last bitstream before you switched to FPGA based SCC.

Is the external SCC interface (to use a physical Z8530) still included (albeit disabled) in the LisaFPGA design files on GitHub? If not, is it practical to put it back in so it becomes an optional configuration, or if not, add a branch with the old code?

Yes it's still on GitHub.  To use a physical Z8530,  I used the bitstream from this commit: https://github.com/alexthecat123/LisaFPGA/commit/d179067bed131ce858645aeda29335a92021a05c

Rick

Quote from: sigma7 on September 02, 2026, 04:29:37 AM

Quote from: AlexTheCat123 on August 30, 2026, 11:04:52 PMprobe the PWM line on the Sony floppy connector (J3), which happens to carry MT0
...
I would just probe it myself on my board, but the Twiggy floppy controller won't emit pulses on MT unless it detects a disk in place, and since I don't have any real Twiggy drives
...
And @sigma7, if you could confirm whether or not both of your Twiggies spin with the new LisaFPGA code, that would be great too.

I'm observing a problem with controlling rotating floppies which makes me wonder if there is a problem with my particular LisaFPGA.

I previously reported problems formatting or writing to a Twiggy drive and a 400k drive.

This is the sort of scenario I'm seeing with build 555dcf7, Sony 400K drive, using full 20 conductor cable, A8 I/O ROM, stock CPU speed:

• Switch on USB power. If a disk was already inserted, the drive runs briefly then stops (which is normal).
• Press Lisa Control Power on, arrives at Startup From menu (normal)
• Apple-3 to boot from ESProFile, boots BLU 0.90, all normal
• Insert floppy, runs briefly then stops (normal)
• Select Floppy - Format - Yes erase
• Drive starts, head steps, speed changes, seems normal, completes normally (sometimes).
• Assuming formatting completed: Select Floppy - Read
• Drive starts, progress counts normally, completes normally.
• Select Floppy - Write - Yes overwrite
• Drive starts, a few sectors appear to write properly, then a floppy drive error is reported
• The drive continues to rotate (it should stop)
• Select Fail to return to the BLU menu, drive continues to rotate
• Select Floppy - Eject
• Floppy is ejected, but spindle motor continues to rotate.
• Insert disk and eject again, spindle continues to rotate.
• Press Lisa Control Reset, sometimes self-test shows I/O Board error 57 (probably because FDC is non-responsive)
• Boot into BLU again
• can still insert floppy and eject and motor continues to run.
• Selecting Floppy - Read and first sector generates error
• Press Lisa Control Power off, Powers down but drive continues to rotate
• Lisa Control Power on, Lisa powers up, but floppy drive remains unresponsive aside from ejecting on command.

Switch off and on main power, and drive is again responsive until the hiccup is triggered again.

On my setup this is reliable, so I think unlikely that others would not have seen such floppy failures, making me think it has something to do with this particular unit.

Given the inscrutability (or at least un-probe-ability) of an FPGA, I wonder if there is a hardware test suite for the LisaFPGA to help confirm or disprove this suspicion?

Wow, that's really odd! Does this only happen on a real drive, or on the emulator too? Can anyone else replicate this? I tried and I can't replicate it myself.

Quote from: AlexTheCat123 on September 02, 2026, 02:36:56 PMDoes this only happen on a real drive, or on the emulator too?

The ESFloppy seems to work fine... can Format, Read, Write multiple times in a row without a hiccup.

I'll probe the cable signals, perhaps the 74HCT245 drivers are damaged (or marginal/inadequate compared the the 74LS244 and 8T97 of a real I/O Board).

Quote from: sigma7 on September 02, 2026, 03:33:53 PMprobe the cable signals, perhaps the 74HCT245 drivers are damaged...

It looks like the voltages are good and the edges square (with a 400K Sony drive attached).

Sometimes when I retry after the format fails, it recals to track 0, then steps through the first set of tracks at the first speed normally, then after changing speeds the head carriage clicks at the appropriate rate for track stepping but it does not move.

Very strange that this is a problem with a single unit.

How many other users have used a real 400K Sony drive without problems?

No issues with a 400K drive on my unit.

Quote from: sigma7 on September 02, 2026, 03:33:53 PMHow many other users have used a real 400K Sony drive without problems?

I know that Todd had a 400K drive working with his board.  I will try and test this with my board this weekend and let you know the results.
Rick

Quote from: sigma7 on September 03, 2026, 01:44:40 PMSometimes when I retry after the format fails, it recals to track 0, then steps through the first set of tracks at the first speed normally, then after changing speeds the head carriage clicks at the appropriate rate for track stepping but it does not move.

My 400K Sony problem solved, I think: stepper lead screw was fouled; seems to work now after cleaning & lubrication.

Going back to working on Twiggies...

Quote from: sigma7 on September 04, 2026, 05:57:25 AMMy 400K Sony problem solved, I think: stepper lead screw was fouled; seems to work now after cleaning & lubrication.

Going back to working on Twiggies...

Glad to hear it! I was scared that I had screwed something up with my board design...

I tried hooking up my bench supply and was successful in getting the FPGA board to function. I booted into LOS 1.0 and the Twiggy drive would not function. I inserted the disk and it didn't attempt to clamp down or anything. As you can see from the following photo it was only drawing 1.026A @ 5v. When the disk was inserted the current draw didn't change. I tried with my other bench power supply which can supply 10A @ 5v and it was pretty much spot on (1.025A @ 5v) and didn't function either. All my cabling looks to be ok.
(https://applelisa.net/wp-content/uploads/2026/09/IMG_9470-scaled.jpg)

I decided I better get out my real Lisa and test the drive to make sure it was still functioning. Here is the result.
(https://applelisa.net/wp-content/uploads/2026/09/IMG_9471-scaled.jpg)
So it looks like my drive still works with no problems. Not sure what else to try. The power supply didn't go into current limiting mode or anything. 10A should be plenty. If I designed an interface board with the 12V coming into the board instead of going through the LisaFPGA am I likely to get a better result or would that be a waste of time and resources? Is it possible there is some problem with my board? I installed the latest firmware several days ago before trying any of this.

*Edit* As you can see on the shelf above the Lisa is my other bench supply.
Also, I used the ESProfile on my Lisa and it works just fine.

Can you show how your Twiggy drive is connected to your LisaFPGA and the Twiggy breakout board?

Quote from: ried on September 04, 2026, 06:22:55 PMCan you show how your Twiggy drive is connected to your LisaFPGA and the Twiggy breakout board?

I'll try and get that later tonight or tomorrow. I need to put away my real Lisa in order to get my workspace back for the FPGA board. I was just thinking though, I had it connected to the lower connector on the Twiggy adapter board as that's where I had it when testing the other day before trying tonight with my power supply. I had to get a banana plug to test clip cable to hook it up. I'll try connecting to the upper connector and see if my results are any different.

(https://m.media-amazon.com/images/W/BW_MEDIAX_AVIF_MEASUREMENT_1306696-T4/images/I/61bpuoGzhHL._SX522_.jpg)

I'll update with photos after further testing.

Yeah, I have had success with the Upper Twiggy connector on the breakout board, but not the Lower Twiggy side.

Quote from: ried on September 04, 2026, 06:22:55 PMCan you show how your Twiggy drive is connected to your LisaFPGA and the Twiggy breakout board?

Here is my configuration. The red stripe is located on pin 1 on all the connectors. I tried the upper Twiggy connector on the breakout board but it didn't make any difference. I connected my scope up to the Motor Data Clock pin 22 and when I turn power on to the board the motor spins for 3-5 seconds before stopping and I see a waveform on the oscilloscope although its not a nice square wave, it's very noisy pulses with a regular interval. I didn't get a picture of that but if anyone wants one I could try and get it this weekend.

(https://applelisa.net/wp-content/uploads/2026/09/IMG_9472-scaled.jpg)
(https://applelisa.net/wp-content/uploads/2026/09/IMG_9473-scaled.jpg)
(https://applelisa.net/wp-content/uploads/2026/09/IMG_9474-scaled.jpg)

In the third photo that is a passive board I made several years ago to more easily probe the signals going to the twiggy drive. That is where I can measure and verify I have 5v, -5v, and 12v on the correct pins. And also to probe any signals with a scope or a logic analyzer.
Ignore the spots for switches, I thought I would make a board with multiple purposes as that was the first board I ordered from PCBWay in China.

I believe the red stripe for the 6-pin cable should face down going to the breakout board, not up. Please double-check those connections very carefully.

https://github.com/alexthecat123/LisaFPGA#twiggy-specific-stuff

Quote from: ried on September 04, 2026, 11:13:36 PMI believe the red stripe for the 6-pin cable should face down going to the breakout board, not up. Please double-check those connections very carefully.

https://github.com/alexthecat123/LisaFPGA#twiggy-specific-stuff

In the photo on Alex's GitHub the red stripe is down on both ends. Mine is up on both ends. It shouldn't matter.

Yes, I understand, as long as the position of the connector is in the lower four holes at each end. Just trying to eliminate variables here.

My motor turns on when the board is powered up but does nothing when a disk is inserted after the OS is booted. Running when the LisaFPGA is powered on shows that the board is getting correct voltages at least or the motor couldn't run. I guess since the power is applied to the Twiggy drive upon power up even before the soft power switch is pressed it differs from a real Lisa where the Twiggy only gets power after the soft switch is pressed.

Quote from: ried on September 05, 2026, 12:53:08 AMYes, I understand, as long as the position of the connector is in the lower four holes at each end. Just trying to eliminate variables here.

I appreciate that. Yes, both ends are in the bottom four holes of the connector. I'll do more investigating in the next few days.

Separate to Twiggy/FDD matters... I was perusing the LisaFPGA schematic and I notice that the ESProFile and the parallel port appear to be wired separately to the FPGA. This is really interesting since it means that (probably with some FPGA code changes) you could boot from the ESProFile and then have the parallel port appear to be one of the ports on a two-port expansion card. You could use it to copy files to and from a real ProFile, or you could hang a Canon PJ-1080A off of the parallel port and print in colour!

Quote from: stepleton on September 05, 2026, 01:29:55 PMSeparate to Twiggy/FDD matters... I was perusing the LisaFPGA schematic and I notice that the ESProFile and the parallel port appear to be wired separately to the FPGA. This is really interesting since it means that (probably with some FPGA code changes) you could boot from the ESProFile and then have the parallel port appear to be one of the ports on a two-port expansion card. You could use it to copy files to and from a real ProFile, or you could hang a Canon PJ-1080A off of the parallel port and print in colour!

Yeah, that was a big part of why I chose to do it that way! I'll probably get to implementing the parallel card eventually, but right now a standalone version of ESFloppy is my main priority. I've got some prototype boards coming in the mail, so hopefully it's not too far off from being ready.

Quote from: slewis1962 on September 04, 2026, 11:11:54 PMIn the third photo that is a passive board I made several years ago to more easily probe the signals going to the twiggy drive. That is where I can measure and verify I have 5v, -5v, and 12v on the correct pins. And also to probe any signals with a scope or a logic analyzer.

That breakout board is INCREDIBLY helpful! Could you hook a logic analyzer up to all of the signals that form the Twiggy interface and send me the trace while you insert a disk into the drive? That should help narrow things down a lot.

Quote from: AlexTheCat123 on September 05, 2026, 05:17:45 PM

Quote from: slewis1962 on September 04, 2026, 11:11:54 PMIn the third photo that is a passive board I made several years ago to more easily probe the signals going to the twiggy drive. That is where I can measure and verify I have 5v, -5v, and 12v on the correct pins. And also to probe any signals with a scope or a logic analyzer.

That breakout board is INCREDIBLY helpful! Could you hook a logic analyzer up to all of the signals that form the Twiggy interface and send me the trace while you insert a disk into the drive? That should help narrow things down a lot.

I'll have to get everything set up. I want to do that on a real Lisa first to get a baseline. The first thing I'm going to do tonight is probe my cables to make sure all the connections are there. My 20 pin cables are from Amazon and my 26 pin cables were made at home. I just assumed everything would be alright and they would work so I never tested them but with my problems I need to verify. I'm also going to connect a 3.5" Lisa drive to make sure my LisaFPGA has no problems. I can't seem to find my Floppy Emu at the moment. It's in a box somewhere.

I have a few updates. First, when attempting to boot into LOS 3 I get the following error:

(https://applelisa.net/wp-content/uploads/2026/09/IMG_9475_2-scaled.jpg)

It makes no sense. It won't even give me the boot menu, it boots straight into this error and that's it. I shut off the LisaFPGA, erased the SD card and reloaded the selctor files, nothing would work. I finally changed the ROM back to the Twiggy ROM, rebooted, and was able to choose my boot image. As it was not the Twiggy image it failed to fully boot. I then changed the ROM back and hit the reset button next to the Lisa soft switch. This worked and booted into LOS 3. The only problem is, once I shut it down again I had to go through that whole process. Any ideas? I'll try it again tomorrow and see if it's still doing that.
I forgot to mention it does that with both the built in ESProfile as well as the stand alone ESProfile.

My second update is once I was fully booted into LOS 3 with an external Lisa 3.5" drive I was able to insert a disk and it read it. So, it seems my FPGA board is ok and is able to talk to a 3.5" drive. I also ohmed out the cables from the end that connects to the LisaFPGA all the way to my board. I'm wondering if the 6 pin cable is not making good contact. I have it seated as far as it will go. It may still be making a poor connection. I'm wondering if I would have better luck with female to female individual hookup wires. I have some in a box in my basement. They might fit a little tighter.

Quote from: slewis1962 on September 05, 2026, 11:55:19 PMIt won't even give me the boot menu, it boots straight into this error and that's it.

I think this is an issue with Stepleton's awesome selector software (used by the ESProFile) and/or the default values for the PRAM, depending on your point of view.

If you press a key during the self-test, you will see the startup-from menu, and then selecting a startup device works.

If you miss that opportunity, (I surmise) the values in the PRAM look like a default startup device has been selected, but doesn't fully specify which device. So when the selector loads it can't tell which parallel port it was loaded from. You can type the digit 1 and it will proceed normally. If you use a real ProFile, I expect it works normally without this hiccup.

As far as I can tell, the integrity check the ROM does on the PRAM values at startup doesn't catch some of the scrambled permutations, and I suppose the default values in the LisaFPGA match one of these (all zeros perhaps).

I see there is a 93C56 eeprom on the LisaFPGA... perhaps that can be used as actual persistent PRAM?

Otherwise, we should probably come up with a new set of default values to request. IIRC there is another problematic PRAM value that makes the MacWorks XL mouse double-click insanely short, so double-click won't work until one changes the setting in the control panel. Other options may be short RAM test and I suppose startup defaults to the primary parallel port.

edit: corrected description of the selector

It is the Selector software you're seeing here, and my own LisaFPGA shows the same behaviour. I can just press 1 to select the built-in parallel port, and it works fine from there. @slewis1962, does pressing 1 when you see this screen not work for you?

If we're getting this far, then the ProFile is working and the Selector is successfully loading and running from it. And I generally unplug my (no batteries) Lisas all the time: sometimes using the STARTUP FROM... menu and other times just booting directly. On real hardware, I've never seen this problem. On my LisaFPGA, it happens whether I use the STARTUP FROM... menu or not. (Edit: I checked again: it ONLY happens if I boot naturally and it NEVER happens if I use the STARTUP FROM... menu.)

It didn't do this on my LisaFPGA until I upgraded the firmware the first time. It has done this ever since (at least with an H/A8 ROM configuration).

Note that the Selector never talks to the PRAM itself.

---

Working through the problem:

So before the Selector reads the list of images from the hard drive and posts the hard drive image selection menu, it checks to see (https://codeberg.org/stepleton/cameo/src/branch/master/aphid/selector/selector_ui.x68#L50) whether the hard drive is a Cameo/Aphid, an ESProFile, or any other disk capable of honouring the Selector "magic blocks" protocol (https://codeberg.org/stepleton/cameo/src/branch/master/aphid/selector/PROTOCOL.md). This check is failing.

A look at the routine that does the check (https://codeberg.org/stepleton/cameo/src/branch/master/aphid/selector/drive.x68#L154) shows a number of reasons the check could fail. Some of them can happen because talking to the hard drive emulator fails, or because it doesn't see the special byte sequence in the $FFFFFF block that says that the emulator supports the Selector protocol. But as I've pointed out when i complained about this problem earlier, I've checked the contents of the $FFFFFF block myself and always found it to have this marker. There is probably another reason.

The Selector always has an idea of which of seven possible parallel ports (the internal parallel port and six possible expansion cards) it could be talking to --- that's called "the current hard drive" or "the current port" or something similar. (In the code, it's called "zCurrentDrive".) The HD emulator check routine calls this routine (https://codeberg.org/stepleton/cameo/src/branch/master/aphid/selector/drive.x68#L134) that confirms that the current parallel port is actually connected to a hard drive. The routine doesn't actually talk to hardware; it just looks up the current port in a table that the Selector has built earlier when it scans all the possible parallel ports for hard drives. This check can fail if (a) the current parallel port is invalid or (b) if the table says that there's no hard drive on the current parallel port.

Going back to my LisaFPGA, I can confirm that an H/40 ROM configuration (H ROM with a Twiggy I/O board) boots the Selector successfully but that an H/A8 (H with Sony) will not. If I take a slow-motion video of the Selector's own boot screen (shown and then cleared away before the screen in @slewis1962's post), I see a flash of what looks like:

Connecting to the boot drive: ?invalid drive?... failed

This is happening here (https://codeberg.org/stepleton/cameo/src/branch/master/aphid/selector/narrated.x68#L107), where the drive is being identified by reading the byte at $1B3. We normalise that byte to turn the identifier $00 to $02 if needed (since the boot ROM on a 2/10 uses $00 and $02 interchangeably to refer to the internal parallel port, and $02 works in all non-expansion-card parallel port cases), then call PrintParallelPort (https://codeberg.org/stepleton/cameo/src/branch/master/aphid/selector/narrated.x68#L384). PrintParallelPort compares that byte to a set of valid parallel port identifiers, and if none match, it prints ?invalid drive?.

So I think this is a major part of the problem. Per the boot ROM manual (https://www.bitsavers.org/pdf/apple/lisa/Lisa_Boot_ROM_Manual_V1.3_Feb84.pdf) (PDF page 25), location $1B3 is supposed to say the location of the boot device. On the LisaFPGA running H/40, this location appears to wind up having something unexpected in it.

Trying to find what this strange thing could be... If I press the NMI key at any point during the hard drive loading process and then go into Service Mode, the contents of $1B3 appear to be $00, which is suspicious. At that page in the Boot ROM manual, it says that $00 is for a built-in hard drive, which arguably an H/A8 computer should not have (note that the manual appears to use "parallel port" and "builtin hard drive" to mean different things). If I try an H/40 ROM, then $1B3 appears to be $02, which is as expected per the manual.

Ah! Now remember that byte normalisation that turns $00 into $02. It only happens on a Lisa 2/10 (https://codeberg.org/stepleton/cameo/src/branch/master/aphid/selector/narrated.x68#L110), something that's registered by a value of $03 at memory location $2AF. On the LisaFPGA, a H/40 ROM configuration has $2AF = 0 ("Lisa 0" per Boot ROM manual PDF page 27), while an H/A8 ROM has $2AF = 1 ("Lisa 2 with Sony, old I/O board (slow timers)"). So it won't convert $00 into $02. $00 is not a valid hard drive identifier for the Selector or the code it depends on.

If this theory is correct, then we have a testable prediction: shorting GPIO0 to 3V3, making our Lisa into a 2/10, will find the Selector booting successfully. Let's try it: yes! And in Service Mode, $2AF  = $03. (Even though it maybe should really be a different value meaning "Lisa 2/10 with Sony, some I/O board with slow timers, internal disk." You can tell the slow timers by the lower pitch of the boot ROM beeps when running at the stock clock frequency!)

(NB: Other minor edits were made for clarity)

Questions in a separate post since the one before is probably too long:

1. The problem appears to be that the LisaFPGA, when booting from the internal parallel port in an H/A8 configuration, sets $1B3 to $00 and not $02. @AlexTheCat123, is this as expected?

2. Does anyone use the Selector (the drive image boot menu) with a real Lisa 2/5? Do you ever see the problem @slewis1962 reported (https://lisalist2.com/index.php/topic,694.msg6417.html#msg6417)? Either way, what happens if you quit the Selector (press Q from the hard drive image menu), then enter Service Mode (press Apple-S), then type 1 (for DISPLAY MEM), then 1B3<return> (for ADDRESS?), then 1<return> (for COUNT?)? What do you see if you then type 1, then 2AF<return>, then 1<return>?

Quote from: stepleton on September 06, 2026, 07:51:01 AM1. The problem appears to be that the LisaFPGA, when booting from the internal parallel port in an H/A8 configuration, sets $1B3 to $00 and not $02. @AlexTheCat123, is this as expected?

No, I never even touch $1B3! The boot ROM is the only thing that messes with it. My (very quick and possibly inaccurate because I have two homework assignments I need to get done) scan of the boot ROM listing seems to indicate that $1B3 only gets set if the user typed a boot command, and NOT if the system is trying to autoboot, so perhaps this is happening because it's autobooting and nothing overwrites the default value that's in RAM, which happens to be 0?

Quote from: stepleton on September 06, 2026, 07:51:01 AM2. Does anyone use the Selector (the drive image boot menu) with a real Lisa 2/5? Do you ever see the problem @slewis1962 reported (https://lisalist2.com/index.php/topic,694.msg6417.html#msg6417)? Either way, what happens if you quit the Selector (press Q from the hard drive image menu), then enter Service Mode (press Apple-S), then type 1 (for DISPLAY MEM), then 1B3<return> (for ADDRESS?), then 1<return> (for COUNT?)? What do you see if you then type 1, then 2AF<return>, then 1<return>?

I've seen it occasionally on real hardware, although I've always just dismissed it as a fluke and never really paid attention to when/why it happened. I feel like I've probably noticed it more after cold boots than warm boots/resets, but I don't have any concrete evidence to back that up.

Quote from: AlexTheCat123 on September 06, 2026, 03:38:24 PMI never even touch $1B3! The boot ROM is the only thing that messes with it.

At 16E8 and 16FE the ROM checks to see if the startup-from menu is requested, if not, at 1706 it checks to see if PRAM is valid.

If PRAM appears valid, at 1722 it loads the stored boot device id from PRAM into D0.

Then at 1754, D0 is stored in $1B3. (The ROM listing I'm looking at is misformatted: the bytes of the instruction at 1754: 11C0 01B3 are not shown in the listing, it just increments the PC, making it look like there is no instruction there... the instruction is in the ROM binary.)

The PRAM checksum algorithm is simply adding with some rotates then checking if the sum is zero, so all zeros looks valid.

Suggest defaulting the PRAM to some other value.

Quote from: sigma7 on September 06, 2026, 01:47:30 AM

Quote from: slewis1962 on September 05, 2026, 11:55:19 PMIt won't even give me the boot menu, it boots straight into this error and that's it.

I think this is an issue with Stepleton's awesome selector software (used by the ESProFile) and/or the default values for the PRAM, depending on your point of view.

If you press a key during the self-test, you will see the startup-from menu, and then selecting a startup device works.

If you miss that opportunity, (I surmise) the values in the PRAM look like a default startup device has been selected, but doesn't fully specify which device. So when the selector loads it can't tell which parallel port it was loaded from. You can type the digit 1 and it will proceed normally. If you use a real ProFile, I expect it works normally without this hiccup.

As far as I can tell, the integrity check the ROM does on the PRAM values at startup doesn't catch some of the scrambled permutations, and I suppose the default values in the LisaFPGA match one of these (all zeros perhaps).

I see there is a 93C56 eeprom on the LisaFPGA... perhaps that can be used as actual persistent PRAM?

Otherwise, we should probably come up with a new set of default values to request. IIRC there is another problematic PRAM value that makes the MacWorks XL mouse double-click insanely short, so double-click won't work until one changes the setting in the control panel. Other options may be short RAM test and I suppose startup defaults to the primary parallel port.

edit: corrected description of the selector

This is really embarrassing. I got my first Lisa in 1991 or 1992. I used to know all this stuff. I guess since my Lisa's have been sitting on a shelf since I archived the Twiggy Basic disks sometime in 2012 I have forgotten the basics! Anyway, I typed 1 and it gave me the selector menu. Thanks for the help.

Quote from: stepleton on September 06, 2026, 07:44:45 AMIt is the Selector software you're seeing here, and my own LisaFPGA shows the same behaviour. I can just press 1 to select the built-in parallel port, and it works fine from there. @slewis1962, does pressing 1 when you see this screen not work for you?

Yes it does. As I said in my previous post I seem to have forgotten all that I knew years ago due to my Lisa's sitting on a shelf for almost 14 years! I appreciate the help!

Quote from: stepleton on September 06, 2026, 07:51:01 AMQuestions in a separate post since the one before is probably too long:

1. The problem appears to be that the LisaFPGA, when booting from the internal parallel port in an H/A8 configuration, sets $1B3 to $00 and not $02. @AlexTheCat123, is this as expected?

2. Does anyone use the Selector (the drive image boot menu) with a real Lisa 2/5? Do you ever see the problem @slewis1962 reported (https://lisalist2.com/index.php/topic,694.msg6417.html#msg6417)? Either way, what happens if you quit the Selector (press Q from the hard drive image menu), then enter Service Mode (press Apple-S), then type 1 (for DISPLAY MEM), then 1B3<return> (for ADDRESS?), then 1<return> (for COUNT?)? What do you see if you then type 1, then 2AF<return>, then 1<return>?

This is what I get on my LisaFPGA board. I'll try later with my actual Lisa.
(https://applelisa.net/wp-content/uploads/2026/09/IMG_9477-scaled.jpg)

*EDIT*
I used the selector with Alex's ESProfile the other day for the first and only time on my Lisa 1. I didn't have any problem and it booted up to the normal selector menu. I'll try it on my 2/5 or 2/10 later on. I also have a MacXL which I could try it on.

Quote from: AlexTheCat123 on September 06, 2026, 03:38:24 PMNo, I never even touch $1B3! The boot ROM is the only thing that messes with it. My (very quick and possibly inaccurate because I have two homework assignments I need to get done) scan of the boot ROM listing seems to indicate that $1B3 only gets set if the user typed a boot command, and NOT if the system is trying to autoboot, so perhaps this is happening because it's autobooting and nothing overwrites the default value that's in RAM, which happens to be 0?

I wonder if this commit (https://github.com/alexthecat123/LisaFPGA/commit/2b2e72e7b7d794bc5d91901c5cc55b7dd0d481f6) fixed a bug that was also causing us to get "lucky" when the boot ROM talked to the floppy controller; maybe it read a different value from the PRAM before that somehow?

Quote from: sigma7 on September 06, 2026, 04:08:50 PMIf PRAM appears valid, at 1722 it loads the stored boot device id from PRAM into D0.

...

The PRAM checksum algorithm is simply adding with some rotates then checking if the sum is zero, so all zeros looks valid.

Interesting. On a real Lisa 2/5 (without batteries) that has just been plugged into the wall, odds are that the PRAM is initialised to random values with a checksum that doesn't match. If so, then CHKPM fails at $1706, and then if CHKPROFILE at $1714 sees a ProFile on the parallel port, then we decide to boot from that ProFile at $171E.

But if the PRAM contains all zeroes, then it's valid (as you say) and the boot device is $00, which is as good as $02 for booting from the ProFile to the boot ROM

I think it's a Selector bug to fail in this way, so I will probably change the code here (https://codeberg.org/stepleton/cameo/src/branch/master/aphid/selector/drive.x68#L315) to promote $00 to $02 for all Lisas except a Lisa 1. So a version bump from 1.0 to 1.01 is pending...

Quote from: slewis1962 on September 06, 2026, 05:46:27 PMYes it does. As I said in my previous post I seem to have forgotten all that I knew years ago due to my Lisa's sitting on a shelf for almost 14 years! I appreciate the help!

I'm glad it helps! But the Selector software itself is only five years old; it was written in the depths of COVID. So there's no old knowledge that you have lost here. (For me that's something that's reassuring to hear  :) ).

Quote from: slewis1962 on September 06, 2026, 05:50:02 PMI used the selector with Alex's ESProfile the other day for the first and only time on my Lisa 1. I didn't have any problem and it booted up to the normal selector menu. I'll try it on my 2/5 or 2/10 later on. I also have a MacXL which I could try it on.

Thanks for trying on the Lisa 1; what you see matches my expectations based on today's investigation (and also my experience). The 2/5 specifically is the system of primary interest for this test, especially when you start it up for the first time after unplugging it and plugging it back in; the rest shouldn't behave in an unexpected way (I hope). But I'm betting it just works, since the boot PRAM probably won't be initialised to zeros. It would still be helpful to confirm it, of course!

Quote from: stepleton on September 06, 2026, 06:52:10 PMI wonder if this commit (https://github.com/alexthecat123/LisaFPGA/commit/2b2e72e7b7d794bc5d91901c5cc55b7dd0d481f6) fixed a bug that was also causing us to get "lucky" when the boot ROM talked to the floppy controller; maybe it read a different value from the PRAM before that somehow?

I was pondering this earlier and came to the same conclusion. Perhaps the stack corruption was touching PRAM values and causing them to be nonzero, making the checksum fail and causing the values to get reset to good defaults?

Quote from: stepleton on September 06, 2026, 06:52:10 PMI think it's a Selector bug to fail in this way, so I will probably change the code here (https://codeberg.org/stepleton/cameo/src/branch/master/aphid/selector/drive.x68#L315) to promote $00 to $02 for all Lisas except a Lisa 1. So a version bump from 1.0 to 1.01 is pending...

Even so, I think I should probably still make PRAM initialize with garbage instead of 0's to be more accurate to the original hardware. My goal is 100% accuracy (or as close to that as I can realistically get), and the fact that the Selector works on real hardware but shows weird behavior here means that I'm not quite there yet.

Quote from: stepleton on September 06, 2026, 07:51:01 AMQuestions in a separate post since the one before is probably too long:

1. The problem appears to be that the LisaFPGA, when booting from the internal parallel port in an H/A8 configuration, sets $1B3 to $00 and not $02. @AlexTheCat123, is this as expected?

2. Does anyone use the Selector (the drive image boot menu) with a real Lisa 2/5? Do you ever see the problem @slewis1962 reported (https://lisalist2.com/index.php/topic,694.msg6417.html#msg6417)? Either way, what happens if you quit the Selector (press Q from the hard drive image menu), then enter Service Mode (press Apple-S), then type 1 (for DISPLAY MEM), then 1B3<return> (for ADDRESS?), then 1<return> (for COUNT?)? What do you see if you then type 1, then 2AF<return>, then 1<return>?

This is from my Lisa 1 with D/40 ROMS. It booted into selector with no problems.

(https://applelisa.net/wp-content/uploads/2026/09/IMG_9488-2-scaled.jpg)

This is from my Lisa 2/5 with H/A8 ROMS. It also booted into selector with no problems.

(https://applelisa.net/wp-content/uploads/2026/09/IMG_9485-scaled.jpg)

Thanks for that --- interesting to see that 02 right there after the BF, but perhaps not unexpected given the discussion we've been having. Had you already booted this Lisa at least once before (and left it plugged in after that), or is it right after having the Lisa unplugged and then plugging it back in? I suspect it doesn't matter, but there's a very slim chance it might.

Quote from: stepleton on September 07, 2026, 04:57:35 PMThanks for that --- interesting to see that 02 right there after the BF, but perhaps not unexpected given the discussion we've been having. Had you already booted this Lisa at least once before (and left it plugged in after that), or is it right after having the Lisa unplugged and then plugging it back in? I suspect it doesn't matter, but there's a very slim chance it might.

This is first thing after booting. I pulled it off the shelf and plugged it in. It booted to selector, I chose Q, then hit apple-s.

thanks! It's consistent with the theory that uninitialised PRAM is in a random, invalid state; it's not all zeroes.

Quote from: ried on August 27, 2026, 09:12:04 PMGood news, everyone! In today's episode of "Testing Random Amazon Power Bricks" we found a winner.

This suggestion from sigma7 allows the upper Twiggy to work just fine. No issues with reading, writing, or ejecting. This encouraged me to try the lower Twiggy drive also, just to see if it'd work. The spindle motor still does not run in that drive when it's connected... However everything else seems to work. The carriage moves, and eject works. The spindle motor not spindling was previously discovered by sigma7 (https://lisalist2.com/index.php?msg=6148) and seems to remain that way with current firmware.

In any event, the upper Twiggy works just fine with that particular power brick.

I have some fantastic news! I got some individual hookup wires and connected the 4 pin connectors with those.

(https://applelisa.net/wp-content/uploads/2026/09/IMG_9491-scaled.jpg)
(https://applelisa.net/wp-content/uploads/2026/09/IMG_9492-scaled.jpg)

I hooked the Twiggy drive to the upper connector. This was the result.

(https://applelisa.net/wp-content/uploads/2026/09/IMG_9490-scaled.jpg)

I then powered down and connected to the lower connector. This was the result.

(https://applelisa.net/wp-content/uploads/2026/09/IMG_9494-scaled.jpg)

I'll do some more testing in the next few days. I have to go back to work today. I was off for a week of vacation. I'll try and hook two drives up at the same time. I also didn't try writing or formatting. I'll try copying a file from one drive to the other. I'll get to all of that soon. The important thing is both drives can spin the motor and mount a disk.

Some more observations. When "idling" with no Twiggy activity it draws about 1 amp.

(https://applelisa.net/wp-content/uploads/2026/09/IMG_9493-scaled.jpg)

When the drive is being accessed the highest I observed was around 3.9 amps.
I don't believe the Lisa tries to access both drives at the same time but I'll note what the maximum current draw is at that time.

In case anyone wants to know my theory I believe the sense signal was flaky. The disk in place signal is sent over the sense line. My 6 pin cable was probably not making a good connection so the Lisa didn't know a disk was in place. These individual hook up wires are making a good strong connection. Just my 2 cents.

Alex, just wondering how many amps your usb-c circuitry can handle. Is this going to do any damage in the long term? I don't have a lot of experience designing boards as far as power rails go.

*EDIT*
Alex, I looked up the 12v boost converter and see that it can supply 10A so I guess that answers my question.

Quote from: slewis1962 on September 08, 2026, 10:55:30 AMthe 12v boost converter ... can supply 10A

The TPS61178 datasheet says the switching current limit is 8A +/- 1.4A ( +/-17% !) when the current limit setting resistor is 80K6. I suspect Alex's 86K6 value is close enough to consider it the same. However, I think this is not the output current limit of the circuit... if the duty cycle of the current switch were 75% then the average current would be more like 6A, and I wonder if this limit applies to the switching current at the source voltage (5V), so the overall circuit would be making 30W, or 2.5A at 12V. Perhaps (presumably?) Alex used the WEBENCH® Power Designer and may be able to recall what performance it predicted?

slewis1962's measurements suggest 2.9 Amps more draw from the overall +5 supply when the Twiggy is in use, so +14.5W and thus maybe ~1A from the 12V regulator is enough. When I look at the 12V on my drive, I see substantial spikes, but that may be completely due to my power source, or maybe the Twiggy breakout board would benefit from a big cap.

Quote from: stepleton on September 08, 2026, 03:34:07 AMtheory that uninitialised PRAM is in a random, invalid state; it's not all zeroes

I've found this depends... contents at powerup seems random/unpredictable in general, but may be consistent for a specific part. IIRC, I helped someone repair an I/O Board and after replacing the SRAM the all-zero bytes power-up problem revealed itself on a consistent basis. They had another I/O Board, so I suggested mixing the parts between the boards to get around the issue. I don't recall much about it, so I may be imagining things again.

Quote from: sigma7 on September 08, 2026, 07:21:27 PMThe TPS61178 datasheet says the switching current limit is 8A +/- 1.4A ( +/-17% !) when the current limit setting resistor is 80K6. I suspect Alex's 86K6 value is close enough to consider it the same. However, I think this is not the output current limit of the circuit... if the duty cycle of the current switch were 75% then the average current would be more like 6A, and I wonder if this limit applies to the switching current at the source voltage (5V), so the overall circuit would be making 30W, or 2.5A at 12V. Perhaps (presumably?) Alex used the WEBENCH® Power Designer and may be able to recall what performance it predicted?

I wasn't aware of the WEBENCH Power Designer when I did the first one or two regulators (which included the 12V one), so I did the calculations by hand based on the info in the datasheet. That was NOT fun, so I soon discovered WEBENCH and used it for the rest of them. But I know I went for 2A on the 12V regulator at an absolute minimum, and perhaps more than that. I was trying to match or beat the specs of the original Lisa PSU, so I know that I didn't go below that.

Here is my video showing the LisaFPGA board with dual Twiggy drives. Let me know what you think.

Quote from: slewis1962 on September 11, 2026, 06:45:58 PMHere is my video showing the LisaFPGA board with dual Twiggy drives. Let me know what you think.

YouTube is saying that the video is private.

Quote from: slewis1962 on September 11, 2026, 06:45:58 PMdual Twiggy drives. Let me know what you think.

Looks like it works, fantastic!

I see that at timestamp 0:51, with both drives running, the 5V power supply says 6.49 Amps

Quote from: sigma7 on September 11, 2026, 07:17:59 PMLooks like it works, fantastic!

How were you able to see it? The video still shows up as private for me.

Quote from: AlexTheCat123 on September 11, 2026, 07:25:59 PM

Quote from: sigma7 on September 11, 2026, 07:17:59 PMLooks like it works, fantastic!

How were you able to see it? The video still shows up as private for me.

I have no idea. It plays fine embedded in the post, and I can play the link in YouTube in a separate tab too. I'm not logged-in to Google/YouTube is the only thing that comes to mind as a potential difference.

Quote from: sigma7 on September 11, 2026, 07:50:05 PMI have no idea. It plays fine embedded in the post, and I can play the link in YouTube in a separate tab too. I'm not logged-in to Google/YouTube is the only thing that comes to mind as a potential difference.

Strange. I can't play it embedded, in a separate tab, in a separate logged-out browser, or anywhere. I guess it doesn't matter as long as we know that the Twiggies work, although I would like to see them!

Here it is again. I changed some settings. Hopefully this will play now. If not I'll delete and re-upload. I first published it through iMovie and accidentally set it to private. I published it and then changed to public at that time. Maybe that messed something up.

Quote from: sigma7 on September 11, 2026, 07:17:59 PM

Quote from: slewis1962 on September 11, 2026, 06:45:58 PMdual Twiggy drives. Let me know what you think.

Looks like it works, fantastic!

I see that at timestamp 0:51, with both drives running, the 5V power supply says 6.49 Amps

I actually saw around 7.5 amps the other day while I was testing with both drives. I noticed with one drive connected it was showing right at 1 amp when the drive was idle and with both drives connected around 1.5 amp while both drives are idle.

If that doesn't work you can try searching YouTube for "Dual Twiggy drives on a LisaFPGA board"

I re-uploaded it just to be sure it is viewable by everyone.

Awesome! Congrats!  8)

Quote from: ried on September 12, 2026, 12:27:46 AMAwesome! Congrats!  8)

Thanks!

Great to see this, but 37 watts is quite a draw! I'm glad to know that this is what's needed.

Quote from: stepleton on September 12, 2026, 04:59:47 AMGreat to see this, but 37 watts is quite a draw! I'm glad to know that this is what's needed.

I'm not sure what exact conditions caused the 7.5 amps the other day. I had two disks in just like in this video but it didn't get that high. Unless I just happened to catch the peak that day. I imagine a data logger of some kind could give a more accurate representation of what's normal.

It's great to see both drives working! That's some pretty crazy power consumption though. When I designed the board, I was guessing about 2A max when the drives were active (spindle on and seeking), so 7.5A is absolutely crazy. To be fair though, I had no way of knowing given that I don't have any Twiggies myself!

Quote from: AlexTheCat123 on August 28, 2026, 01:17:59 AMThat's great!!! One drive confirmed to be fully-working. I wonder what's going wrong with the lower drive though? You are running the latest firmware that's supposed to fix the bug, right?

I jumped back into this today, suspecting that the four-pin TWIG port on the board and the AUX IN on the breakout board might not be making good connections via that 6-pin cable. I bent the prongs further up on each and, sure enough, now the lower drive's spindle motor spins just fine.

I've got a 2 part question. Has anyone successfully initialized a "new" Twiggy disk on their LisaFPGA board? I made a new disk today and tried to initialize it but it failed. I then booted into service mode and attempted to do a format which failed. I should also explain that I have several disks which I initialized or formatted between 14 and 24 years ago that would not read under the LisaFPGA board. I then tried to format them from service mode and was unsuccessful.

So today after the failures I pulled out my real Lisa 1, booted into LOS 1.0, and tried to initialize my new Twiggy disk. I was unsuccessful there also. But when I booted into service mode I was able to successfully format a disk and then LOS 1.0 was able to mount it. I then pulled out the other disks which failed under the LisaFPGA board and several of them failed under a real Lisa also. One was able to format but when I booted into LOS it said the disk was damaged but was unable to repair it and I didn't get the option to initialize it. I'm just wondering what could be different between the real Lisa and the LisaFPGA board in regards to service mode and formatting disks.

The second question is, I'm wondering if the error code I get in service mode, error 15 unable to verify, is because it is having issues with an underlying format or underlying data already on the disk which is interfering with the format or initialization. Has anyone used a bulk tape eraser on a Twiggy disk? I saw a video in the last year or so on "Adrian's digital basement" where he used a bulk eraser to "fix" some diskettes, 3.5" not Twiggy, that wouldn't format. I'm considering getting one off of ebay but thought I would ask the list first in case anyone has any experience in that area.

Thanks in advance.

Quote from: slewis1962 on September 13, 2026, 08:03:10 PMHas anyone used a bulk tape eraser on a Twiggy disk?

BLU has a "zero disk" function that writes nothings over the entire disk, "effectively un-formatting it".

Dunno if it would help in this case. I'd try it on the real Lisa first. ymmv

Quote from: sigma7 on September 13, 2026, 08:59:27 PM

Quote from: slewis1962 on September 13, 2026, 08:03:10 PMHas anyone used a bulk tape eraser on a Twiggy disk?

BLU has a "zero disk" function that writes nothings over the entire disk, "effectively un-formatting it".

Dunno if it would help in this case. I'd try it on the real Lisa first. ymmv

I'll have to try that first. My real Lisa is still set up so I don't have to get it out again.