A Lisa Inside An FPGA

[ried]

42, of course. The answer to the Ultimate Question of Life, the Universe and Everything.

[stepleton]

Can the switch control something else? Square pixels vs. tall pixels would be very handy, though I'm guessing you're already accommodating that in one way or another.  Otherwise I can't really think of anything. Choose a frequency that makes it easiest to bit-bang an address line so that you can play a tune on an AM radio?

(For v3 move from switches to a rotary encoder that goes from 5 MHz for the 68k to the upper limit...)

If there's any chance, I'd love to see a cheap-and-cheerful video of LisaMandelbrot Solo running on the 80 MHz dot clock Lisa...

[AlexTheCat123]

Can the switch control something else? Square pixels vs. tall pixels would be very handy, though I'm guessing you're already accommodating that in one way or another.  Otherwise I can't really think of anything. Choose a frequency that makes it easiest to bit-bang an address line so that you can play a tune on an AM radio?

Yep, I already have an H/3A switch for that! Playing music sounds like a good idea though...

(For v3 move from switches to a rotary encoder that goes from 5 MHz for the 68k to the upper limit...)

I wish I could, but unfortunately that's not as easy to implement as it sounds. You can't easily sweep the output frequency of an MMCM across a range, and I guess I could use a variable clock enable on a single high-speed clock to accomplish the same thing, but that would require rewriting significant portions of the code. And it would probably break a lot of stuff, so I'm not sure it would be worth it!

If there's any chance, I'd love to see a cheap-and-cheerful video of LisaMandelbrot Solo running on the 80 MHz dot clock Lisa...

Here you go!
https://www.youtube.com/watch?v=o00bQq0lx0A

I haven't given up on getting 80MHz working just yet. I've tracked down the COP issue; it's no longer a sync problem with sending the command. That part works fine now. The new issue is that the COP takes "so long" to return the data that the 68K times out before it's ready. At the lower (but still overclocked) clock speeds, the timeout loops were tolerant enough that the CPU was still willing to wait long enough to retrieve the data, but not anymore. Remember, we're running at 4x the stock clock speed now, so the timeout periods are essentially 4x shorter than they should be.

There may not be anything I can do about this. Obviously I can't patch the ROM (and every other piece of Lisa software) to extend the timeout because that's just a really dumb solution, and I also can't overclock the COP because that would mess up the RTC and break the timing of the keyboard interface.

Unless anyone else has any suggestions, my only remaining idea is to try and shorten my "extended" pulse on DDRA that feeds the COP its command. Obviously it needs to be extended some because otherwise the COP will never receive its command at the higher clock speeds, but perhaps (and this is just a total guess) the COP doesn't start processing the command until DDRA goes back to an input again and takes the command off the bus. And given that I'm probably extending the pulse for longer than I need to, maybe I'm wasting some time during which the COP could be processing the command. So what if I just shortened the pulse a bit, in the hopes that the COP starts processing the command quicker and returns the data faster, hopefully within the timeout period? That's what I'm about to try, and hopefully it works! If not, then I think we might be stuck with 60MHz, or maybe I can try 70 and see if I have any better luck there...

[AlexTheCat123]

Yeah, shortening the DDRA pulse made no change whatsoever, so I don't think there's any way to fix this. I'm going to try stepping the clock down in increments of 5MHz until I can find the highest point at which the COP works, and we'll call that the max speed. Hopefully it's above 60MHz!

By the way, it takes about an hour and 15 minutes to resynthesize the design at this point, so if anyone's wondering why progress is slower now than it used to be, that's your answer. Just changing a single line of code necessitates a full resynthesis, so every little change takes that long to test. And if the new design struggles to reach timing closure, it can take even longer than that!

[stepleton]

Wow, thanks for recording that video. 80 MHz is quick! It's also cool to see that you can change the clock while the machine runs.

