A Lisa Inside An FPGA

[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 

[AlexTheCat123]

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

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

[AlexTheCat123]

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!

[AlexTheCat123]

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

[stepleton]

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?