News:

Want an XLerator? Please participate in the market research thread: https://lisalist2.com/index.php/topic,594.msg4180.html

Main Menu

A Lisa Inside An FPGA

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

Previous topic - Next topic

AlexTheCat123

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!

AlexTheCat123

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!

AlexTheCat123

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

ried

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

AlexTheCat123

Quote from: ried on Yesterday at 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!