dJOS wrote:

Sorry if I'm being dense but is there any benefit to non coders? Is this just for new games?

Nah, it's just for coders who are writing new games, so they can easily add support for OPL2LPT and DBS2P.

Scali wrote:

dJOS wrote:

Sorry if I'm being dense but is there any benefit to non coders? Is this just for new games?

Nah, it's just for coders who are writing new games, so they can easily add support for OPL2LPT and DBS2P.

Ah good, that's what I thought but wasn't sure. 😎

here's an article by Vincent Bernat,
on using OPL2LPT under linux :
https://vincent.bernat.im/en/blog/2018-adlib-opl2lpt

I built my OPL2LPT kit this weekend. Very solid little gadget. Nice clear instructions on what goes where. You don't always get that with projects like this. Something that surprised me was that Star Control 2 actually supports OPL2! As far as I know that game's entire soundtrack uses sampled sound, but when I started the game with the OPL2LPT device inserted with the driver loaded it played sound! Must be some hack they did. That game's sound card support never ceases to amaze me.

Volume levels were super low but quality was at least as good as my homemade covox clone.

Some games were a bit speed sensitive. The Monkey theme played incorrectly when I used the device on my K6-400 machine, but worked fine on my 386-DX 40 machine.

Also I had to make sure I had selected OPL2 in games that also support OLP3 chips. At first TIE Fighter confused me with incorrect music, but then I realised I'd set it to use OPL3. I'd never owned an OPL2 device before so I'd always just set it to OPL3.

The driver used a fair amount of CPU on my 386 - some games lagged a bit (like Flashback). Best results were on games that could be patched. Doom was almost playable in low res mode on my 386, at least not noticeably worse than when playing without sound.

AnacreonZA, you might not have the latest version of the TSR. It should say "Patching enabled" when you load it. Download it here: https://github.com/pdewacht/adlipt/releases/
If you do have the latest version, I'll take a look at what Flashback is doing. I hoped I had eliminated the slowdowns on 386 machines.
Also, thanks for the note about TIE Fighter. I was looking for games that allowed one to configure OPL3 without digital audio but couldn't find any. That will help with testing OPL3LPT 😀

pdw wrote:

I was looking for games that allowed one to configure OPL3 without digital audio but couldn't find any.

I believe also Nascar Racing (and possibly SimCity 2000) offers the option to have OPL3 music, and allow you to select a different device for digital sounds.

Descent and the Doom MBF port comes to my mind.

Would it be possible to make your program reroute port 388 to something other than a LTP port, pdw? It would be useful for CMI8x38 based sound cards behind a PCI to PCIe bridge. The FM synth can also be found on the cards PCI port range, just add 50h to the base address.

Beegle wrote:

I believe also Nascar Racing (and possibly SimCity 2000) offers the option to have OPL3 music, and allow you to select a different device for digital sounds.

SimCity 2000 uses the Miles Audio system for sound drivers. You can independently select the SFX and music devices.

While working on my emulation utility in assembly, I discovered a minor bug in ADLiPT, if a port range is already mapped via EMM386 IOV (maybe even twice!):

1ADLiPT 0.6  github.com/pdewacht/adlipt
2
3You have an EMM386 version I don't know about: version 4.95
4Please report your experiences.
5
6Error: no supported memory manager found
7Requires EMM386 4.46+, QEMM 7.03+ or JEMM

It reuses generic error message when virtualization call fails.
Additionally, EMM386 4.95 is the typical EMM386 used with windows 9X DOS7. No problem encountered with it by me so far, so the warning can probably be removed.

BTW, I made the tool requested by Kamerat, soon to be released.

Odd. I've been attempting to figure out how to create a version of SoftMPU to use the JEMM (FreeDOS memory manager) for years now.

bjwil1991 wrote:

Odd. I've been attempting to figure out how to create a version of SoftMPU to use the JEMM (FreeDOS memory manager) for years now.

I only use EMM386 in my app for now, but the code for JEMM seem to be present in the ADLiPT utility.

bjwil1991 wrote:

Odd. I've been attempting to figure out how to create a version of SoftMPU to use the JEMM (FreeDOS memory manager) for years now.

My impression is that OpenWatcom makes it easier to write this sort of code than the MSVC/MASM combination used by SoftMPU.
OpenWatcom makes it easy to put code into specific segments, so creating resident code is very easy. Creating 32-bit code segments is also simple.

So perhaps it would be interesting to port SoftMPU to OpenWatcom?
Then you should be able to pretty much copy the JEMM code from Adlipt.

