LisaList2

Advanced search  

News:

Want an XLerator? Please participate in the market research thread: https://lisalist2.com/index.php/topic,594.msg4180.html

Pages: 1 [2]   Go Down

Author Topic: A Lisa Inside An FPGA  (Read 30742 times)

patrick

  • Sr. Member
  • ****
  • Karma: +92/-0
  • Offline Offline
  • Posts: 115
    • Patrick's Hardware Page
Re: A Lisa Inside An FPGA
« Reply #15 on: September 25, 2025, 03:15:20 pm »

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

AlexTheCat123

  • Sr. Member
  • ****
  • Karma: +113/-1
  • Offline Offline
  • Posts: 386
Re: A Lisa Inside An FPGA
« Reply #16 on: September 25, 2025, 05:12:05 pm »

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!
Logged

AlexTheCat123

  • Sr. Member
  • ****
  • Karma: +113/-1
  • Offline Offline
  • Posts: 386
Re: A Lisa Inside An FPGA
« Reply #17 on: October 05, 2025, 02:05:07 pm »

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!
Logged

AlexTheCat123

  • Sr. Member
  • ****
  • Karma: +113/-1
  • Offline Offline
  • Posts: 386
Re: A Lisa Inside An FPGA
« Reply #18 on: October 06, 2025, 11:41:57 pm »

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!
Logged

bmwcyclist

  • Sr. Member
  • ****
  • Karma: +21/-0
  • Offline Offline
  • Posts: 204
Re: A Lisa Inside An FPGA
« Reply #19 on: October 07, 2025, 07:36:33 am »

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"!

Logged
Using my LISA for writing blogs and other work projects and fun and games at home. LISA 2/10, AST RAM board, ESProfile, FloppyEMU, Mac2LISA Mac extended keyboard, reproduction LISA 1 mouse.

stepleton

  • Hero Member
  • *****
  • Karma: +159/-1
  • Online Online
  • Posts: 521
Re: A Lisa Inside An FPGA
« Reply #20 on: October 07, 2025, 01:42:15 pm »

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!
Logged
Pages: 1 [2]   Go Up