Print

[patrick]

The 6504 is a 6502 with some pins not connected. Both parts use the same silicon die. So you can use the 6502 core and ignore the upper address lines.

[AlexTheCat123]

The 6504 is a 6502 with some pins not connected. Both parts use the same silicon die. So you can use the 6502 core and ignore the upper address lines.

Yep, that's exactly what I'm doing!

[AlexTheCat123]

Time for another progress update!

I'm in the process of testing and working out the kinks on the I/O board, and it's getting pretty far in its series of tests.

The boot ROM actually does a decent bit of testing on the I/O board before it even puts up the "Testing..." screen, with only a relatively small amount of testing happening during the "I/O board test" that you actually see occurring after the RAM test completes. Once it gets through that initial I/O board test, it actually goes back and does some additional CPU board tests (this is what's happening when the CPU icon is highlighted on the Testing... screen) and this exposed a few more minor problems with the CPU board. Namely that the "write wrong parity" and vertical sync interrupt circuits weren't working right, but those have now been fixed and I think it's safe to say that the CPU board is fully-functional.

It also completes the long RAM test just fine (the one that you see on the Testing... screen), so that's some additional confirmation that memory addressing and parity checking is working fine!

As for the I/O board itself, both VIAs seem to be working flawlessly, and the COP seems to be executing code and putting out its ready signal like it's supposed to. The boot ROM isn't making it to the in-depth COP test yet (that's the very last test that it does on the I/O board), but the preliminary test at least looks good.

Communications with the SCC seem to work fine too, although the SCC core I found from the NanoMac project is insanely limited, to the point that it doesn't even support the internal loopback mode that the Lisa uses during the self-test. For now, I've just patched the loopback test out of the boot ROM, and I'll come back and improve the SCC core later. Reading and writing all the SCC registers seems to work great though!

The only two tests left in the I/O board phase of testing are the floppy controller and extended COP tests, and it's stuck on the floppy controller right now. Up until yesterday, the floppy controller was actually completely dead, but I've got it in a much better state now. It's now happy enough that it puts its ROM revision in the shared RAM for the 68000 to read,  and the 68K reads the A8 just fine. And it seems to be able to address and control all the floppy drive control signals as well. I'm not 100% sure if the LS323/P6A PROM/LS174 state machine is working the way it's supposed to, but it at least seems to be running and doing something.

The current issue with the floppy controller is that it's failing its initial self-test, which the boot ROM notices when it reads the test results from the shared RAM, causing it to abort testing at that point. Luckily, I know why it's failing: for some reason, the floppy controller thinks a drive is connected, even though there isn't one, and so it tries to seek the heads back to track 0. But even after sending the seek command 80 times, the track 0 indicator bit still doesn't turn on (because there's no drive connected to turn it on), so the floppy controller thinks that either the drive or controller is defective and sets an error bit in the self-test result byte. So I just need to figure out why it thinks there's a drive connected when there's actually not.

After that, it's just the COP test, and then the I/O board should be done (aside from the SCC fix of course). The only thing left in the boot ROM's self-test after that is the scanning of the expansion slots for cards, but I don't have any cards "inserted", so it shouldn't detect anything and will hopefully just breeze through that test just fine.

At that point, we should be at the boot menu, where my next step will be getting a keyboard and mouse hooked up and interfacing with the COP so I can actually control things. I think I might try to hook up a USB keyboard and mouse, or PS/2 at the very least. And after that, I think connecting a ProFile would be a good idea. Not sure if this is even a thing, but if an ESP32 Verilog/VHDL core exists, I might even be able to integrate the functionality of ESProFile straight into the FPGA; no external drive or emulator needed!

[AlexTheCat123]

Okay, I'm very nearly to the point where I can get to the boot menu consistently!

In fact, the FDC and extended COP tests work great in simulation and I'm able to get to the menu there every time just fine, but I'm still having a minor problem on the actual hardware, although it's proving to be pretty annoying.

When running on the actual FPGA, sometimes the FDC RAM gets corrupted and causes the Lisa to fail the self-test with an Error 57, and other times it passes just fine and makes it to the "no keyboard connected" and then Startup From... menu. It looks like the problem has to do with setup time issues with the addresses going to the floppy controller RAM, which of course only show up in actual hardware where you've got propagation delays to worry about. I've tried some strategies to fix the address issue (like delaying the RAM CS signal so that it wouldn't arrive until a 16MHz clock cycle later after things are stable), which helped, but then that has introduced weird edge cases where things completely break if the 68K tries to access the floppy controller RAM at the wrong time and interrupts the delayed CS pulse from the 6504. So I'm now trying out another solution, which will hopefully do the job a bit better. I'm super close though!

[bmwcyclist]

It must be an inspiring site to see it go through the pre-boot hardware check and then come up with the "no keyboard connected"!

[stepleton]

I don't have much to offer to help along this journey, but every time I see that there's another update to this thread I get pretty excited. Go Alex go!

[AlexTheCat123]

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.

[bmwcyclist]

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.

[AlexTheCat123]

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!

[AlexTheCat123]

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!