Maybe it really is a little too soon to give up on 80 MHz. If it's the CPU timing out, are there ways to suspend it or slow it down around critical access to the COP (and maybe other components too)? It looks like you would want to specifically detect clock queries as the mouse seems fine in your video. Maybe there's a pin you can keep (de-)asserted that holds the 68000 in place, or if nothing else you could have the hardware send `foo: BRA.S foo` instructions to the CPU on instruction fetch (you'll need to hold off delivering interrupts too in that case, I suppose).

Or just leave things as they are and say: well, it's not for the software we have now, but maybe people designing new software can write code to take advantage of it! Put a skull and crossbones on the silkscreen around the 80 Mhz setting so that people don't make service enquiries to you when throwing it crashes the machine ("what did you expect?"). Then one day much later someone who does have the urge to hack the software can say "I unlocked pirate mode!!"

In re "dial-a-clock", my inspiration: if you ever find yourself in Cambridge, England, there is a computer museum there that has a computer made from discrete surface-mount transistors and so on. I believe the whole computer (and not just the processor) is made this way; in any case, it is huge, filling up multiple panels the size of tall cubicle walls and stretching out along much of the length of the room. They usually have it set up so you can play Tetris on it. But my favourite part of it is a gigantic forearm-sized rheostat that looks like it came out of a locomotive --- I'm sure it's handling only a couple milliamps its current role, which is letting you select the processor clock speed at any point from 0 to a few tens or hundreds of KHz if memory serves.

[coffeemuse]

(For v3 move from switches to a rotary encoder that goes from 5 MHz for the 68k to the upper limit...)

I wish I could, but unfortunately that's not as easy to implement as it sounds. You can't easily sweep the output frequency of an MMCM across a range, and I guess I could use a variable clock enable on a single high-speed clock to accomplish the same thing, but that would require rewriting significant portions of the code. And it would probably break a lot of stuff, so I'm not sure it would be worth it!

I may be missing something here, so please take this as a naïve observation rather than a proposal.

I completely agree that a potentiometer or swept clock runs into real MMCM and architectural issues. What occurred to me while reading the thread was that some of the "knob" UX might be achievable with a much simpler mechanism: a 2-pole, 4-position detented rotary switch, rather than a pot or encoder.

Electrically it would just be selecting among the existing discrete speed presets (the same thing the two speed-select switches already do today), so there's no clock sweeping or refactoring involved. Mechanically it feels like a single "speed knob," which is very period-appropriate, but logically it's still just fixed presets.

If the speed-select signals were ever exposed on a small header, this could even be entirely optional and external (case-mounted), leaving the current on-board switches and hot-switching behavior untouched. I mention it only because v3 is being finalized now and it seemed like a very low-impact way to split the difference between UX and complexity.

Happy to be corrected if I'm overlooking something.

[AlexTheCat123]

Maybe it really is a little too soon to give up on 80 MHz. If it's the CPU timing out, are there ways to suspend it or slow it down around critical access to the COP (and maybe other components too)? It looks like you would want to specifically detect clock queries as the mouse seems fine in your video. Maybe there's a pin you can keep (de-)asserted that holds the 68000 in place, or if nothing else you could have the hardware send `foo: BRA.S foo` instructions to the CPU on instruction fetch (you'll need to hold off delivering interrupts too in that case, I suppose).

I didn't really want to do anything like that for the sake of remaining completely cycle-accurate to the original Lisa. Sure, the extension of DDRA isn't accurate, but that's completely invisible to the programmer and to all the hardware except the COP, so it doesn't really matter. But stalling the 68K until the COP data is getting closer to being ready definitely hurts that accuracy. Which doesn't quite sit right with me.

But of course, this project is for everybody, not just me, so if it's what other people want then I'll absolutely give it a shot! I'm not super familiar with how the synchronous 6800-style bus cycles work and whether you're allowed to delay VPA like you can with DTACK without the 68K immediately bus erroring, but maybe I could make it so that, after the CPU sends a command to the COP through the VIA, it doesn't actually see VPA get asserted until the data is ready. That way, whenever it's time to read the data, it's guaranteed to be there!

Some pretty good news: I just tested it at 75MHz and it seems to work just fine, with no COP weirdness or RAM mods needed, so at least we have that to fall back on if 80 doesn't work.

I completely agree that a potentiometer or swept clock runs into real MMCM and architectural issues. What occurred to me while reading the thread was that some of the "knob" UX might be achievable with a much simpler mechanism: a 2-pole, 4-position detented rotary switch, rather than a pot or encoder.

Ahhh, I see! That's a really excellent idea. I'll look and see what LCSC has in stock and stick one on the board. That would be a much better interface than two switches.

I mention it only because v3 is being finalized now

Just to be clear to everybody, v2 is the one that's being finalized right now, and v3 is probably going to be the first release version. There might still be some really minor issues with v2 that need to be cleared up, and labeling that needs to be changed as the design changes, so I don't want to commit to anything with it.

[stepleton]

> But of course, this project is for everybody, not just me, so if it's what other people want then I'll absolutely give it a shot!

That's generous! I'm for it, but sparingly. I think this kind of trick is not uncommon with accelerators (though others on this board can say much more authoritatively). My recollection is that the "fast" Apple IIs inside of the IIGS and maybe also the IIc+ and the Apple II expansion card for Macs might do it this way too. So it's straying a bit from the Lisa tradition but still applying a time-honoured technique.

Here's one way to look at it: it might be handy to have a facility that can delay or suspend the CPU temporarily for a few reasons. There's debugging, and also if there's ever a plan to make a version of this apparatus that has an expansion port or that's used to help make expansion cards, then it could be that existing cards and new cards under development may simply be unable to cope with such a high clock rate. Working out a way to selectively slow the Lisa when it carries out certain accesses could be helpful, especially if you've got a kind of bug where it's helpful for the rest of the system to be fast.

Made-up example: you're working on a networked disk driver for the Office System for a Lisa Fujinet expansion board. The hardware can only go a certain speed, so the slowdown feature is handy. But since it's an OS driver, crashes are frequent, and you're often having to reboot the entire machine and start over. Thankfully it doesn't take all that long to get you back to where you were!

Another thing that might be handy for hardware hacking --- and perhaps an alternative to an 80 MHz switch. What about a 0 MHz switch? Some parts of the Lisa might not like it, but if not, if you could freeze it in its tracks, it could be handy. Maybe even have a pin on the board that's ordinarily pulled down to 0V, but make it logic-high and the Lisa stops right where it is... with another pin right next to it for stepping. If triggerable by a logic analyser then that could be very helpful indeed. OK, this is getting a bit elaborate, but it's fun to think about :-)

So even if not part of the "main" Lisa FPGA programming, it could still be handy to know how to do this well.

[sigma7]

Unless anyone else has any suggestions

Since you've covered the maximum compatibility option, I suggest aiming for a maximum performance option. eg. a setting for maximum workable clock rate, overclock the COPS by say 2x or 4x so it generally 'works' with the caveats that the RTC is wrong and Lisa keyboard/mouse artifacts will occur until someone tweaks the COPS code to account for the faster COPS clock. I suppose that means having a duplicate COPS ROM that is switched in with the expectation that there will someday be two versions. [shrug]

What about a 0 MHz switch? Some parts of the Lisa might not like it, but if not, if you could freeze it in its tracks, it could be handy.

That would be a great way to troubleshoot real Lisa CPU boards. Regrettably, the original NMOS 68000 has a minimum clock speed, so one would need to swap in the CMOS version eg. MC68C000 which will operate down to 0 MHz.

[AlexTheCat123]

Another thing that might be handy for hardware hacking --- and perhaps an alternative to an 80 MHz switch. What about a 0 MHz switch? Some parts of the Lisa might not like it, but if not, if you could freeze it in its tracks, it could be handy. Maybe even have a pin on the board that's ordinarily pulled down to 0V, but make it logic-high and the Lisa stops right where it is... with another pin right next to it for stepping. If triggerable by a logic analyser then that could be very helpful indeed. OK, this is getting a bit elaborate, but it's fun to think about :-)