I also based my SoftIMFC on Adlipt instead of SoftMPU for that reason (but didn't bother to add JEMM support yet).

Scali wrote:

I also based my SoftIMFC on Adlipt instead of SoftMPU for that reason (but didn't bother to add JEMM support yet).

My stuff is in assembly (TASM), did not actually remember SoftMPU is asm too. Easier to add asm than rewrite to C, I believe.
I'm just too lazy to set up environment with JEMM.

noop wrote:

My stuff is in assembly (TASM), did not actually remember SoftMPU is asm too. Easier to add asm than rewrite to C, I believe.
I'm just too lazy to set up environment with JEMM.

SoftMPU is only part ASM. The code it borrowed from DOSBox (the main MPU-401 emulation) is in C.
It's the connection between the ASM and the C that's quite complicated.
This could be done simpler with OpenWatcom, I believe (you can still link TASM/MASM code to it, it comes with its own WASM which is also somewhat MASM-compatible, and there's inline asm support).

noop, thanks for the bug report.

Dealing with JEMM is not that bad. The first thing to know is that JEMM's JLM modules are ordinary 32-bit Windows DLLs. You can use any tools you like, as long as they can produce a Win32 DLL.

The big annoyance is that JEMM's internal API is almost entirely undocumented. There's some sample code and it mimics the internal Windows 95 DDK API, so you can sort of figure it out, but it's difficult. It doesn't help that the published source code is incomplete.

For a project like SoftMPU, with lots of 16-bit assembly, it's probably possible to have a small 32-bit stub that switches to 16-bit mode for all the work. But that's more complicated than anything I've done. The JEMM version of ADLiPT is pure 32-bit code 😀

I released my tool here, but it is only useful for the owners of supported soundcards.
RemapCMI - Tool for emulating DOS audio ports on C-Media CMI8x38 soundcards
Will continue working on other soundcard emulation utils.

Hello! I recently bought a kit, and I just put it together tonight. However I ran into an issue where I misread the values on the resistors. Resistor 7 I believe. I tried to remove it but ended up losing a solder pad on the bottom. I attempted to transplant it by using the top of the board.

I mention this as I'm not sure if I did anything else wrong, as when I powered it on through USB (one attempt with another pc, another with a power brick and another with a monitor), I get various levels of noise without a successful test of its output on a 486 machine I have (though it is detected and the device itself powers on of course).

One curious thing that I found though is that if I apply pressure to the volume knob I can hear radio interference. The more pressure the better I can hear the interference (the static noise changes as well). Does anyone have an idea on what I did wrong? I can send pictures or a video upload if that would help.

EDIT: I should also state that the headphone jack I got only had five legs (missing one of the middle ones), I haven't seen a good closeup of this part in a video but it looked like in the picture that it had six legs, could this also be an issue? Is this something that I could easily fix?

EDIT 2: Upon more testing I think its not actually the volume knob but the two chips next to it, as I think I was applying pressure on them as well. If I just put pressure on them and not the volume knob then whatever it is picking up becomes a bit clear. Did I somehow put them in the wrong way?

Onyx Jaguar wrote:

EDIT 2: Upon more testing I think its not actually the volume knob but the two chips next to it, as I think I was applying pressure on them as well. If I just put pressure on them and not the volume knob then whatever it is picking up becomes a bit clear. Did I somehow put them in the wrong way?

Opamps are known to pick up a lot of noise if you touch them. This is normal. Also, the quality of your power supply is important and if your PC is properly grounded, etc.

Cool! I have a bunch of different power supply, well things I can use in order to test. I'll have to investigate those further to see what does what so to speak.

In case you are still stuck, I'll try to help with troubleshooting

Onyx Jaguar wrote:

Resistor 7 I believe. I tried to remove it but ended up losing a solder pad on the bottom. I attempted to transplant it by using the top of the board.

I don't get what is meant by "transplant". If no traces going to the pad, ignore it, because it is connected to the pad on the opposite side anyway. If there was a trace going to the missing pad, then carefully remove the insulation from the end of that trace with a small knife, until shiny copper is visible, add a drop of flux there and connect it with solder to the leg of your resistor.

Onyx Jaguar wrote:

I get various levels of noise without a successful test of its output on a 486 machine I have (though it is detected and the device itself powers on of course).

It is normal for this device to produce strange noises until initialized. Reset button may help.
I must say one important thing though. OPL2LPT utilities DON'T DETECT OPL2LPT. Detection is unfortunately not possible for this particular device. They only detect the presence of an LPT port. You can easily check that by disconnecting OPL2LPT. Utils will still work as before.
It is best if you confugure your LPT port to "Standard" or "Normal" or "SPP" mode in BIOS, just in case.
After running Adlib emulation with ADLiPT, I typically use this demo to test FM music: http://www.pouet.net/prod.php?which=67319

Onyx Jaguar wrote:

One curious thing that I found though is that if I apply pressure to the volume knob I can hear radio interference.

It is normal to hear noises when putting a finger near amplifier ICs

Onyx Jaguar wrote:

I can send pictures or a video upload if that would help.

This would probably help.

Onyx Jaguar wrote:

EDIT: I should also state that the headphone jack I got only had five legs (missing one of the middle ones)

Normal, same on mine. No need to fix anything, just solder the 5 legs properly.

You may want to read my previous posts in this thread (1 of 2 chips was either DOA or failed while I was soldering and testing):
OPL2LPT