LisaList2

The Office System only included LisaDraw, and my understanding (based on asking someone who would know) is that a paint appliction wasn't really considered. A "LisaPaint" tool in the style of MacPaint and MousePaint (which amusingly used Lisa UI styling) seems like it would be both straightforward and useful, since in a certain sense it can be "just" a wrapper around QuickDraw.

One thing that stands out to me from reading some of the writeups is that getting files to and from Lisa is a pain. It seems like one possible option would be a Kermit implementation: The protocol is designed to be simple, robust, and work over variable-speed 7-bit half-duplex channels, with an open-ended feature set that can include things like directory listing and put/get functionality.

The HP-48SX used it for its computer interface to very good effect. This even allowed it to support an external 3.5in floppy drive with an RS-232 interface and Kermit support; it could list, read, write, and delete files on DOS floppies tht way.

A "Kermit service" on Lisa could even conceivably run as a background process to allow access to a Lisa's mounted filesystems via one of the serial ports. Then something like a FUSE module could be used to work with those files "transparently" in your favorite editor on a modern system, while still doing builds etc. on Lisa under Workshop.

(Note that I'm not suggesting a port of C-Kermit, which is a pretty large and complex project, but a Lisa-specific implementation focused on a couple high-level goals like fast-and-accurate transfers and providing filesystem access.)

FreePascal is going to be extremely different than Lisa Pascal and I don't think a port would be very straightforward at all, especially since Lisa Pascal makes use of a whole bunch of subtle customizations on top of the compiler Apple licensed like the stack probe insertion.

Since its source is floating around, there's a lot that could be done to improve Edit to make the overall experience of development on Lisa more pleasant. (And if Workshop source is similarly floating around, that would also be a good thing to put some work into improving.)

An SD driver would be useful; the OS 3.0 block driver model (which splits things into high-level and low-level drivers) could make it straightforward, and enable the use of large volumes—though they'd still be limited to 32761 files, since S-file IDs are 16-bit signed integers and 0-4 and 32767 are reserved.

Unless you were thinking of using a parallel port adapter, you might also be talking about building an SD I/O card. That would also be interesting as we now have enough information to not only write a proper "loader loader" for a new volume type, but also enough information to implement a boot ROM for a new card. And if one's talking about a new card anyway, one may as well stick an ESP32 or Pico between the Lisa and the SD interface to simplify everything further.

A SCSI driver, loader loader, and boot ROM would also be useful, of course, and also in theory shouldn't be too difficult. But the effort:reward ratio might be better for SD given that SCSI isn't exactly modern either.

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

This is some excellent work, Alex! Here's hoping this will lead to lots of interesting hacking!

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!

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!

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

Quote from: stepleton on January 28, 2026, 06:14:50 PMHa, neat! AI can certainly automate a lot of tasks... As I was writing Lisavox, I felt that the choice to hand-code everything was basically an indulgence on my part; I could have asked an AI to take care of most of the Python in particular and it would surely have done fine.

Yep, I have a personal rule for the LisaFPGA project that I don't use any AI-generated code anywhere in it, although I absolutely do use AI for help when I get stuck debugging. It makes it a whole lot easier to understand weird little quirks of FPGA design that you wouldn't otherwise know unless you read thousands of pages of Xilinx documentation!

Given that it seems to be working pretty well right now, I'll probably just leave the code alone for the sake of not wanting to break it, but that's a really good idea about feeding a big program through to confirm that it's fully-functional. I'll give that a try if/when I get the chance!

Quote from: stepleton on January 28, 2026, 06:14:50 PMI wonder what the COP issue was. Do you think you'll be able to break the 60 MHz barrier?

Give me a second and I'll explain that back over in the LisaFPGA thread!