Idea: Arduino style board for hacking the PDS slot?

[marciot]

Hi everyone,

I have a recently restored LC II to play around with. I've been poking around the schematics and have learned that the PDS slot is basically a giant breadboard that gives you access to all the processor pins. This got me thinking about what kind of interesting hacks could be done using that slot and modern electronics.

The most interesting hack I've found so far was this one, which captures video directly from the PDS of a Macintosh SE using a microcontroller:

srm32f4discovery – Hackaday

hackaday.com

It got me thinking about how neat it would be to have a low-cost Arduino-like PDS card that could be used to implement interesting, and maybe useful projects for vintage Macs, without requiring a mess of jumper wires.

I got to thinking about this and started listing out some requirements and/or gotchas.

1) The microcontroller needs at least 39 GPIO pins for Macs with a 16-bit bus: 23 for the address, and 16 for the data
2) The microcontroller needs to be 5V tolerant, for *read-only* observation of the bus
3) Tri-state level shifters would be needed for *read-write* access to the bus.
4) The microcontroller clock speed needs to exceed the bus speed of the Mac by a significant margin
5) Different Macs have different PDS slots, so making a universal card may or may not be possible

It seems that requirement 3 would drive up the cost of the card quite a bit, but I still think interesting things can be done with read-only access. Examples:

1) A VGA card for compact Macs; possibly making using of "classic" Quickdraw in eight color mode.
2) Screen casting via Wifi, maybe using an ESP32 as a bridge?
2) Driving LED matrices and other external things
3) Sending messages to IoT devices for home automation

Another cost-related question is the PDS connector. I understand these are technically Eurocard style connectors, but it appears as if standard pin headers can fit the PDS slot. Is there any danger of damaging the connector by using these instead of the correct Eurocard style connector?

For people who have more experience designing cards and getting them manufactured, what do you think would be the cost of such a card, if a service such as JLCPCB was used for assembly?

Anyhow, I am more of a software guy, and less so a hardware guy, which is why I am asking these questions here just to brainstorm some ideas.

 

[marciot]

Also, since I primarily have Mac Plus computers in my collection, I am curious whether something similar could be done for those machines, maybe by interfacing with the CPU socket itself.

 

[Johnnya101]

That would be a really cool project. Only big thing to keep in mind is that different models have different PDS pinouts.

Would be good to finally have something for the IIfx PDS slot...

 

[cheesestraws]

