LisaList2

Count me in for a board as well.

Thank you! I haven't really considered it up until today. But then one vendor reached out to me a couple hours ago wanting to list some boards on their site. I'm in the middle of final exams right now, but I'm thinking about it and I'll get back to them once I'm done!

I'm blown away by your work on this, Alex.  In terms of unit sales, have you considered working with an existing vendor?  Might help to reduce headaches and hassles.

Thank you James!

QuoteI uploaded a public YouTube video about this project

Very nice! Congratulations on your continued progress on this ambitious project. You've certainly demonstrated a lot of determination and dedication, not to mention development of some serious troubleshooting finesse.

Wow, I uploaded a public YouTube video about this project to my channel last night, and it's gotten about 8,000 views overnight! Most of the reception has been positive (other than a couple guys complaining about the board being ugly and saying that I need to talk to a pro PCB designer and also a few people complaining about my horrible camerawork) and a lot of people have said that they want to buy one. I'm honestly shocked at how much attention it's getting!

https://youtu.be/8jNQDcpHc68

Quote from: stepleton on May 02, 2026, 04:21:24 AMConsider explaining the situation and asking on 68kmla/TinkerDifferent/VCFed? A link to this thread would help folks who want to know more or who want to confirm that the project is real.

Good idea, I think I'll do that! And maybe I'll make a YT video going over its capabilities so that people know what they're getting into.

Quote from: coffeemuse on May 02, 2026, 08:01:56 AMAlready preparing on my end: Workshop 3.0 manuals, original M0100 mouse, and a tube of Zilog SCCs in case the external SCC route is the way to go.

Haha, you're all ready to go! I hope to see you at the presentation, and hopefully the boards will be here in time (assuming there's enough demand)!

Quote from: sigma7 on May 02, 2026, 01:08:10 PMIn what version/range of MW+ did you find this bug?

Whoops, I completely forgot to mention that in my last post. I found it in 1.0.18, but it's probably in other versions as well. Notably, it's NOT in MacWorks XL or MW+II. Search for 007C 0300 207C 00FC DD81 243C 0000 0108 and replace the timeout value of 0000 0108 with something big; I just arbitrarily chose 7000 0000 for some reason.

Quote from: sigma7 on May 02, 2026, 01:08:10 PMThis brings up the issue that some code might want (or need) to know that it is running on your FPGA design and at what speed (and any other options). If you can add some kind of info register in the CPU board address space to expose that sort of thing it would be more reliable than the code trying to decide for itself.

Wow, that's a good idea! I think I might just extend the system status latch (the thing that holds the states of INVID, CSYNC, VID, BUST, BTIR, HDER, and SFER) to be 16 bits instead of 8 bits, and put some magic number in there (along with maybe the current DOTCK speed and some other stuff) that identifies the board as an FPGA and not a real Lisa. That's a really easy change to make.

Quote from: sigma7 on May 02, 2026, 02:09:13 PMBy the sound of your report, your FPGA design has some kind of logic analyzer or code trace feature... if there is a way to make that available to others, it could be a tremendous benefit to anyone working on Lisa code!

Yeah, it's incredibly useful, and it's built right in to the Xilinx toolchain. You just mark signals for debugging to keep them from getting optimized away and rebuild your design. Then you can add a logic analyzer core within the FPGA that uses the FPGA's internal block RAM as its sample memory and sends data back to Vivado over JTAG. Once you program the board, you configure your trigger settings and can start capturing data in Vivado! The only catch is that there's not a whole lot of sample memory to play with since it's just running off the FPGA's block RAM, but it hasn't really been much of a problem for me except for when I'm trying to probe really slow stuff like the ProFile interface and the COP's sync signal.

Quote from: AlexTheCat123 on May 01, 2026, 08:11:15 PMI figured out the MacWorks Plus issue

By the sound of your report, your FPGA design has some kind of logic analyzer or code trace feature... if there is a way to make that available to others, it could be a tremendous benefit to anyone working on Lisa code!

Quote from: coffeemuse on May 02, 2026, 09:09:42 AMTorZidan, thanks for the suggestion. It compiles with LisaEm once the source code is available, but I must admit that it had some glitches. About 10% of the time, it would hang or crash during compilation, and occasionally even corrupt the image. In such cases, I would restore the image from a backup and try again. I was running the emulator at the fastest rate, which may have contributed to some of the crashes. I noticed less problems at slower CPU emulation speeds. However, I can (somewhat) reliably compile LOS now.

That was about what my experience was like back when I was doing the parts of the compilation project that required me to use LisaEm instead of a real Lisa. Luckily I only needed to build small parts of it on LisaEm instead of the whole source release, so it wasn't as bad, but I can imagine that getting through the whole thing could be tough!

Quote from: AlexTheCat123 on May 01, 2026, 08:11:15 PMI figured out the MacWorks Plus issue ... it does require a small patch to your MacWorks Plus disk.
...
They set the flag in the CCR in the event of a timeout, but then on LITERALLY THE NEXT INSTRUCTION they pop the old contents of the CCR off the stack and overwrite the CCR with it before returning to the caller.

In what version/range of MW+ did you find this bug?

Quoteanother BLU problem: it fails its self-check when running with a 60MHz or 75MHz DOTCK. It passes the self-check fine when booting from floppy at these speeds, but not from the ProFile

This brings up the issue that some code might want (or need) to know that it is running on your FPGA design and at what speed (and any other options). If you can add some kind of info register in the CPU board address space to expose that sort of thing it would be more reliable than the code trying to decide for itself.