Also from the Netherlands

[TimoHartong]

Hi I'm in the process of assisting the BouwmachinesvanToen museum in restoring a dragline simulator which was used at the SOMA ( School for plant operators in the Netherlands ) to train their pupils. The museum has indicated that they prefer to have a replacement for the MTX512 so I thought of using a pi

[Bill B]

Is the simulator pure software, or does it interface to any special hardware?

If pure software, then you want MEMU. That will run on any Raspberry Pi with HDMI display, or even on a Pico with VGA display.

If the simulator needs to control any hardware, then that can be done using GPIO. It may be necessary to slightly customise MEMU to get whatever inputs and outputs you need. Also be aware that while the MTX has 5v inputs and outputs, those on a Raspberry Pi or Pico are only 3.3v.

[TimoHartong]

Hi Bill,

Unfortunately it supports some (custom ) hardware. I have been compiling MEMU software for the Pi but that seems not to be working. The normal LINUX version seems to work on the pi . Indeed interfacing the hardware will be the next challenge because the pi IO is not even 5 Volt tolerant.

[Bill B]

Unfortunately it supports some (custom ) hardware. ... Indeed interfacing the hardware will be the next challenge because the pi IO is not even 5 Volt tolerant.

How was the hardware attached?

• Centronics Printer Port
• The internal 20-pin Custom I/O DIP socket
• The 60-way edge connector

Depending upon the attached hardware, outputs from a 3.3v CMOS device can directly drive 5v TTL inputs. Providing the data rate is not too high, a simple resistor divider can reduce 5v outputs from the attached hardware to 3.3v. Bidirectional connections are more difficult, but there are many types of interface chip for that. If you can post more details I will see what I can suggest.

I have been compiling MEMU software for the Pi but that seems not to be working.

Yes, the Pi specific version of MEMU is obsolete. It uses an interface to the GPU that is no longer supported on the later Pi's for display. Also the way it talks to the GPIO is not supported on recent Linux distributions. At some time I need to re-work that, to have a modern version with GPIO support.

[TimoHartong]

Hi Bill,

It is connected to the "The internal 20-pin Custom I/O DIP socket" and the data rate is I don't think the data rate was that high. It only read in some buttoms and some analuge values. It looks that a value was first outputted which selected a chip ( ADC, 74LS245 ) and the value was read in at the bus.

I hope this is an incentive to work on a modern GPIO implementation I'm more than happy to test it .

[Bill B]

I hope this is an incentive to work on a modern GPIO implementation I'm more than happy to test it .

Any preference: Raspberry Pi or Pico? The Pico has the advantage of much faster boot (no Linux operating system).

If just reading buttons then they probably have a simple pull-up to 5v. Change that to 3.3v and they are safe.

The MTX is not capable of directly reading analogue values. Does the external hardware include an ADC chip?

Do you have a circuit diagram for the attached hardware? Can you post it?

[TimoHartong]

Hi Bill,

First of all thanks for all the support . I have laying around a number of Raspberry Pi (Zero's) so that is my preference. The external hardware does contain an ADC ( an AD7581). Unfortunately there is no schematics available from the external hardware ( lost in time ).
I have been able to save the software by a good friend who had a high end cassette deck and transferred the tapes to WAV with Tapeview I was able to retrieve the software so that gave some insight how the software was interacting with the external hardware

[Bill B]

For use with a Pi Zero I would suggest something like this. It provides 16 Input / Outputs at 5v, as per the MTX I/O port.

I have got something I am trying to finish first, then I will have a look at adding support for this to MEMU.

[TimoHartong]

That looks indeed as an interesting option. I will look if it is also available in the Netherlands. Just take the time it is a hobby

[Bill B]

Having looked at the code, support for an I2C port expander was in reasonable shape, and it was not too much work to hack it into he Linux builds.

Pull the latest code from my repository, then either:

Code: Select all

cd MEMU
mkdir build
cd build
cmake -DTARGET=XWin -DHW_23017=Y ..
make

Or:

Code: Select all

cd MEMU
mkdir build
cd build
cmake -DTARGET=FBuf -DHW_23017=Y ..
make

To run the program you will need a hardware.cfg file (see docs/Hardware_Config.pdf), like:

Code: Select all

[PIO]
PIN0,MCP23017,/dev/i2c-1,0x20,A0
PIN1,MCP23017,/dev/i2c-1,0x20,A1
PIN2,MCP23017,/dev/i2c-1,0x20,A2
PIN3,MCP23017,/dev/i2c-1,0x20,A3
PIN4,MCP23017,/dev/i2c-1,0x20,A4
PIN5,MCP23017,/dev/i2c-1,0x20,A5
PIN6,MCP23017,/dev/i2c-1,0x20,A6
PIN7,MCP23017,/dev/i2c-1,0x20,A7
POT0,MCP23017,/dev/i2c-1,0x20,B0
POT1,MCP23017,/dev/i2c-1,0x20,B1
POT2,MCP23017,/dev/i2c-1,0x20,B2
POT3,MCP23017,/dev/i2c-1,0x20,B3
POT4,MCP23017,/dev/i2c-1,0x20,B4
POT5,MCP23017,/dev/i2c-1,0x20,B5
POT6,MCP23017,/dev/i2c-1,0x20,B6
POT7,MCP23017,/dev/i2c-1,0x20,B7

Then start MEMU using:

Code: Select all

memu-x -config-file memu.cfg -hw-config hardware.cfg

(Replace memu-x by memu-fb if that is what you want to use.)

Note that while this simulates the 8 input and 8 output bits, it does not simulate the two strobe lines. If these are needed by the hardware, and given that these will be time sensitive, I would suggest using a latch (74LS373) to provide INSTB and a tri-state buffer (74LS244) to provide OTSTB. In which case, build your own circuit board with these and an MCP23017, rather than use a commercial board.

Providing a version of MEMU with support for the RPi inbuilt GPIOs is going to take rather longer. One issue is that libgpiod v2 (which is the future of GPIO control) is not currently provided by RPi OS.