Since you've covered the maximum compatibility option, I suggest aiming for a maximum performance option. eg. a setting for maximum workable clock rate, overclock the COPS by say 2x or 4x so it generally 'works' with the caveats that the RTC is wrong and Lisa keyboard/mouse artifacts will occur until someone tweaks the COPS code to account for the faster COPS clock. I suppose that means having a duplicate COPS ROM that is switched in with the expectation that there will someday be two versions. [shrug]

Wow, these two answers couldn't be any more different! We've got "so fast that it breaks things" and "literally no clock at all", and between the two, I'm probably going to lean towards the 0MHz clock. Pushing the clock even higher at the expense of the COP worries me a bit because I'm not even sure how to test certain things without a keyboard, and I bet a lot of other things will begin to break as I go past 80MHz. Plus, there's no guarantee that anyone will ever fix the COP, so there's a good chance that most people would never end up using this mode. Whereas 0MHz is pretty darn easy to do and could have a wide set of use cases; just wire a switch to the OE pin on the clock mux, which is currently tied low (always enabled).

Given that 75MHz seems to work okay, I'll probably try and find a 5-position rotary switch, with 0, 20, 40, 60, and 75MHz positions. And then I could add a single step pin too; just run an edge detector off the master 125MHz sysclk, look for rising edges on that pin, and let a single cycle of the DOTCK through the clock mux whenever an edge is detected.

