Print

[stepleton]

(all out of curiosity)

Are the level shifters for the CPLD? That SRAM itself seems to accept and send TTL-compatible signals, though the outputs won't go up to a full +5V.

What kind of things does the CPLD do? I only scanned the Lisa Hardware Manual about this once, but I took away the impression that some of the work of the support logic was dealing with placing the RAM board in the appropriate part of the address space. (As the SRAM is a full 2 MB, the correct positioning is straightforward: it takes up all of it.) Furthermore, there's no need for DRAM refresh, so maybe that simplifies things too.

I suppose I'd hoped therefore that you might be able to reduce necessary logic down to a few surface-mount TTL ICs. You might put them on both sides of the board to achieve more compactness, though it would be better to avoid that so that you can use a hotplate for assembly.

But I assume there is plenty of remaining devil in various timing details for RAM reads/writes, etc.

Meanwhile, I was always wondering if you could replace the COP with a suitably busy Arduino (with enough pins)...

[sigma7]

Amazing progress!

Indeed!

vision of an SRAM-based RAM card that would be comically small inside of the card cage, and I'd even had my eye on this single, somewhat pricy RAM chip (Infineon CY62167ELL-45ZXI), with its 16-bit data bus
...
But I hadn't started to sweat the details yet

I suspect parity could become a sweaty consideration, so I suggest sorting out how you will handle the parity issue before finalizing your part requirements.

The issue is that the parity test circuitry allows storing bad parity in multiple byte addresses for discovery at an indeterminate time.

IIRC, the POST sets bad parity at only one address, so rather than storing parity, it is possible to record that address and report the parity error when it is read again, but if some software (LisaTest maybe?) does a more complicated parity circuit test, it may discover your secret of circumventing stored parity bits.

Modifying the CPU ROM to remove the parity circuit check may be sufficient for most operation, but some purists prefer LisaTest success, and I don't know if anything else checks the parity circuits, so ymmv etc.

[sigma7]

MacWorks Plus II - Gives error about PFG since we don't have a PFG installed

Since you don't have a fully functional SCC module, and possibly don't want to develop one (in particular with the SDLC (or whatever it is) complication that makes LocalTalk possible), you might consider using a real SCC, which then makes plugging in a real PFG an option. And/or we can figure out a strategy for implementing any desirable features of the PFG without the real hardware if the SCC can be adequately emulated.

But this is just one aspect of what the final result might be... now that you've very well established a proof of concept, it might be time to brainstorm the final objectives...

For example, is it, or some version of it, going to:

• completely replace real Lisa hardware including card cage, video, chassis, specific expansion cards, while not supporting arbitrary real expansion cards?
• replace the CPU and memory boards in a real Lisa card cage/chassis that uses real motherboard, video, I/O and expansion cards?
• replace CPU, memory, and I/O boards in motherboard form-factor so real expansion cards can be inserted in a real chassis?

Lots of options to consider that have their benefits and drawbacks... some of the challenges of being the project manager!

[AlexTheCat123]

Yeah, I know it would be some pretty simple logic, but the purpose of the CPLD would be consolidating the small amount of TTL logic that would be required as well as figuring out parity. It could be done in TTL too, but I figured that a CPLD would probably be more compact and inexpensive. I was thinking about doing @sigma7's strategy of remembering the one address that the boot ROM does the "write wrong parity" test to, but it's true that we don't really know what else may use this feature. It would be easy enough to find out though; just boot each Lisa OS with the FPGA-based Lisa set to trigger on accesses to the appropriate address in the system control latch.

Unlike the SRAM card (if and when I get around to making that), I want to actually handle parity the proper way in the FPGA-based Lisa. So I was thinking about using the external SRAM for the main memory and then still keeping the parity inside the FPGA's block RAM.

Since you don't have a fully functional SCC module, and possibly don't want to develop one (in particular with the SDLC (or whatever it is) complication that makes LocalTalk possible), you might consider using a real SCC, which then makes plugging in a real PFG an option. And/or we can figure out a strategy for implementing any desirable features of the PFG without the real hardware if the SCC can be adequately emulated.

Yeah, that's a good idea that I hadn't really thought about before! I had previously planned on (and really, REALLY dreaded) implementing the SCC myself later on, but this might be a better (even if temporary) solution.

I've already implemented the PFG in an ESP32, and I've been imagining that implementing the same state machine inside an FPGA would be even easier, so my current plan is to (at least for my own personal use) make a Verilog version of the PFG. And same for the XLerator and LSAC too. Maybe we could work out a deal where @sigma7 could sell those as IP cores that people could add to their own FPGA Lisas without having access to the source code?

