GPIO Expanders for nostalgy project

[Back2Volts]

Some time in the late seventies, I got myself a $49 minimum set of chips to put together an 8080.   It included the supporting chips  and eight static one kilo bit memory chips.   I was able to hand wire wrap all these parts and a few more on a board, which I still have, and that by itself cold do nothing.

To control the board, I designed and built, another component, to allow me to HOLD the 8080 and take control of the buses.   In those years I was working in steal mill process control, using mini computers that had switch consoles to load/display/update address and such...   So I ended with a large, long board, with a bunch of toggle switches and LEDs and a ton of 74LS chips.   This board is gone.

Recently, I run into the 8080 board, and I though it would be fun to rebuild the missing control using modern technology, so here we go.

I have settled on the RP2040, those state machines are something else.   Ideally, I would like to have some SPI driven GPIO expanders for the interface layer, 3.6 Volts, tolerant to 5V, with the ability to go 3-state.

It seems to me that the typical MCP23009/17.. do not have the ability to go high impedance on the pins.   Am I right?

The only part I have found, is the XRA1403 from MaxLinear, https://assets.maxlinear.com/web/documents/xra1403.pdf.
   
Are there other parts I could use?

Attached board picture, in desperate need of some TLC.

[MarkL]

The MCP23009/17 does have the ability to be high impedance.  Just set the IODIR bit for the pin to make it an input, or since it's an open-drain device leave the output high.  By default on power-up it's an input anyway.  And if you want the SPI version of the part, it would be the "S" version, e.g. MCP23S09.  If you want totem-pole outputs (push-pull), it would be MCP23S08 (also with the ability for high impedance).

However, the MCP23xxx isn't 5V tolerant when operated at a lower Vdd.  One approach would be to run the MCP23xxx at 5V and provide a level translator for the SPI signals.  Then you could add as many MCP23xxx as you need to interface to the old TTL signals.

Alternatively, the NXP PCA9502 is a 3.3V (max 3.6V) GPIO expander with 5V tolerance.

Why not the XRA1403 that you found?  Looks like it meets your constraints.

[Back2Volts]

Yes, I think I will go with the XRA1403.     Thank you.

[fchk]

You might rethink your choice of the RP2040.

An ATmega128/1280/1281/2560/2561 might be a better solution. It has an external Memory Bus similar to the 8080, although multiplexed (HC573 for demultiplexing needed). This would allow you to take over the bus, load memory and then enable the 8080. It's a 5V device, so you don't need level shifters. And you don't need IO expanders. If you need USB, there is the AT90USB1286/87.

fchk

[Back2Volts]

Thank you for the idea.   There are a number of reasons I prefer to stay with the RP2040.

First, I have been reading deep into the RP2040 support for state machines,and I think it is ideal for what I am trying to do, as far as interacting with bus controls, memory cycles, etc...with pretty much guarantied timings up to a level.   I think I could even implement instruction step by step.

Second, I can program most of it if not all in micro-python, even the state machines.   I do not believe that would be an option with ATmega.   If I was to take another MCU, it would be in the STM32 line, supports micro-python and I have done some work with hem , but I looked into it and discarded it.

Third, I have never touched the ATmega line, and the appeal it may bring is not enough for me to move in that direction now.   May I add I am way up there in age and this may be the last project.   In fact I have been unloading some of my lab equipment, HP and Tektronics scopes, meters...   Witch now, I may need to buy a low end scope for the project, but it is not about money.

Fourth, I want to a GUI from PC, and with micro-python, I can have an HTTP server.   At a later time I can switch to the newer RP2040, with WIFI/BLE.

I have been thinking about it for a few weeks, and I think this weekend, I have solved the last hurdle, the GPIOs layer.

Thank you for your idea though.     

[MarkL]

Yes, I think I will go with the XRA1403.     Thank you.

I'm not up on my RPi kernel versions, but there is a driver for the XRA1403 that has been in the kernel for several years if you don't want to write your own SPI-level stuff.  You could access the XRA1403 I/O pins via the sysfs interface (old way) or character device (new way).  The sysfs interface is deprecated, so it might not be there in your kernel version anyway.  In either case you would just add the XRA1403 to the device tree.  FYI.

[tooki]

Yes, I think I will go with the XRA1403.     Thank you.

I'm not up on my RPi kernel versions, but there is a driver for the XRA1403 that has been in the kernel for several years if you don't want to write your own SPI-level stuff.  You could access the XRA1403 I/O pins via the sysfs interface (old way) or character device (new way).  The sysfs interface is deprecated, so it might not be there in your kernel version anyway.  In either case you would just add the XRA1403 to the device tree.  FYI.

The RP2040 is the RPi Pico, which is an MCU board, not a Linux SBC.

[Simon]

Just use another micro controller