I'm compiling LOS at 75MHz right now to see how long it takes, and so far it's made it through all the apps (including the Desktop Manager) in a little over an hour. A significant improvement from the stock Lisa!

[AlexTheCat123]

Alright, I think I'm ready to order the v2 boards! I made quite a few changes, and I've attached renderings of the new design. If you're not super familiar with the v1 board (and even if you are), it might be kind of tough to spot the changes visually, but trust me, there are quite a few of them! If you're curious exactly what they all are, go check one of my posts from a couple weeks back where I lay them all out.

The price for the minimum quantity of two fully-assembled boards is about $575, so not horrible, but then shipping (about $100) and tariffs (about $275) come in and raise the price to over $900, so it ends up being a lot. If anyone's still willing to donate anything to cover part of the cost, I would be very grateful! You can find me on PayPal at paypal.me/alexthecat123 if you're interested in contributing anything. Don't feel obligated to though; I wouldn't even be asking if people hadn't already expressed interest in giving some money in the past!

And following up from the previous post: the entirety of LOS (including LisaGuide and running PACKSEG to pack all the files for the installer disks) compiled in 3 hours and 10 minutes, which felt lightning fast to someone who's used to the stock Lisa's compile speeds.

Also, remember how I said that the Lisa would work with the Floppy Emu, but not real floppy drives? Well, I figured out why! My real floppy drive (which I thought was functional) was shorting 12V to the RDA (read data) line, and obviously the Lisa had no idea what to do with this. It's a miracle it didn't fry the electronics on the floppy drive, and even more impressively that it didn't kill the FPGA. 12V is muuuuch higher than the 3.3V limit that the FPGA's datasheet specifies!!! After fixing the floppy drive, real floppies now work perfectly fine!

The main things left to do at this point are:
- Get the serial ports working. I think the SCC is completely dead on the current PCB; some of the changes on the v2 board are really going to help with this!
- Improve floppy drive reliability and get external ProFiles working. Both of these problems can be mostly or entirely blamed on the v1 board's terrible level shifters.
- Upgrade the HDMI subsystem from 1080p30 to 1080p60. This may not be possible; the pixel clocks required for 1080p60 are higher than the maximum supported clock speeds of the OSERDES primitives inside the Artix 7 FPGA, so there's physically a hardware limitation preventing it from working quite right. Whenever I try it, the design obviously fails timing, but sometimes I'm actually able to get a stable image on the screen. It's really flaky though and will randomly start tearing the picture and glitching out the sound with weird clicks and pops, so we're truly pushing it up against its limits. I'll mess with it a bit more, but we might be stuck with 30FPS video. Hopefully people don't mind too much; it really bugs me, but it's likely the best we can reliably do!
- Fix a few reliability issues at higher clocks. MacWorks Plus sometimes randomly shuts down at higher clock speeds (60MHz and above), so we might still have intermittent COP problems of some kind that only show up there.
- Get Xenix working. Xenix will sometimes boot, but it's super picky about ProFile timings and fails ProFile handshakes so often that it frequently hangs. I've gotten to the login prompt once or twice though. And don't even think about running it higher than 20MHz; then the ProFile code completely breaks! My upgrade of the SD card slots from SPI to SDIO on the v2 boards will likely help with this too.
- Get UniPlus working. It always seems to initially boot just fine, but kernel panics right after it shows the "welcome" screen that displays your system's configuration. I'm hoping that this is because of the broken SCC, so I'm not going to worry too much until we get the SCC issues fixed and can try again.
- Get GEM working. I haven't tried booting it from hard disk, but at least when you boot it from floppy, it reads a bunch of tracks and then hangs. It never displays the fish icon or anything, so I guess it's failing pretty early.
- Figure out a better solution to the parity issue. I'm torn between implementing the full parity RAM using the FPGA's internal block RAM versus hard-coding the RAM board to only report bad parity when it detects the boot ROM (or LisaTest) performing the "write wrong parity" test. We'll see.
- Get my ESP32-based floppy emulator working! But this is something I can worry about after I've released the LisaFPGA boards; even if I fail; the boards are still perfectly useful as-is.

