LisaList2

Quote from: AlexTheCat123 on March 15, 2026, 07:57:32 PMSure enough, it works great

Since that's the case, it's obvious you'll eventually need to make a third version of the board for use as a drop-in replacement for a Macintosh Plus motherboard!

Not sure how I forgot to try this earlier, but now that the SCC is working, we absolutely have to see if MacWorks Plus II runs!

Sure enough, it works great! The one issue is that it only recognizes the PFG at boot if you have the DOTCK set to 20MHz; any higher than that and it thinks it's not there. This could very well just be an issue with my setup though; I'm using an ESP32-based PFG replica that I designed and my code may not like the faster clock. I can't find my original PFG right now, but there's a good chance it would be fine.

Given that MW+II only enforces the PFG's presence during those initial checks and not once Mac OS is booting, you can simply boot at 20MHz and then switch up to the full 75MHz after you see the Happy Mac and things will work fine. Sure, settings won't get saved to the PFG's memory properly at the higher clock speed, but everything else will work great and MW+II won't lock up on you.

Anyway, back to troubleshooting the floppy controller! Synthesis is almost done, so we'll soon find out if my drive select fix was enough to get it working!

I chose Serial B since it seems to be the default port for a lot of things, including BLU, UniPlus, and all of my LOS compilation scripts. Maybe Xenix too; I'm not sure. And I figured that it would be nice to have the convenient USB hardware on the most frequently-used port. That was really the only factor I was taking into consideration!

And by the way, I've thoroughly tested the serial ports at this point (both USB on Serial B and a regular serial cable on Serial A) and they both seem to be rock-solid, including the flow control logic (which is very important if you're going to use my LOS transfer scripts)!

So now I'm moving back to the floppy disk controller issues. One problem I just discovered is that I had the drive select mapped wrong in my code for the new board. I had to reverse the drive select outputs in my code on the old board thanks to getting the drive select lines backwards on the PCB, but that has been fixed on the new one, and I forgot to switch them back around to normal again. Hopefully that's the only problem!

Excellent as usual to hear about this progress! It's interesting that Serial B is the one with the USB gubbins as this is the port you would use for LocalTalk if I'm not mistaken. Is there any relationship between those two things?

I need to do some more testing to be completely sure, but I think the serial ports are working now!

It turns out that the problem was a combination of PCB design issues and a bug in my CPU board logic.

I swear that something has to have been wrong with me when I was designing the Serial B section of the board; there were an insane number of mistakes that I found! First up, RX and TX were hooked up backwards. And not only that, but DTR and DSR were also hooked up backwards! There's also an LS157 mux on the board that's used to pick whether Serial B is controlled by the CP2102N USB to serial chip or the physical serial port, and I somehow managed to hook it up wrong too! I genuinely have no idea what could've been going through my mind, but I had signals that were supposed to be outputs from the mux connected to its inputs and vice versa.

With this absolute mess on my hands, I decided to just bodge the board into a hard-wired CP2102N configuration. It would've been a real pain to bodge the mux back into action, so I disabled the actual serial port and opted to just allow USB control over Serial B.

Sorting all of this out got me a bit further; the RSIR interrupt now wouldn't trigger until I tried to send or receive a character over serial. But the moment that it did trigger, the whole system would still lock up! After more investigation, I discovered the cause of the problem: the RSIR interrupt wasn't making it back to the CPU! It turns out that there was a bug in my priority encoder code on the CPU board that takes the Lisa's various interrupt sources and encodes them into the IPL[2:0] interrupt signal that the 68K uses. It was a typo that literally just affected the SCC interrupt and none of the others, which is why it went unnoticed until now. After fixing that, I could transmit and receive data over Serial B through the board's built-in USB to serial interface!

Then it was time to try Serial A. Serial A doesn't have an onboard USB interface like Serial B, so its logic on my PCB is simpler, and luckily I don't think I screwed any of it up because I plugged in a serial cable and it mostly worked on the first try!

