mrkirkby wrote:I got mine, soldered it up and after a re-socket and a bit of isopropyl on the second ya ha ha chip, I have sound! Woo.. Fired up Monkey2 and it seems to be working after a bit of emm386 startup config alteration.There's slight distortion on the sound. I'm guessing that's normal for the adlib era? or do I have a crappy solder joint some place?Word of enlightenment. If your sound is all 90% noise / distortion and 10% signal, you probably want to re-seat that smaller Yamaha chip in its socket.Great product! Now for an LPT MPU / Midi interface for the MT32? ??

hi mrkirkby,nice, that's great.and welcome on the forum !!!

Can you try with a large headphone, if you still hear distortion ?The amp is suitable for line out and also direct headphone,best not to set it too high when using for line out to powered speakers

mrkirkby wrote:Great product! Now for an LPT MPU / Midi interface for the MT32? ??

LPT MIDI interfaces did exist, only need to clone one or design a new one. It will be easiest to modify SoftMPU to work with LPT connected UART/microcontroller.Full MPU emulation on a LPT dongle won't be necessary.

derSammler wrote:Err... serial port and SoftMPU?

Generally, serial ports are not compatible with MIDI baud rate, so standard MIDI devices can't work even if physical signal is converted from RS232 voltage levels to MIDI current loop.However, some MIDI modules can be connected to RS232 serial ports with standard PC baud rates.

Jepael wrote:Generally, serial ports are not compatible with MIDI baud rate, so standard MIDI devices can't work even if physical signal is converted from RS232 voltage levels to MIDI current loop.However, some MIDI modules can be connected to RS232 serial ports with standard PC baud rates.

But what if you make a sort of FIFO buffer?I am thinking of something similar to the Disney Sound Source: the data can come in at any rate, and it clocks it out at 7 kHz.If you were to build something like that, which can accept data at any rate (either from a COM or LPT port, wouldn't really matter how you do it, COM may be simpler), and has a simple output circuit that outputs at the correct rate and voltage for MIDI.That might be a very simple and cheap solution.

Scali wrote:But what if you make a sort of FIFO buffer?I am thinking of something similar to the Disney Sound Source: the data can come in at any rate, and it clocks it out at 7 kHz.If you were to build something like that, which can accept data at any rate (either from a COM or LPT port, wouldn't really matter how you do it, COM may be simpler), and has a simple output circuit that outputs at the correct rate and voltage for MIDI.That might be a very simple and cheap solution.

Sure it's possible; there are already projects like that. For COM port the are hobby projects that have a simple microcontroller with two UARTs, one talks to PC usually at 38400 bps, other talks to MIDI at 31250 bps. Can even be built from some Arduino boards maybe, only needs one with two UARTs.For LPT port to MIDI, there are even commercial devices such as Midiman Portman.

Same one missing as me! Was it just missing from the kit?I got ten of them for under £2 on ebay which have turned up today - swapped out the alternate one I put in and it's a much cleaner sound now. Still doesn't work on the PS/2 though.

SteveC wrote:Same one missing as me! Was it just missing from the kit?I got ten of them for under £2 on ebay which have turned up today - swapped out the alternate one I put in and it's a much cleaner sound now. Still doesn't work on the PS/2 though.

Yeah it seems i must have made a mistake and forgot the LM358 in some kits... oops My apologies !! DerSammler I will send you one.I checked the remaining kits I had prepared here, and all of them had LM358 in it... so I hope it was only you 2..

The jumper = JEPEAL BASS BOOST Honorary feature, as a thank you to Jepeal for helping debug the board It will give you more bassy sound, by attenuating higher frequenciess somewhatGenerally the sound is good without the jumper, but if you have typical 90s crappy pc speakers, and the sound is too treble, put the jumper on.--> just try it

yeah, I will add description of the button and jumper to my webshop page,

This has me curious. Can you try the attached detection tool I wrote and post what it reports? It would be interesting to compare the results from machines on which the device works, too, if anyone is willing to try. It might be a good idea to unplug any parallel port devices first, or better yet, try both with and without your usual devices plugged in.

EDIT: EPP detection isn't perfect, but it seems to work well enough for now.

EDIT 2: Attachment removed; a more reliable version will be available in a future post.

Last edited by 640K!enough on 2017-12-02 @ 04:44, edited 1 time in total.

I can claim to have this device working on a PS/2 L40SX laptop. I got it working, compared playing Keen4E with TSR loaded (slideshow, as expected) against patching it with adpatch 0.4 (playable speed without sound emulation slowdown).

Sadly I cannot do any more tests on that PS/2 at the moment since it started acting up strangely after testing out the OPL2LPT.Some ports were working, then not working (serial), then working again.... Also PS/2 port stopped working completely...

I opened it and noticed that the electrolytic caps were starting to leak. I took them all out, going to replace all 14 of them. Really hoping that the weird acting up and sporadic drop out of ports will vanish with new capacitors in place and nothing is damaged permanently.

Since you're the developer of the TSR, would it be correct to assume that the device works consistently on your hardware? I will need to add a few more lines to the ECP routines and fix the EPP detection, but I suspect that the problems are related to the type of parallel port on a given system. I have been having similar problems with one of my own parallel port devices, so I am already working at finding a solution.

In my case, the symptom is sporadic data corruption, which could explain why some users of the OPL2 device get mostly noise. I'm still testing, but will be back with a new version of the detection tool soon.

Yes, the OPL2LPT works reliable for me. I test on a Cyrix MediaGXm-based system.

The parallel port can be set up in different modes in the BIOS. This doesn't seem to have any effect for the OPL2LPT, it works fine in all modes.- SPP (LPTDTECT detects this as "standard (output-only)")- EPP 1.7 (detected as "bi-directional")- EPP 1.9 (detected as "bi-directional")- ECP (detected as "ECP")- ECP+EPP (detected as "ECP")

So far I think SteveC's PS/2 P70 is the only machine where it doesn't work at all. Did I perhaps miss a report?

I find it interesting that there can be so much variation in parallel port behaviour from one machine to the next. I have attached a newer version of the detection tool. On my machine, it correctly identifies EPP mode, regardless of version. With the previous version of the tool, EPP 1.9 was identified correctly, while 1.7 was listed as "bi-directional". Curiously, your machine listed both as bi-directional, and SPP doesn't seem to be bi-directional.

In some cases, selecting a different parallel port mode can cause trouble. I have seen this with a number of hobbyist devices, as well as a few commercial products. Okidata has an old support note that recommends disabling ECP mode for some printers, if problems occur. That's why I was so curious about the capabilities of the PS/2 machines a few members have mentioned in this thread, especially since it was mentioned that they don't have the ability to change modes.

I thought there were at least two PS/2 owners who were having trouble, but perhaps I am mistaken.