I think that's it; let me know if there's anything I've promised or mentioned in the past that I'm forgetting. And if you're willing to donate to the PCB order, then thanks again; I really appreciate it!

[AlexTheCat123]

Wow, I've gotten over $700 in donations since making my post last night. That's way more than I could've ever imagined; thank you so much to everyone who pitched in!

I just placed the order a couple hours ago, but I have some slightly unfortunate news about the timeline of things. Unbeknownst to me until I was about to place the order, JLC just closed down their 6-layer production line for the Chinese Spring Festival, and they won't even start fabricating my board until the 24th. So it probably won't be here until March 10th or so. If only I had placed my order two days earlier; if I had, then they would've put it into production now instead of waiting. But I just didn't know at the time. This is also a really big problem because I ordered a 6-layer board that I need for one of my classes at the same time, and I'm not going to be able to get my assignment done before the deadline if they wait that long!

Having to wait on the LisaFPGA boards is just an inconvenience, but the board I need for school is actually really important, so I paid extra for expedited manufaturing on both boards to get my school one here fast because their site said that it would go into production before the 24th if I did that. But then on my order history page, it ended up saying that it wouldn't go into production until the 24th again!

I reached out to their customer service (who are really good by the way) and it turns out that this was a bug in the site; you weren't supposed to be able to pay extra to get an order in before the holiday if you placed your order after the 2nd. Given that it was a bug on their end, they're going to try their best to honor what the site said and squeeze me in before the factory closes, but if not then they'll just refund me the expedited fee. So we might end up getting the LisaFPGA boards earlier than March, but it's all just going to depend on whether they're able to get me into production quickly.

If only it was a 2-layer or 4-layer board; those production lines are only closed from the 16th to the 19th and if I placed the order now, it would probably be done well before then anyway! But I don't even want to imagine having to design something around a super-dense FPGA with only 4 layers to work with...

[coffeemuse]

Having to wait on the LisaFPGA boards is just an inconvenience, but the board I need for school is actually really important, so I paid extra for expedited manufaturing on both boards to get my school one here fast because their site said that it would go into production before the 24th if I did that. But then on my order history page, it ended up saying that it wouldn't go into production until the 24th again!

I reached out to their customer service (who are really good by the way) and it turns out that this was a bug in the site; you weren't supposed to be able to pay extra to get an order in before the holiday if you placed your order after the 2nd. Given that it was a bug on their end, they're going to try their best to honor what the site said and squeeze me in before the factory closes, but if not then they'll just refund me the expedited fee. So we might end up getting the LisaFPGA boards earlier than March, but it's all just going to depend on whether they're able to get me into production quickly.

Fingers crossed that JLC's customer service comes through and gets you squeezed in before the holiday shutdown. That's a rough spot to be in with your school project deadline on the line. Hopefully the fact that it was a bug on their end works in your favor.

At least waiting on the LisaFPGA boards is just a patience test. Here's hoping good luck is on your side and the boards make it out before the factory closes.