Parallel Port interface possabilites

[Pickle]

Ive built a mt32 pi with the rpi 3+. I already have the uart and usb (roland um-one) working (and they work well).
The only thing I found missing was protected mode games on dos machines with no MPU 401 (i.e. laptops)
The first thing that comes to mind is the dreamblaster on parallel port which is reported to work with protected mode.
It seems from the softmpu asm source that the data bytes are just sent on the port with a little delay between them.
So the question is if the m32-pi could do the same. If it could then it really opens the capabilities on old machines.

So i happened across this project as well:
https://github.com/worlickwerx/pi-parport

The above solution might be overkill, i dont know that all the control pins would really be needed. If softmpu is really just bit-bashing the data maybe the rpi3 just has to continually poll 8 gpio pins to capture the data.

I might try getting a level converter and build a hat then use s2p softmpu to see if data can be captured.
Also if anyone has better ideas Id be interested.

[dwhinham]

Honestly, I think a better use of time and effort would be focussing on patching the protected mode games to output MIDI via serial port rather than MPU or parallel port. Some work has already been done here by Cloudschatze for the MPU-232, a serial port MIDI interface: https://www.vogons.org/viewtopic.php?f=62&t=81178

When your serial port is delivering the MIDI, you can use a cheap USB to serial cable with the PC/laptop as described in the wiki, or native RPi UART with MAX232. You can even use the official Roland serial port MIDI driver from within Windows with this setup.

James MacKenzie did a nice video demonstrating this kind of configuration: https://www.youtube.com/watch?v=SxMjDsT9rEo

I can only see negatives for a custom parallel port solution. The HAT linked uses a huge chunk of GPIO on the Pi and even just the data pins conflict with the ones I've reserved for controls/buttons. Polling the GPIOs could be a pain to implement without affecting the tight deadlines of the audio rendering and other tasks and it'd make the code more complex and difficult for me to maintain and test (I don't have any hardware to even start with this). It'd need custom hardware; serial port stuff can be found cheaply and easily on Amazon or eBay.

Would strongly recommend going with the serial port and encouraging development of patches to take care of the remaining protected mode games. The end of the thread linked above suggests interest in developing more generic tools that could be used to patch multiple games.

[Pickle]

I wasnt aware that many patches had been created. Like i mentioned I do have the serial connection *uart" functioning on my setup so i will try that out.

I agree with you that the HAT as is wouldnt work because of the GPIO conflicts. I meant to include it as an idea.
I dont think i was correct on how the S2P is receiving data. It does to appear it could be using some of the io control
For reference here is the pinout:

S2P is wired up to the following pins on the DB25 connector :
1: A0 -> /Strobe CTRL-0
2: D0 <-> Data0
3: D1 <-> Data1
4: D2 <-> Data2
5: D3 <-> Data3
6: D4 <-> Data4
7: D5 <-> Data5
8: D6 <-> Data6
9: D7 <-> Data7
10: /RESET - Ack
14: /CS -> /Linefeed CTRL-1
15: IRQ <- Error Status-3
16: /WR -> Init CTRL-2
17: /RD -> /Select CTRL-3

I suspect a gpio might be used as an interrupt but maybe it adds too much cpu usage even with that type of setup rather than polling.
Thanks for the feedback and the work on this project. I was pleasantly surprised it all basically just worked. I have an oled screen, i2s dac, roland um-one, and uart. I need to create my own hat with buttons and 3d print a case.