News:

2022.06.03 added links to LisaList1 and LisaFAQ to the General Category

Main Menu

A Lisa Inside An FPGA

Started by AlexTheCat123, September 04, 2025, 05:20:35 PM

Previous topic - Next topic

AlexTheCat123

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!

AlexTheCat123

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!

stepleton

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.

AlexTheCat123

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

stepleton

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, though I have no theory that can account for why it should cause that trouble.

AlexTheCat123

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!

AlexTheCat123

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!