I was thinking about this myself a little while ago, as another software person with limited hardware experience (fun, isn't it). They say there's nothing worse than a software person with a soldering iron, right?

Something worth noting in this connection is that someone managed to make a functional mini-podule for the Acorn A30x0 using one of the RPsomethingsomething microcontrollers; although those podules have only an 8-bit data bus.

The main issue I ran into with a thud was enough GPIO pins in a reasonably affordable package. I had a go at an alternate design that used latches to allow for reading/writing 32 bits in 8-bit chunks, but it got very complicated very fast, especially when writes were involved.

Another idea I had on this front was just restricting reads and writes to being 8 bits wide to the card, and just having an 8-bit data path, rather like the mini podule. I have a vague memory that Lisa cards had this restriction (??). And it would cut down on the number of required pins somewhat.

I also noodled out vague timings based on a couple of fastish microcontrollers, and I think it should work: at least, I could put some stuff out on GPIO pins fast enough to satisfy what the timing requirements are stated to be in Cards and Drivers.

 

[marciot]

@cheesestraws: Yeah, I really wanted to use all the little dev boards in my collection, especially the ESP32 ones with WiFi, but they all max out at about two dozen pins. That really does seem to be the biggest challenge.

The next biggest challenge is 5V compatibility and following that allowing the 68000 to read values from the card. Add level shifters and tri-state buffers and the complexity goes up significantly.

I feel like a card would be hobbled by being output-only, so maybe there is a halfway compromise, where it is 16-bits in one direction and 8-bits in the other. The STM32F4DISCOVERY board listed above seems capable of reading the address and 16-bit data bus directly with no interfacing logic (because it appears the GPIO pins are 5V tolerant), but maybe we could add a tri-state buffer in one half of the data bus to allow for 8-bit input by the 68000 CPU.

 

[Trash80toHP_Mini]

KISS: design only a right angle adapter for the LCIII PDS that really is the equivalent of a breadboard.

My suggestion has always been to use a PCI Slot connector. In that configuration a 10cm x 10cm prototyping board only needs the edgecard interface implemented to slot right in. Keep it low profile and you can install protoboards component side up for live testing.

Start out with a 10cm x 10cm .05 pitch grid protoboard as your "PCI Slot/PDS" reference design. That'll be useful right out of the gate for interfacing PiHat form factor boards. Who ever puts the lid back on a case when prototyping anyway?

 

[bdurbrow]

A Microcontroller won't have the performance needed for a direct CPU-bus interface. You'll need to use a CPLD and some discrete logic at a minimum; but adding a FPGA to the mix would really help matters.

The XC9500 series CPLD is 5V tolerant but runs at 3.3v; and is available in QFP packaging (so, no need to try to solder a BGA). This is what my design ideas for general-purpose FPGA cards were based around (no, I have no idea when I'll be able to get back to working on that - I've got too many other projects that are demanding of my time).

You'd probably want to choose RAM that was capable of responding at several times the PDS clock rate; so that you could do cycle-sharing: one cycle for the CPU, one cycle for whatever the RAM buffer was being used for (video out? data capture?) - this would eliminate the need for dual-ported RAM.

 

[Johnnya101]

I don't know too much about electronic stuff like this, but what about a pi instead? Kind of...defeats the purpose of old computers somewhat...but opens the door to pretty much anything I would think.

 

[marciot]

A Microcontroller won't have the performance needed for a direct CPU-bus interface. You'll need to use a CPLD and some discrete logic at a minimum; but adding a FPGA to the mix would really help matters.

That’s what everybody on hackaday thought, but the project I posted above shows that it is possible. I think that’s a game changer, because it really simplifies things.

 

[cheesestraws]

Here's the RP2040 podule project:

Arc Pipe Podule (homemade RP2040-based podule) - stardot.org.uk

stardot.org.uk

GitHub - evansm7/arc2040podule-hw: PCB design for Acorn Archimedes RP2040-based podule

PCB design for Acorn Archimedes RP2040-based podule - GitHub - evansm7/arc2040podule-hw: PCB design for Acorn Archimedes RP2040-based podule

github.com

Note the use of a dual core microcontroller, one bitbanging the bus, one actually computing stuff. Same approach would likely work for at least the slower PDS slots.

A Microcontroller won't have the performance needed for a direct CPU-bus interface

I remain unconvinced of this: the permitted timings for PDS are looser than I expected. I may be missing something but at least with some tight coding, it looked doable to me? What numbers are you basing this on?

I don't know too much about electronic stuff like this, but what about a pi instead?

The problem with a Pi is that it's really designed as a computer in its own right: you'd have to run bare metal code on it, rather than using Linux or anything, and at that point you're just using it as a badly-documented microcontroller anyway.

 

[Trash80toHP_Mini]

Very cool that Podule setup, almost illustrates my notion for generic hardware interface for PDS development. AI diagrams forthcoming, definitely in a dedicated thread. Need some feedback before I start.

Does it matter if ayour prototyping setup would keep the assy within confines of closed case or for exo-lid playtime? PDS connector choice offers a several options for direction, LA, RA and Vertical orientation of both the PDS EuroDIN and protoboard edgecard connector.

Same adapter board would cover all PDS implementations, LC through PPC.


edit: maybe I should just start that DevBoard thread before you answer to keep this topic on track?

 

[cheesestraws]

Very cool that Podule setup, almost illustrates my notion for generic hardware interface for PDS development

Yes, it's really nifty. I was honestly quite surprised that it worked when the thread on stardot first turned up, because I too was languishing under the idea that this was probably impossible.

edit: maybe I should start that DevBoard thread before you answer to keep this one on track?.

I think so: the physical design and microcontroller gubbins are probably two separate threads of conversation that would benefit from being separate threads

 

[Trash80toHP_Mini]

Cool, I'll do some sketches at work tonight to kick that off later. I'm particularly interested in LCIII, SE/30 and IIsi variants of the proposed universal interface setup.

Microcontroller gubbins would be my other area of interest. Strongly suggest that RPi Compute Module be used if going that way. I've got plans for using a single module I can easily move between several projects. The most enticing prospect would be its PCIe expansion capability. So one notion aligning with the flow of this thread:


Can't get the notion of HDD running on IIfx PDS out of my noggin. That'd blow my JackHammer completely out of the water.

 

[Johnnya101]

Can't get the notion of HDD running on IIfx PDS out of my noggin. That'd blow my JackHammer completely out of the water.

That would be awesome. I don't think there are any PDS cards made for the IIfx except I think the tokamac used it and there's some sort of SCSI card for it, both impossible to find. It's begging for some sort of new use!

 

[MacKilRoy]

I wonder if a NuBUS card could also easily be made? Or is PDS easier?

Imagine a card, with some sort of Raspberry Pi or something, which runs a diagnostic on boot, of the connected machine, for troubleshooting. Theoretically it could probe the various points of the machine, couldn't it (even more so than a Snooper card)?

 

[bdurbrow]

What numbers are you basing this on?

I haven't had a chance to fully read the thread since I made the post - and I'm on my way out the door right now - so I'll have more to say about it later; but...

I am making the presumption that the MCU will service interrupts other than the bus interface interrupt; which will totally kill any timing constraints. IIRC, there's a rather short window in which to detect that a cycle is in your address range and assert a wait state for your MCU to catch up in. Although possible to do in discrete logic, it really makes more sense to just use a CPLD to do that. XC9500 series CPLDs seem suited to the task, and they're not too hard to work with.

Also, having the MCU get interrupted for every bus cycle and then have to determine that it's either the target or not in software; well, that's not going to leave much time for doing anything else with the MCU. Easier to pop an extra chip on the board to deal with this specifically.

 

[bdurbrow]

OK, I'm back and have had a chance to read the thread.

It looks like it's not quite as bad as I had thought; however I'd still use a CPLD to manage the low-level bus interface - it's just not that hard of a thing to integrate, compared to what it gives you.

---

From Designing Cards and Drivers for the Macintosh Family, 2nd Edition:

There is an overriding watchdog timer on the Macintosh SE/30 main logic board that generates a /BERR signal anytime the address strobe is asserted for longer than 44 microseconds. You must guarantee that your design generates a /DSACKx, /BERR, or other termination signal within this period.

And assuming - just for ballpark estimates - a SAMD21 running at 48mhz, which is what is found in the Arduino Zero and related boards --- doing the math, that gets you 2112 MCU clock cycles before the system board throws a bus error. The Cortex-M0+ has 15 clock cycles for interrupt latency; and another 13 on exit - however, it also has some efficiency features like tail-chaining ISRs if there's a pending interrupt. The MCU does not save all the registers on entry, however, so there will be some additional software overhead for saving anything that the ISR code uses - again, just for a ballpark estimate, suppose it's 16 cycles on entry and 16 on exit.

15 + 13 + 16 + 16 = 60 clock cycles for getting into the ISR and back out again.

Then you have to do the address decoding; figure another 10-30 cycles for that, depending on how complex your card's memory map is.

Flipping the right bits on the MCU's I/O port in order to acknowledge the bus access would take a few more clock cycles.

The IIfx is of course faster, with tighter timing requirements:

An overriding timer on the main logic board generates a /BERR signal anytime the address strobe (/AS) is asserted for longer than 16 microseconds. Your expansion card design must include a provision for generating /DSACK, /BERR, or other terminating signals within this period.

For the same SAMD21; that yields 768 MCU clock cycles before a bus error is thrown.

So... you could get a fast MCU to handle it without causing constant bus errors.

However, that still leaves the issue of being hit with an interrupt at 1/4th the Mac's system speed (the 68030 bus has 4 phases). Even figuring that your MCU is only going to actually acknowledge bus cycles that were aimed at it; and ignore everything else - that still leaves it evaluating each bus cycle to figure out that it wasn't aimed at it. Given the above ballpark figures, if I did the math right, that SAMD21 will 100% saturate with a Mac system bus speed of 1.92Mhz - so, even an SE/30 would swamp it.

If you use a CPLD to do the address decoding and bus management, your MCU won't be swamped by servicing interrupts like that; and you also don't have to use up MCU pins on the high bits of the address bus.

It is possible to use discrete chips to do this (inverters, multi-input AND gates, and possibly a SPDT DIP switch if you want to be able to set the address range after the board is soldered together), but that does get a bit bulky.

---

I wonder if a NuBUS card could also easily be made? Or is PDS easier?

PDS is easier; but not by that much. NuBus requires the addition of a latch to store the address in, and the bus cycle is a bit different.

 

[buserror]

You should check PiStorm. Desolder the 68k, install PiStorm and you get software running the Mac instead. Right now it's pretty early stage, but it boots.
I've socketed the 68k on a mac SE here, and plan to hack away at that project for a little while...

 

[CircuitBored]

You should check PiStorm. Desolder the 68k, install PiStorm and you get software running the Mac instead.

PiStorm is (currently) only compatible with 16-bit systems, meaning it can only be installed in machines with 68000, 68010 or 68020 CPUs. This sadly excludes the LC II. I've been trying to get PiStorm working in a Classic for quite a while to minimal success. It's an exciting project but the Mac side of it is developing at a very slow pace compared to Amigaland.

 

[cheesestraws]

It's also not really a way of developing or exploring PDS cards...