But this is just one aspect of what the final result might be... now that you've very well established a proof of concept, it might be time to brainstorm the final objectives...

I'm currently imagining two different versions of the final device:
1. A modernized standalone version of the Lisa. This will be a board that sits on your desk with HDMI video output, USB (or possibly PS/2) keyboard and mouse input, built-in ESProFile hard drive emulation, USB to serial feeding directly into the Lisa's serial ports, and perhaps built-in floppy emulation if I end up writing a floppy emulator. It would also let you plug in original keyboards, mice, hard/floppy drives, and would expose the original Lisa video signal for those who want it.
2. A version in the form factor of the Lisa motherboard. This would be a drop-in replacement that people could stick straight into their Lisas to replace a bad card cage, and it would include expansion slots too, on top of all the original ports that you'd expect.

Both versions would probably have switches that would let you flip between H and 3A as well as 40 and A8 ROMs on the fly.

Option #1 is the first priority that I'm just starting to mess around with now, with #2 coming later.

[AlexTheCat123]

It's been a while, time for an update!

I'm getting pretty close to finishing the schematic for the PCB, and then I'll be onto the layout and routing phase. The whole schematic is done other than the connections of everything to the FPGA itself. Hopefully that shouldn't be too hard, I just need to look at the datasheet and make sure I connect certain Lisa signals to certain special-purpose I/O pins.

By the way, I've settled on the Xilinx Artix 7-100T as the FPGA of choice for the final board. It's pretty darn cheap at about $20, has plenty of LUTs, and between 200 and 400 I/O depending on which package you get it in. I'm currently using a little over 200 I/O, and this board doesn't even have expansion slots on it (which will add even more to that), so the 300-I/O version is going to probably be the chip of choice.

The key features of the board are:
- Power over either USB-C or barrel jack; 12V, -12V, and -5V (along with the 1V, 1.8V, and 3.3V FPGA voltages) are all generated onboard.
- USB port goes into an onboard hub chip, which feeds four devices: JTAG for FPGA programming and debugging, an onboard ESProFile, an onboard (yet-to-be-coded and I'm not even sure if I'll ever get it to work) floppy emulator, and a USB to serial chip that can directly feed the Lisa's Serial B port.
- As just mentioned, an onboard ESProFile and ESP32-based floppy emulator. There's a Floppy Emu-style OLED display and set of buttons for controlling floppy emulation, although once again none of that is implemented yet. And of course there are switches to choose whether you want to use the hard/floppy emulators or actual drives plugged into ports on the board.
- Switches to toggle between H and 3A CPU ROMs (and the corresponding VSROMs) and A8 and 40 I/O ROMs on the fly.
- The first version won't, but future versions will have Twiggy headers for the lucky few of you who happen to own a set of Twiggy drives!
- Onboard speaker (with the Lisa's 3-bit volume control) for Lisa audio, and external speaker header if you want to connect a larger one.
- Onboard contrast latch DAC in case you want to use the analog contrast signal for anything.
- HDMI video output. The VSYNC, HSYNC, and VID signals are also exposed on a header for easy connection of an RGBtoHDMI if you prefer that.
- USB keyboard and mouse input. As with the ProFile and floppy interfaces, these are switchable, so you can still plug in original Lisa keyboards and mice and use those too.
- Per James' suggestion, the Lisa's serial ports are implemented using a real 8530 SCC that you'll have to pop into a socket on the board once you receive it. But all the SCC's serial I/O pins are also bidirectionally level-shifted and run back to the FPGA so that a future version of the firmware can implement the SCC internally without requiring any changes to the PCB. The FPGA would just enable the level shifters, and that would take control from the external SCC.
- And as I mentioned earlier, Serial B is switchable between the actual DB25 port and a direct USB to serial interface with your computer, making it really easy to do things like transferring over all the LOS source code without needing a USB to 9-pin serial adapter and then a 9-pin to 25-pin serial cable.

There's no way that this thing will even come close to working on the first try, but hopefully I'll be able to figure out all the problems reasonably easily after getting a prototype run of boards in the mail.

As with some of my other recent designs, I've made sure that every part I'm sourcing is from JLCPCB/LCSC's parts library, so they'll be able to assemble the whole board for you when you order one. Which is pretty crucial given how much surface-mount stuff there is on here! The parts cost is currently looking to be a little over $100 per board, but I'm hoping to get it a little lower than that on the next board revision when some of the debugging hardware is removed.

It's still probably going to be a couple weeks before the layout and routing are done, but at least finishing up the schematic means that I'm about halfway there now!

[ried]

That is astonishing. Congratulations, Alex! Looking forward to seeing it in the real world.

[bmwcyclist]

I am stunned fantastic work thank you!!