LisaList2
General Category => LisaList2 => Topic started by: AlexTheCat123 on September 04, 2025, 05:20:35 pm
-
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!
-
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!
-
Fantastic!
Please keep us updated!
-
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 (https://github.com/ijor/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.
-
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.
-
Wow! reminds me of when Dr. Chandra revived HAL in Odyssey 2 ;)
-
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...
-
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!
-
Thanks for your work!
I wish I could help, but that is way out of my skill sets...
-
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...
-
Wow, this is big news, and thank you for your efforts Alex! I can't wait to own one, and I will want one.
-
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!
-
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!
-
Thank you so much !
-
The video problems have been fixed; it turns out that they were being caused by a RAM timing issue where video reads from RAM were occasionally causing addresses adjacent to the current read address to be overwritten with random garbage. This one was really subtle and took a long time to figure out!
I've moved onto the I/O board now, and I've finished the initial design of the whole thing other than Page 2 of the original schematics, which contains the keyboard VIA and the COP. Since the COP core I found is in VHDL, whereas the rest of my code is in SystemVerilog, and I'm a bit nervous about integrating the two, I think I'm going to implement everything but the COP and then come back for that later. We should still get waayyy further in the boot process even in its absence.
Some people might be wondering what cores I'm using for the 6504, 6522s, 8530 SCC, and the (yet to be integrated) COP. Well, no 6504 cores seem to exist, so I'm using this (http://www.aholme.co.uk/6502/Main.htm) transistor-accurate 6502 core instead. As for the 6522 and 8530, I'm using the cores from the NanoMac project (https://github.com/MiSTle-Dev/NanoMac/). The 6522 core seems really accurate and fully-featured, but the SCC core leaves a lot to be desired; it seems to just implement the bare minimum to get the Mac to work and leaves out a lot of I/O lines used by the Lisa. But it's the only 8530 that I could find, and it should at least get us booting. And last but not least, the COP. I'll be using the T400 (https://github.com/devsaurus/t400) core, which as I said is written in VHDL instead of Verilog, which hopefully won't cause too many headaches. It also has a really weird/unpleasent way of reading in the ROM (you have to run a script that generates a VHDL file that's essentially a massive case statement for each ROM address instead of just using $readmemh) and some weird platform-specific scripts that you have to run, so I'm hoping that none of that causes a problem.
I should be able to start testing the I/O board in simulation by tonight or tomorrow, and then in actual hardware whenever I get all the simulation kinks worked out!
-
The 6504 is a 6502 with some pins not connected. Both parts use the same silicon die. So you can use the 6502 core and ignore the upper address lines.
-
The 6504 is a 6502 with some pins not connected. Both parts use the same silicon die. So you can use the 6502 core and ignore the upper address lines.
Yep, that's exactly what I'm doing!
-
Time for another progress update!
I'm in the process of testing and working out the kinks on the I/O board, and it's getting pretty far in its series of tests.
The boot ROM actually does a decent bit of testing on the I/O board before it even puts up the "Testing..." screen, with only a relatively small amount of testing happening during the "I/O board test" that you actually see occurring after the RAM test completes. Once it gets through that initial I/O board test, it actually goes back and does some additional CPU board tests (this is what's happening when the CPU icon is highlighted on the Testing... screen) and this exposed a few more minor problems with the CPU board. Namely that the "write wrong parity" and vertical sync interrupt circuits weren't working right, but those have now been fixed and I think it's safe to say that the CPU board is fully-functional.
It also completes the long RAM test just fine (the one that you see on the Testing... screen), so that's some additional confirmation that memory addressing and parity checking is working fine!
As for the I/O board itself, both VIAs seem to be working flawlessly, and the COP seems to be executing code and putting out its ready signal like it's supposed to. The boot ROM isn't making it to the in-depth COP test yet (that's the very last test that it does on the I/O board), but the preliminary test at least looks good.
Communications with the SCC seem to work fine too, although the SCC core I found from the NanoMac project is insanely limited, to the point that it doesn't even support the internal loopback mode that the Lisa uses during the self-test. For now, I've just patched the loopback test out of the boot ROM, and I'll come back and improve the SCC core later. Reading and writing all the SCC registers seems to work great though!
The only two tests left in the I/O board phase of testing are the floppy controller and extended COP tests, and it's stuck on the floppy controller right now. Up until yesterday, the floppy controller was actually completely dead, but I've got it in a much better state now. It's now happy enough that it puts its ROM revision in the shared RAM for the 68000 to read, and the 68K reads the A8 just fine. And it seems to be able to address and control all the floppy drive control signals as well. I'm not 100% sure if the LS323/P6A PROM/LS174 state machine is working the way it's supposed to, but it at least seems to be running and doing something.
The current issue with the floppy controller is that it's failing its initial self-test, which the boot ROM notices when it reads the test results from the shared RAM, causing it to abort testing at that point. Luckily, I know why it's failing: for some reason, the floppy controller thinks a drive is connected, even though there isn't one, and so it tries to seek the heads back to track 0. But even after sending the seek command 80 times, the track 0 indicator bit still doesn't turn on (because there's no drive connected to turn it on), so the floppy controller thinks that either the drive or controller is defective and sets an error bit in the self-test result byte. So I just need to figure out why it thinks there's a drive connected when there's actually not.
After that, it's just the COP test, and then the I/O board should be done (aside from the SCC fix of course). The only thing left in the boot ROM's self-test after that is the scanning of the expansion slots for cards, but I don't have any cards "inserted", so it shouldn't detect anything and will hopefully just breeze through that test just fine.
At that point, we should be at the boot menu, where my next step will be getting a keyboard and mouse hooked up and interfacing with the COP so I can actually control things. I think I might try to hook up a USB keyboard and mouse, or PS/2 at the very least. And after that, I think connecting a ProFile would be a good idea. Not sure if this is even a thing, but if an ESP32 Verilog/VHDL core exists, I might even be able to integrate the functionality of ESProFile straight into the FPGA; no external drive or emulator needed!
-
Okay, I'm very nearly to the point where I can get to the boot menu consistently!
In fact, the FDC and extended COP tests work great in simulation and I'm able to get to the menu there every time just fine, but I'm still having a minor problem on the actual hardware, although it's proving to be pretty annoying.
When running on the actual FPGA, sometimes the FDC RAM gets corrupted and causes the Lisa to fail the self-test with an Error 57, and other times it passes just fine and makes it to the "no keyboard connected" and then Startup From... menu. It looks like the problem has to do with setup time issues with the addresses going to the floppy controller RAM, which of course only show up in actual hardware where you've got propagation delays to worry about. I've tried some strategies to fix the address issue (like delaying the RAM CS signal so that it wouldn't arrive until a 16MHz clock cycle later after things are stable), which helped, but then that has introduced weird edge cases where things completely break if the 68K tries to access the floppy controller RAM at the wrong time and interrupts the delayed CS pulse from the 6504. So I'm now trying out another solution, which will hopefully do the job a bit better. I'm super close though!
-
It must be an inspiring site to see it go through the pre-boot hardware check and then come up with the "no keyboard connected"!
-
I don't have much to offer to help along this journey, but every time I see that there's another update to this thread I get pretty excited. Go Alex go!
-
Still getting the "no keyboard connected" icon, but the good news is that the mouse is now working!
I hooked up a Macintosh mouse, and it works! FPGAs aren't 5V-tolerant, but the Mac mouse requires 5V since it's got a TTL logic chip inside, so I was pretty worried about what do do there, given that I'd rather not add any additional complexity in the form of level shifters until I get to the point of designing a custom PCB. But luckily, I discovered that certain mice would actually function fine on 3.3V, although it took about 5 or 6 mice before I found one that would.
I was initially trying to hook up a USB mouse, only to discover that my FPGA dev board doesn't actually have a USB host controller on it, just a USB line driver. Given that my FPGA (a ZYNQ 7020) has an ARM core inside it, I think they were expecting that to handle the USB protocol, but obviously we're not even using that here at all! And I don't feel like implementing the entire USB protocol from the ground up in Verilog, so USB support will probably just need to wait until I make a custom PCB with a host controller.
I've plugged up the keyboard now too, although it's not working yet. Well actually it's a USB to Lisa keyboard adapter because believe it or not, despite having three Lisas, I somehow don't have an actual Lisa keyboard! But regardless, something's keeping it from working. Not sure what though; I've probed the line with a scope and the COP is clearly sending out sync pulses that the keyboard responds to with data whenever I press a key. And the keyboard sends a reset packet too whenever it powers up, so it doesn't look like the issue is anything with the physical line itself.
I'm not sure how tight the timings have to be on the keyboard signals (maybe @patrick would know thanks to his reverse-engineering of the protocol), but my current suspicion is that the COP's clock is slightly off and it's not quite in step with the signals coming from the keyboard. The sync pulses generated by the COP are supposed to be 20us but are more like 13us in my case, so I think there might be something to this theory. The PLL inside the FPGA isn't producing exactly 3.9MHz like the COP expects, although it's only off by a little and I figured that it wouldn't be enough to matter. But to test my theory, I'm going to expose the COP's clock to an I/O pin and feed it from a function generator so I can fine-tune the clock and see if I can get that sync pulse tuned to exactly 20us. Then it should hopefully be perfectly in sync with the timings it expects from the keyboard, and maybe then it'll actually detect it properly!
Still having intermittent issues with the floppy controller, but I want to get the keyboard and mouse working before I go any further with that so I can go into service mode and write bytes straight into the FDC's shared RAM to try and diagnose the problem.
-
I occasionally would have delays or issues with my USB to keyboard adapter. Typically, right after a power on. Might’ve been my individual keyboard or equipment though so consider it anecdotal.
-
Luckily, it wasn't a problem with the keyboard adapter! It was a combination of accidentally having the wrong clock divider value set for the COP (/8 instead of /16) and forgetting to gate the output of the keyboard reset signal with the VIA's DDR so that it's not stuck low the entire time the computer is in reset. So now we have working keyboard and mouse, and I can type stuff into Service Mode!
I'm tempted to just go ahead and try to hook up an ESProFile to see if I can get anything to boot. I know the floppy controller's not quite healthy, but at least the Selector should start up assuming everything else is working. Luckily, the ESP32 uses 3.3V logic levels to begin with, so need to worry about any level shifting there!
-
ESProFile is hooked up and somewhat working! I can get into the Selector just fine and BLU on most attempts (although it fails its self-check presumably because of the SCC or floppy controller), so that's a start. And thanks to the serial number reading feature in BLU, I can finally confirm that the time-sensitive SN logic seems to be working okay!
Unfortunately though, it seems that the Lisa doesn't really like ESProFile for some reason. Or maybe it's a timing thing inside the FPGA, but results seem better with a real Widget, so I tend to think it's an ESProFile thing. Which means that I can't really get any other environments to show any signs of life because of disk read errors before they can load more than a few blocks off the ProFile. MacWorks Plus gets as far as clearing the screen to grey before crashing, but that's the farthest we get, aside from LOS.
It honestly shocked me that LOS made it the furthest of them all, but it did! Not to the "welcome to LOS" screen or anything, but it clearly loaded for a few seconds before disk erroring, and gave a 10726 (boot device read failed) error when it finally did fail. The others just hung or gave an error 75 from the boot ROM after reading a block or two, so LOS got quite far by comparison.
So then I decided to try and plug in a real Widget with LOS 2.0 installed to see if I'd have any better luck with a real drive. And I sure did! This time, it loaded for a good 10-15 seconds before giving a 10727, which means that the loader exhausted all the system's memory and had to give up. This makes a lot of sense; my Lisa currently only has 256K of RAM installed in it, which very likely isn't enough for LOS!
I'm just realizing as I type this that I plugged the Widget into the FPGA without level shifters. Whoops. At least it didn't fry anything.
The only big peripheral left to hook up is the floppy drive, but obviously I need a working floppy controller before I can do that! And given that I designed this thing around the 2/5 I/O board so that people can hook Twiggies to it, I guess I need to do the Lite adapter too, although that should be super easy. So I think I'm going to go back and finally get the FDC fixed up now. I could see this being really perplexing and taking a while, so don't be shocked if the next update isn't for several days or a week.
I'm noticing that (aside from the garbled CPU board error 41 picture) I haven't really provided much proof that anything I've been saying is actually true up until this point, so I've attached some photo evidence of all this too!
-
Okay, the floppy controller interfacing problem is fixed now! I ended up adding some delay logic that keeps the 6504's clock paused for a little while after a 68K access to shared RAM ends, which gives some other logic enough time to raise and then lower the FDC RAM CS signal again to re-latch the RAM address that the 6504 was accessing before the cycle got interrupted by the 68K. It was a pretty convoluted fix, but no more Error 57 or hanging!
I also implemented the Lite Adapter, which was super easy. It just compares a constantly-incrementing counter to the value in a shift register (which represents the PWM duty cycle) and sets or clears the PWM output signal depending on whether the counter is greater than or less than the shift register value.
Now that the FDC seems to be working and fully-implemented, I've hooked up a Floppy Emu, and unfortunately we can't quite boot from floppy yet. But we're really close. It can clearly detect whether or not there's a disk inserted, and I've confirmed that seeking and ejecting the disk work perfectly by sending those commands to the FDC manually in Service Mode. The one thing that's not working is reading and (presumably) writing, which is obviously a pretty big problem! Whenever you try to read a sector (either manually in Service Mode or automatically by booting from the disk), the FDC just sits there trying to read the sector forever. This is making me think that something's wrong with the PROM state machine, which is supported by the fact that the only two things I've ever seen it put out onto the 6504's data bus are 0 and 1, which obviously doesn't seem right when reading sectors off a disk. So that's what I'm about to start troubleshooting next; hopefully it's not too hard of a fix!
-
After reading some more about the theory of the Apple ][ floppy state machine (which is basically identical to the Lisa's) and tracing through the states, I discovered that I had wired one of the pins on the ROM to the QH pin of the shift register instead of the QA pin, causing it to clear the shift register every time it shifted in a bit instead of only after a full byte was shifted in. And after fixing that, I can boot from floppy! Here's the status of booting various things from floppy, I'm assuming anything that's failing is because of my tiny 256K of RAM:
BLU - Works
Selector - Works
NewWidEx - Works
LisaMandelbrot - Works
MacWorks XL - White screen, floppy activity for a while and then hangs
MacWorks Plus - Gets about halfway through the Loading... screen and then hangs
MacWorks Plus II - Gives error about PFG since we don't have a PFG installed, if we choose to continue it loads about half the sectors from the floppy before hanging
UniPlus - Immediate error 75, I think my UniPlus floppy might just be corrupted
Xenix - Gets to the screen where it prints the Lisa system type, expansion slot contents, and free RAM, then kernel panics
GEM - Can boot to the command line, starting the GUI causes it to hang midway through loading
LisaTest - Error 49 (Line 1010 or 1111 trap)
LOS/Workshop - Error 10727 (Memory exhausted)
I don't have enough room in the FPGA to go to 512K of RAM, and I can't move the RAM to my board's external SPI flash because the write speed is too slow. My board has a DDR3 RAM chip on it too, but I really don't feel like interfacing with that, and I'm worried the latency would be too high anyway. So I think it might be time to design a custom board with an external parallel (or maybe SPI) SRAM before I continue. Unless anyone's got any better ideas (which I would love to hear), I think this will be my next step, and so it'll probably be a little while before another progress update. I guess I can go ahead and try to fix the intermittent ProFile read problems that I was having, but that's about all that I can do with the current version of the hardware.
-
Fantastic work!
LisaMandelbrot? I will have to look into that.
-
Amazing progress!
LisaMandelbrot is a set of Mandelbrot set plotters that I wrote a while ago. You can find it here: https://codeberg.org/stepleton/LisaMandelbrot
That page looks sparse because there are three varieties: "Port" which runs on the Office System, "Pro" which runs in the Workshop (no extra features, it's just that the workshop seems like the place for "pros"), and "Solo" which is a standalone program (i.e. boots and runs without an OS). Solo is quite small. Anyway, click through to any of the three to see more detailed information.
My standalone programs (including the Selector) don't really exercise all that much of the Lisa's capabilities; for a start, they all leave the MMU in the boot-up "flat" configuration. So it's not a big surprise that they run. For this reason I wouldn't think there's much point in running my stunt standalone Forth port (https://codeberg.org/stepleton/lisa-fig68k) for Lisa, as it is just as gentle on the machine (the Forth part can't even use RAM above 64k!).
Alex's SRAM idea touches on a project I was thinking of attempting but was in my project pile: the Smallest 2Meg RAM Card On Earth. I had a vision of an SRAM-based RAM card that would be comically small inside of the card cage, and I'd even had my eye on this single, somewhat pricy RAM chip (https://www.mouser.co.uk/ProductDetail/727-CY62167ELL-45ZXI), with its 16-bit data bus and (IIUC) +5V tolerance. But I hadn't started to sweat the details yet, and realistically it is a project that would have sat on a back burner for months at least. All of which is to say: Alex, if you wanted to stretch your SRAM plans slightly to make the Smallest 2Meg RAM Card On Earth, it would be pretty cool, and maybe that IC is worth knowing about :)
-
Ha, it's interesting you mention the 2MB RAM card thing; I was just thinking about doing something like that! All the RAM card logic I've written would easily fit into a small CPLD, so throwing the CPLD, some level shifters, and the SRAM onto a tiny little board would work nicely. And funnily enough, that SRAM chip is the exact one that I've been eyeing for the FPGA!
The COP core I'm using seems to also be small enough to fit into a CPLD, so a CPLD-based COP replacement could be another interesting idea...
-
(all out of curiosity)
Are the level shifters for the CPLD? That SRAM itself seems to accept and send TTL-compatible signals, though the outputs won't go up to a full +5V.
What kind of things does the CPLD do? I only scanned the Lisa Hardware Manual about this once, but I took away the impression that some of the work of the support logic was dealing with placing the RAM board in the appropriate part of the address space. (As the SRAM is a full 2 MB, the correct positioning is straightforward: it takes up all of it.) Furthermore, there's no need for DRAM refresh, so maybe that simplifies things too.
I suppose I'd hoped therefore that you might be able to reduce necessary logic down to a few surface-mount TTL ICs. You might put them on both sides of the board to achieve more compactness, though it would be better to avoid that so that you can use a hotplate for assembly.
But I assume there is plenty of remaining devil in various timing details for RAM reads/writes, etc.
Meanwhile, I was always wondering if you could replace the COP with a suitably busy Arduino (with enough pins)...
-
Amazing progress!
Indeed!
vision of an SRAM-based RAM card that would be comically small inside of the card cage, and I'd even had my eye on this single, somewhat pricy RAM chip (Infineon CY62167ELL-45ZXI), with its 16-bit data bus
...
But I hadn't started to sweat the details yet
I suspect parity could become a sweaty consideration, so I suggest sorting out how you will handle the parity issue before finalizing your part requirements.
The issue is that the parity test circuitry allows storing bad parity in multiple byte addresses for discovery at an indeterminate time.
IIRC, the POST sets bad parity at only one address, so rather than storing parity, it is possible to record that address and report the parity error when it is read again, but if some software (LisaTest maybe?) does a more complicated parity circuit test, it may discover your secret of circumventing stored parity bits.
Modifying the CPU ROM to remove the parity circuit check may be sufficient for most operation, but some purists prefer LisaTest success, and I don't know if anything else checks the parity circuits, so ymmv etc.
-
MacWorks Plus II - Gives error about PFG since we don't have a PFG installed
Since you don't have a fully functional SCC module, and possibly don't want to develop one (in particular with the SDLC (or whatever it is) complication that makes LocalTalk possible), you might consider using a real SCC, which then makes plugging in a real PFG an option. And/or we can figure out a strategy for implementing any desirable features of the PFG without the real hardware if the SCC can be adequately emulated.
But this is just one aspect of what the final result might be... now that you've very well established a proof of concept, it might be time to brainstorm the final objectives...
For example, is it, or some version of it, going to:
- completely replace real Lisa hardware including card cage, video, chassis, specific expansion cards, while not supporting arbitrary real expansion cards?
- replace the CPU and memory boards in a real Lisa card cage/chassis that uses real motherboard, video, I/O and expansion cards?
- replace CPU, memory, and I/O boards in motherboard form-factor so real expansion cards can be inserted in a real chassis?
Lots of options to consider that have their benefits and drawbacks... some of the challenges of being the project manager!
-
Yeah, I know it would be some pretty simple logic, but the purpose of the CPLD would be consolidating the small amount of TTL logic that would be required as well as figuring out parity. It could be done in TTL too, but I figured that a CPLD would probably be more compact and inexpensive. I was thinking about doing @sigma7's strategy of remembering the one address that the boot ROM does the "write wrong parity" test to, but it's true that we don't really know what else may use this feature. It would be easy enough to find out though; just boot each Lisa OS with the FPGA-based Lisa set to trigger on accesses to the appropriate address in the system control latch.
Unlike the SRAM card (if and when I get around to making that), I want to actually handle parity the proper way in the FPGA-based Lisa. So I was thinking about using the external SRAM for the main memory and then still keeping the parity inside the FPGA's block RAM.
Since you don't have a fully functional SCC module, and possibly don't want to develop one (in particular with the SDLC (or whatever it is) complication that makes LocalTalk possible), you might consider using a real SCC, which then makes plugging in a real PFG an option. And/or we can figure out a strategy for implementing any desirable features of the PFG without the real hardware if the SCC can be adequately emulated.
Yeah, that's a good idea that I hadn't really thought about before! I had previously planned on (and really, REALLY dreaded) implementing the SCC myself later on, but this might be a better (even if temporary) solution.
I've already implemented the PFG in an ESP32, and I've been imagining that implementing the same state machine inside an FPGA would be even easier, so my current plan is to (at least for my own personal use) make a Verilog version of the PFG. And same for the XLerator and LSAC too. Maybe we could work out a deal where @sigma7 could sell those as IP cores that people could add to their own FPGA Lisas without having access to the source code?
But this is just one aspect of what the final result might be... now that you've very well established a proof of concept, it might be time to brainstorm the final objectives...
I'm currently imagining two different versions of the final device:
1. A modernized standalone version of the Lisa. This will be a board that sits on your desk with HDMI video output, USB (or possibly PS/2) keyboard and mouse input, built-in ESProFile hard drive emulation, USB to serial feeding directly into the Lisa's serial ports, and perhaps built-in floppy emulation if I end up writing a floppy emulator. It would also let you plug in original keyboards, mice, hard/floppy drives, and would expose the original Lisa video signal for those who want it.
2. A version in the form factor of the Lisa motherboard. This would be a drop-in replacement that people could stick straight into their Lisas to replace a bad card cage, and it would include expansion slots too, on top of all the original ports that you'd expect.
Both versions would probably have switches that would let you flip between H and 3A as well as 40 and A8 ROMs on the fly.
Option #1 is the first priority that I'm just starting to mess around with now, with #2 coming later.
-
It's been a while, time for an update!
I'm getting pretty close to finishing the schematic for the PCB, and then I'll be onto the layout and routing phase. The whole schematic is done other than the connections of everything to the FPGA itself. Hopefully that shouldn't be too hard, I just need to look at the datasheet and make sure I connect certain Lisa signals to certain special-purpose I/O pins.
By the way, I've settled on the Xilinx Artix 7-100T as the FPGA of choice for the final board. It's pretty darn cheap at about $20, has plenty of LUTs, and between 200 and 400 I/O depending on which package you get it in. I'm currently using a little over 200 I/O, and this board doesn't even have expansion slots on it (which will add even more to that), so the 300-I/O version is going to probably be the chip of choice.
The key features of the board are:
- Power over either USB-C or barrel jack; 12V, -12V, and -5V (along with the 1V, 1.8V, and 3.3V FPGA voltages) are all generated onboard.
- USB port goes into an onboard hub chip, which feeds four devices: JTAG for FPGA programming and debugging, an onboard ESProFile, an onboard (yet-to-be-coded and I'm not even sure if I'll ever get it to work) floppy emulator, and a USB to serial chip that can directly feed the Lisa's Serial B port.
- As just mentioned, an onboard ESProFile and ESP32-based floppy emulator. There's a Floppy Emu-style OLED display and set of buttons for controlling floppy emulation, although once again none of that is implemented yet. And of course there are switches to choose whether you want to use the hard/floppy emulators or actual drives plugged into ports on the board.
- Switches to toggle between H and 3A CPU ROMs (and the corresponding VSROMs) and A8 and 40 I/O ROMs on the fly.
- The first version won't, but future versions will have Twiggy headers for the lucky few of you who happen to own a set of Twiggy drives!
- Onboard speaker (with the Lisa's 3-bit volume control) for Lisa audio, and external speaker header if you want to connect a larger one.
- Onboard contrast latch DAC in case you want to use the analog contrast signal for anything.
- HDMI video output. The VSYNC, HSYNC, and VID signals are also exposed on a header for easy connection of an RGBtoHDMI if you prefer that.
- USB keyboard and mouse input. As with the ProFile and floppy interfaces, these are switchable, so you can still plug in original Lisa keyboards and mice and use those too.
- Per James' suggestion, the Lisa's serial ports are implemented using a real 8530 SCC that you'll have to pop into a socket on the board once you receive it. But all the SCC's serial I/O pins are also bidirectionally level-shifted and run back to the FPGA so that a future version of the firmware can implement the SCC internally without requiring any changes to the PCB. The FPGA would just enable the level shifters, and that would take control from the external SCC.
- And as I mentioned earlier, Serial B is switchable between the actual DB25 port and a direct USB to serial interface with your computer, making it really easy to do things like transferring over all the LOS source code without needing a USB to 9-pin serial adapter and then a 9-pin to 25-pin serial cable.
There's no way that this thing will even come close to working on the first try, but hopefully I'll be able to figure out all the problems reasonably easily after getting a prototype run of boards in the mail.
As with some of my other recent designs, I've made sure that every part I'm sourcing is from JLCPCB/LCSC's parts library, so they'll be able to assemble the whole board for you when you order one. Which is pretty crucial given how much surface-mount stuff there is on here! The parts cost is currently looking to be a little over $100 per board, but I'm hoping to get it a little lower than that on the next board revision when some of the debugging hardware is removed.
It's still probably going to be a couple weeks before the layout and routing are done, but at least finishing up the schematic means that I'm about halfway there now!
-
That is astonishing. Congratulations, Alex! Looking forward to seeing it in the real world.
-
I am stunned fantastic work thank you!!