I say mostly because I could receive data, but I couldn't transmit. Guess why? There's an LS245 on the PCB that allows the FPGA to directly drive all of the SCC's output pins, which I put there in the hopes that I can eventually integrate the SCC into the FPGA and thus not even need the real SCC at all. But obviously this LS245's outputs should be disabled when a real SCC is installed because otherwise there would be contention between the real SCC and the nonexistent FPGA SCC. Well, I was accidentally setting this output enable pin low in my code, and the 245's OE pin is active-low, so it was enabled and constantly competing with the real SCC to drive the bus! After turning this off and resynthesizing, Serial A worked great! This LS245 was also double-driving all of the Serial B outputs, so I guess the SCC was just strong enough to overpower it in all of the earlier tests, but not for Serial A for some reason.

It's honestly a miracle that the mux, MAX232s, CP2102N, and ESPECIALLY the SCC survived this torture; all of them had at least two (or eight in the case of the SCC) outputs that were being double-driven! Maybe this is why the SCC has been getting so hot that it burns me...

For sale is an HP 1650A Logic Analyzer. Includes many test leads and cables as well as the software disk(s).

Reference Manual: https://www.qsl.net/n9zia/test/HP1650A_Reference_Manual.pdf
Service manual: https://www.qsl.net/n9zia/test/HP1650A_Service_Manual.pdf

Asking $150 OBO plus shipping from U.S. 78070.

For sale is a gently-used Saleae Logic 8 8-channel logic analyzer. Saleae Logic 2 software is available for Windows, Linux, and macOS as a free download at https://www.saleae.com/downloads.

Datasheet: https://downloads.saleae.com/specs/logic_8_data_sheet.pdf

Asking $350 OBO shipped within the U.S. Please PM if interested.

Okay, so I just really want to get the SCC working (I've been dying to test out my built in USB-to-Serial B solution), and I've decided I'm going to do that first before getting the floppy controller working again.

So far the progress has been pretty good; I've confirmed that the Lisa can talk to the SCC perfectly fine. I also discovered that the reason why the SCC fails the boot ROM tests is simply because I'm overclocking the Lisa to 4x speed. The ROM tries to do a port loopback test on the SCC, and the 68K sits in a timeout loop waiting for the data that it sent to the SCC to be "received" back again. But given that it's running at 4x speed, the 68K times out 4x faster than it's supposed to, which doesn't give the SCC enough time to return the data! There's nothing we can really do on the SCC side of things to fix this, so I think I'll just have to patch the boot ROM to skip the loopback test. I've already done this on the H ROM anyway, so it's just a matter of doing it on the 3A ROM too.

But we still have the problem where trying to configure a serial port in LOS causes the entire system to hang. This is true both in LisaTerminal and in the Workshop's PortConfig utility. I can't say for sure yet, but current signs are pointing to the RSIR signal (the SCC's interrupt line) becoming permanently asserted the moment that LOS configures the SCC and enables its interrupt capability, causing LOS to constantly service SCC interrupts until the end of time. I'm guessing that I screwed up something in my PCB design such that one of the RS-232 signals going into the SCC is stuck in a bad state, and that's what's causing RSIR to be permanently asserted, but I'll need to do some more digging to find out for sure.

And by the way, my little scanline experiment worked great! The effect does hurt my eyes a bit, but maybe that's just because of how close I'm sitting to such a big monitor. It sure looks cool though, and I'll probably keep it on the final board, especially if I'm able to make it a little easier on the eyes. Clearly it's possible; the RGBtoHDMI pulls it off very nicely!

Quote from: ried on March 12, 2026, 10:48:16 PMCongratulations, Alex! Looking great! It's crazy how fast LOS boots up on that 

Having that extra speed is really awesome. It feels so terrible every time I switch back to a standard "slow" Lisa now!

Congratulations, Alex! Looking great! It's crazy how fast LOS boots up on that