LisaList2

You're using the patched version of MacTCP 2.1, correct?

The Glen Anderson version? No. Not yet. will give it a try tonight.

I did not see not being able to use the Asante in the list of fixes for it.

.

You're using the patched version of MacTCP 2.1, correct?

So you might have seen my post in the troubleshooting section.

I received my Asante' SCSI to Ethernet adapter yesterday.

Despite receiving an indication on the box that it was connected to my network and was seeing activity, my Lisa, running Mac OS 7.1, was unable to connect to the network. The extension loaded fine; the SCSI probe detects "something" on SCSI ID 2, but the troubleshooting app crashes, and I have no connectivity.

I was really hoping to have a solution that would work with a non-XLerated LISA. I am going to test the unit on a Mac in the next couple of days to try to rule out an issue with the Asante' hardware.

If anyone has this in a working config, any tips and or a drive image would be appreciated. Thanks!

Good news is that I managed to score an Asante EN card

Bad news is that although I got the driver installed and I've got a link light I can't select alternative ethernet in the networking control panel and when I go to the troubleshooter, I get an address error

I'm running system 71 under MAC works, I've plugged the SCSI to ethernet adapter to my sun SCSI card with and without a passive terminator.

I don't currently have an XLerator installed.

2 megs of RAM.

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.

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!

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.

(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)...

Ha, it's interesting you mention the 2MB RAM card thing; I was just thinking about doing something like that! All the RAM card logic I've written would easily fit into a small CPLD, so throwing the CPLD, some level shifters, and the SRAM onto a tiny little board would work nicely. And funnily enough, that SRAM chip is the exact one that I've been eyeing for the FPGA!

The COP core I'm using seems to also be small enough to fit into a CPLD, so a CPLD-based COP replacement could be another interesting idea...

https://www.folklore.org/Alice.html?sort=date I doubt those early builds still exist but one can only hope something was backed up somewhere. Steve Capps is still alive... maybe he knows?