LisaList2

First off, congratulations to the LisaEm team on the 2.0.0 release! For anyone who hasn't seen it yet: https://github.com/arcanebyte/lisaem/releases/tag/2.0.0

This got me thinking about Alex's incredible work compiling LOS from source. I've been wanting to try it myself, but I don't have access to real Lisa hardware—so a LisaEm-only workflow is my only path forward at present. The challenge is getting the source files onto a Workshop disk image in the first place. Alex mentioned in the thread that he transferred everything one file at a time over serial on real hardware, which obviously isn't an option for me.

I'm curious: has anyone successfully imported the LOS source files onto Alex's starter image using LisaEm? I've attempted to set up an emulated serial port between the host and the emulated Lisa in the past, but I was never able to get communication working.

The 2.0.0 release notes mention improved Pseudo TTY serial port functionality and better documentation for both "Shell" and "Pseudo TTY" modes, which sounds promising. Has anyone had a chance to experiment with this yet?

Also, a related question: is Alex's glue.c patch still needed with LisaEm 2.0.0, or has that been addressed upstream?

Would love to hear if anyone has figured out an emulator-only workflow. Thanks!

Quote from: stepleton on Yesterday at 01:20:00 PMAnother 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 :-)

Quote from: sigma7 on Yesterday at 02:32:10 PMSince 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!

Quote from: AlexTheCat123 on January 30, 2026, 10:56:23 PMUnless 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]

Quote from: stepleton on Yesterday at 01:20:00 PMWhat 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.

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

Quote from: stepleton on Yesterday at 07:23:43 AMMaybe 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.

Quote from: coffeemuse on Yesterday at 09:34:34 AMI 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.

Quote from: coffeemuse on Yesterday at 09:34:34 AMI 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.

Quote from: AlexTheCat123 on January 30, 2026, 10:56:23 PM

Quote from: stepleton on January 30, 2026, 04:15:59 AM(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.

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.

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!

Quote from: stepleton on January 30, 2026, 04:15:59 AMCan 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...

Quote from: stepleton on January 30, 2026, 04:15:59 AM(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!

Quote from: stepleton on January 30, 2026, 04:15:59 AMIf 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...

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