LisaList2

1983 is definitely Lisa 1 vintage.
For a collection, personally, I would lean towards ensuring that all of my components were period correct.

Fully agree, this is why I offered my knowledge to help improve the system.
and the system responded.
My post and title was tip-of-the-hat to the high-minded critiques of brush strokes used in oil paintings prior to the 1860s and similar esoteric topics. 
EOC
-----------------------
Hello,

Thank you for reaching out with your recommendations regarding the Lisa-related records, it is much appreciated. The recommendations have been reviewed, and changes have been made to the following records:

Apple Lisa 2 - 102626732 - CHM
Apple Lisa Drive Cage - 102673912 - CHM
Widget Drive Assembly from an Apple Lisa 210 - 102673910 - CHM
Breakout of a Complete Apple Lisa210 - 102673911 - CHM
Apple Lisa Keyboard - X2410.2002B - CHM
Apple Macintosh Mouse - X2410.2002C - CHM

Thank you, again for your support of CHM!

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!

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!

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!

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.

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.

No, they work through the SCSI port provided by your XLerator or Sun SCSI card.

Are they serial port to SCSI?

Quote from: sigma7 on October 07, 2025, 06:27:47 pm

Note that the E/SCC does not affect the use of Ethernet, which is often a better method of networking under MW+II.

How would you connect lisa to Ethernet?

Other than a wireless connection through blue SCSI or serial local talk connection I haven't seen anything.

There are a few SCSI Ethernet adapters that work, namely:

• Asante Mini EN/SC (ethernet adapter)
• Farallon EtherMac (ethernet adapter)
• DaynaPORT SCSI/Link-T (ethernet adapter)