Print

[AlexTheCat123]

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!

[stepleton]

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!

[bmwcyclist]

Fantastic!

Please keep us updated!

[AlexTheCat123]

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.

What 68k core are you using?

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

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.

[AlexTheCat123]

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.

[bmwcyclist]

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

[AlexTheCat123]

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

[AlexTheCat123]

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!

[bmwcyclist]

Thanks for your work!

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

[AlexTheCat123]

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

[classiccomputing]

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

[jamesdenton]

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!

[AlexTheCat123]

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.

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!