Roland MT-32 problems with BB 1.1

[Duplode]

A different MT-32 issue: under my default setup of vanilla DOSBox + external Munt, MT-32 sound in the 1990 4D version stops working very often (for instance, upon entering the evaluation screen). The MT15.DRV replacement trick is of no use in this case, as 1990 4D and 1990 Stunts use the same MT15.DRV, as llm had pointed out several messages ago.

[llm]

im currently working on a basis to port the DRVs to Watcom C/C++ while keeping the result Stunts compatible

maybe someone is interested in helping to port the few lines of asm to C/C++
that way it would be much easier to find bugs and fix them - these drivers are not touched by the re-stunts project so far

[Cas]

I might try to help, although I've never used Watcom C... I had Borland C (C++) 3.1. I don't know how different they could be. Anyway, I remember having taken a look at the contents of one of these DRV files and it looked like it had originally been written in pure assembly. If I remember well, they begin with a set of pointers to jump to the different functions. Not sure how to write that as pure C, since the compiler will put the code wherever it pleases, but the contents of the functions themselves might be translatable. There surely are lots of OUT instructions there, so even the C code would require some commenting to be understood (i.e.: what each OPL2 register is for, for example). How have you been working on it so far?

[llm]

I might try to help, although I've never used Watcom C... I had Borland C (C++) 3.1. I don't know how different they could be.

1. Watcom runs on 64 bit Windows/Linux
2. Watcom can place Variables in Code-Segment (needed for replicating the original behavior of the drivers)
3. no real differences in C/C++ style - or better said: the drives are not that Language power demanding

Anyway, I remember having taken a look at the contents of one of these DRV files and it looked like it had originally been written in pure assembly. If I remember well, they begin with a set of pointers to jump to the different functions.

i also think it was build using asm
as you can see on the first page of this Thread i've already reversed (not perfect, but working) the MT15.DRV completely + assembling back to original
there are some quirks like registers based function parameter etc. but overall very much readable/doable

Not sure how to write that as pure C, since the compiler will put the code wherever it pleases

not 100% true - there is still a linker or special features of the compilers that can do magical things
but i want the magic on a bare minimum level so i've made a small assembler stub for the jump table that gets linked with C code - so its possible to replace every function step by step - while doing tests

what i like to do:
1. cleanly (re-)reverse the MT15.DRV driver versions (stunts 1.0, 1.1, other versions(4D Boxing?)...) - would be nice if someone collect all versions available
2. combine the version differences with IFDEF in one single MT15.drv.asm (only some lines of code)
3. put up a github repo with full build able original asm + new asm_stub+C code (repo name: restunts_drv)
4. port the asm mostly/completely to C
5. port the other DRVs - AD15, PC15, SDB15, TD15... the same way

[Cas]

I normally use Stunts version from BB 1.1, the one most people have here, but I do have a copy of BB 1.0, the first one I got. However, the SB driver in that version, I overwrote long ago with that from Fight, because it was acting up, so I no longer have the original. I do have the original drivers for other sound devices, though and I can share them with you. I don't have any other version.

I didn't know that Watcom C was still being used for modern systems. In the GNU platform, having GCC incorporated as part of the system itself, there isn't much point in installing another C, but it's nice to see that Watcom is still moving forward.

When I looked at the DRV files years ago, I noticed that they were pretty straightforward, but I didn't keep on trying to disassemble them because I figured that anyway, modern systems were going to use an emulator for DOS. Maybe for Windows users, it could make some sense so they can run Stunts natively (I don't know if that's still possible), but in GNU, emulation will still be required. It is, however, very interesting to be able to see the original code there. I was most interested back then in analysing the structure of these drivers so as to be able to produce new drivers that could output sound via other systems (such as a simple DAC on LPT1). This may or may not allow, I don't know, to have Stunts actually save the sound output to a file and have another process read the file on the fly and produce sound natively while Stunts runs in DOSBox. I don't know if DOSBox has any other interface that would allow to push the data out of the emulator... Perhaps, we could use IPX emulation for that purpose.

[llm]

I normally use Stunts version from BB 1.1, the one most people have here, but I do have a copy of BB 1.0, the first one I got. However, the SB driver in that version, I overwrote long ago with that from Fight, because it was acting up, so I no longer have the original. I do have the original drivers for other sound devices, though and I can share them with you. I don't have any other version.

it seems that there are only 2 versions - it've got them - and they are also already reversed and re-assembled to binary equal versions
will push my git-repo soon

I didn't know that Watcom C was still being used for modern systems. In the GNU platform, having GCC incorporated as part of the system itself, there isn't much point in installing another C, but it's nice to see that Watcom is still moving forward.

its still the good old Watcom which was used for DOOM - still able to produce code down to 8086 but ported to Windows/Linux (and DOS) very active community working on the compiler (and with the compiler)

[Cas]

I have just read it now has a free software license, apparently. That's good!

[llm]

A different MT-32 issue: under my default setup of vanilla DOSBox + external Munt, MT-32 sound in the 1990 4D version stops working very often (for instance, upon entering the evaluation screen). The MT15.DRV replacement trick is of no use in this case, as 1990 4D and 1990 Stunts use the same MT15.DRV, as llm had pointed out several messages ago.

did you try dosbox-staging: https://github.com/dosbox-staging/dosbox-staging, they integrated the libmt32emu directly and fixed some bugs/problems

[llm]

can someone explain what is needed to the MT32 emulation in dosbox running
(i've got an source build of vanilla-dosbox and dosbox-staging ready)

i need to debug into the driver loading to understand the meaning of 4 bytes (search for "unknown 4 bytes" in the attached asm) could be that these byte are just unused

[GTAMan18]

The vanilla DOSBox doesn't have the MT32 drivers integrated, but DOSBox-ECE does

[Duplode]

can someone explain what is needed to the MT32 emulation in dosbox running

For vanilla DOSBox, add this midi section in dosbox.conf:

Code: [Select]

[midi]
mpu401=intelligent
midiconfig=128:0
Then install Munt, configure it with the MT-32 roms (see e.g. Ryoma's earlier post) and have it running before starting DOSBox.

[Cas]

Vanilla DOSBox can't turn MIDI data into sound, but it can redirect MIDI output data from games to an actual MIDI input in your system. What you need to produce MIDI-based music is, as Duplode described for the configuration, set up a MIDI route, somewhere for DOSBox to put the data in, and then make sure you have something there. It can be a MIDI mapper program, such as TiMIDIty++. I'm not familiar with Munt, but I guess it must be something similar. But it can also be an actual MIDI interface. For example, if you have a General MIDI compatible keyboard, you could plug it in your computer and use that. In other words, for what concerns DOSBox, this isn't anything related to music. It's just data routing.

[llm]

btw: attached is a zip with all driver integrated game exes (game_(ad|pc|mt|td).exe) - based on the MCGA exe - seem to work without flaws - maybe someone wants to test them more in depth

[llm]

Vanilla DOSBox can't turn MIDI data into sound

but using the MT15.drv with vanilla dosbox sounds different than Adlib, Tandy or PC-Sound - so it seems that there is some sort of emulation going (im not using the offical releases of dosbox only self source builds of svn)

[GTAMan18]

Vanilla DOSBox can't turn MIDI data into sound

but using the MT15.drv with vanilla dosbox sounds different than Adlib, Tandy or PC-Sound

OFF:
You don't say
ON:
Always will sound different, because MT15.DRV (The driver of Roland MT-32) makes the game sounds/music play on Roland MT-32, even with MUNT emulation. Without MUNT, different also than with it. Without using MUNT, car sounds will be gone after a few seconds, and skidding will sound like hitting a key on a piano