General Category > LisaList2

A Lisa Inside An FPGA

<< < (3/8) > >>

classiccomputing:
Wow, this is big news, and thank you for your efforts Alex! I can't wait to own one, and I will want one.

jamesdenton:

--- Quote from: AlexTheCat123 on September 19, 2025, 02:51:00 pm ---It's not pretty, but that is indisputably a CPU board error 41 on the screen. Which is exactly what we'd expect to get from a fully-functional yet I/O board-less Lisa!

Now I just need to figure out why it looks so terrible...

--- End quote ---

Incredible! Where do you find the time??

Nice work!

AlexTheCat123:

--- Quote from: classiccomputing on September 19, 2025, 06:37:41 pm ---Wow, this is big news, and thank you for your efforts Alex! I can't wait to own one, and I will want one.

--- End quote ---

Progress has been great so far, but it's probably going to be a while before we get to that point of other people being able to build one! Getting I/O working and deciding how much I want to modernize that stuff as opposed to requiring the use of original Lisa hardware (like adding native support for USB keyboards/mice vs making the user plug in Lisa originals) is what I anticipate to be the hard part.

For instance, I'm working on piping the Lisa's video output straight through HDMI right now, and that's proving to be a bit weird/challenging in several ways. But it'll be nice once I succeed because then we'll no longer have a need for an RGBtoHDMI, and the Lisa's contrast control can be simulated by simply adjusting the intensity of the white sent over the HDMI link.


--- Quote from: jamesdenton on September 19, 2025, 08:48:17 pm ---Incredible! Where do you find the time??

--- End quote ---

Just working on it whenever I'm done with school and homework for the day, and as much as I can on weekends. The PhD program keeps me busy, but luckily I've still got enough spare time to fit in a couple things like this!

bmwcyclist:
Thank you so much !

AlexTheCat123:
The video problems have been fixed; it turns out that they were being caused by a RAM timing issue where video reads from RAM were occasionally causing addresses adjacent to the current read address to be overwritten with random garbage. This one was really subtle and took a long time to figure out!

I've moved onto the I/O board now, and I've finished the initial design of the whole thing other than Page 2 of the original schematics, which contains the keyboard VIA and the COP. Since the COP core I found is in VHDL, whereas the rest of my code is in SystemVerilog, and I'm a bit nervous about integrating the two, I think I'm going to implement everything but the COP and then come back for that later. We should still get waayyy further in the boot process even in its absence.

Some people might be wondering what cores I'm using for the 6504, 6522s, 8530 SCC, and the (yet to be integrated) COP. Well, no 6504 cores seem to exist, so I'm using this transistor-accurate 6502 core instead. As for the 6522 and 8530, I'm using the cores from the NanoMac project. The 6522 core seems really accurate and fully-featured, but the SCC core leaves a lot to be desired; it seems to just implement the bare minimum to get the Mac to work and leaves out a lot of I/O lines used by the Lisa. But it's the only 8530 that I could find, and it should at least get us booting. And last but not least, the COP. I'll be using the T400 core, which as I said is written in VHDL instead of Verilog, which hopefully won't cause too many headaches. It also has a really weird/unpleasent way of reading in the ROM (you have to run a script that generates a VHDL file that's essentially a massive case statement for each ROM address instead of just using $readmemh) and some weird platform-specific scripts that you have to run, so I'm hoping that none of that causes a problem.

I should be able to start testing the I/O board in simulation by tonight or tomorrow, and then in actual hardware whenever I get all the simulation kinks worked out!

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version