Thanks, Cloudschatze!

Btw: comparing SER38400.COM and SER31250.COM, noticed that at the beginning of the latter, we are setting the low bit of port FFEBh to 1. What's the purpose ?

sunmax wrote on 2021-08-12, 04:50:

Btw: comparing SER38400.COM and SER31250.COM, noticed that at the beginning of the latter, we are setting the low bit of port FFEBh to 1. What's the purpose ?

SER31250.COM was created specifically for use with the PSSJ chipset found in later Tandy 1000 systems. In retrospect, I should have named it "TDY31250.COM" or "TAN31250.COM." I can't edit or update the VCFed post, unfortunately, but will appropriately rename the file if I ever get around to making a consolidated thread of serial drivers/resources on this forum.

In any event, and specific to the Tandy PSSJ chipset, flipping bit 0 at port FFEB negates the default division of the UART clock, and permits the setting of a MIDI-compatible 31250bps rate. This then allows for direct MIDI output from the serial port through the use of a simple current-loop adapter, or connectivity to an RS-232-capable module set to the "PC-1" or 31250 bps rate.

Concerning Western computers, and in addition to the Tandy PSSJ example, several SMC chipsets can also be configured to operate at the standard MIDI rate. I created a "SMC31250.COM" utility for the latter, if there's any interest in that.

Thanks cloudschatze.. i will make a special "CloudSchatze" edition of my phil n chil adapter and send you one for testing 😀

@Cloudschatze First of all, thanks for the amazing work on all these patches! 😃

Not to burden you with extra work, but would it be practical for you to write and maintain these MPU-232 patches in source form on GitHub in the form of something similar to the patches based on the Ragel syntax, as used by ADPATCH (to patch Adlib and Sound Blaster games with OPL2LPT/OPL3LPT support)? This is what I'm referring to: https://github.com/pdewacht/adlipt/wiki/Makin … ADPATCH-patches

(Perhaps someone knows something even better than Ragel. If so, please chime in!)

This way, the patches could be maintained in a central location and improved and extended further by the community, as opposed to mostly just you working on them alone.

Also, this way perhaps the patches could be made more flexible in terms of hardware support, rather than just being hard-coded for (legacy) COM1. For instance, if the patches could be applied with a selectable I/O address, they could perhaps be made to work with PCIe RS-232 cards on more modern legacy-free PCs (that still have a CSM to boot DOS) as well.

I hope this suggestion is useful. 🙂

dreamblaster wrote on 2021-08-14, 12:40:

Thanks cloudschatze.. i will make a special "CloudSchatze" edition of my phil n chil adapter and send you one for testing 😀

Nice! I can only guess as to what that might be... 😀

digger wrote on 2021-08-14, 13:47:

I hope this suggestion is useful. 🙂

This is exactly what I'd like to see happen. I need to become familiar with Ragel though, and also reach out to Peter to see if he'd be okay with the creation of an "MPUPATCH" variant based on his work.

Until then, however, I'm happy to look into and directly share anything that might be of interest. With that in mind, attached are the patched routines for Descent 1 and 2 (HMIMDRV.386), and Duke Nukem 3D v1.3D (DUKE3D.EXE - Apogee Sound System).

Similar to the DMX-based stuff, the serial port address isn't actually hard-coded here, and is instead specified in the respective .CFG file for each game.

COM1, for example, is specified as follows (and where the appropriate data rate of the serial port has been configured prior to starting the game):

DESCENT.CFG
-----------
MidiPort=0x3f8

DUKE3D.CFG
----------
MidiPort = 0x3f8

@Cloudschatze Feel free to build on ADPATCH/S2PPATCH. I've added a standard open source license to the Git repo to make that explicit. But yeah, the build system is a bit complicated, it takes a lot of steps to go from the pattern files to C code.

The "making ADPATCH patches" page actually describes my original approach. The idea was to have bits of assembly code in the pattern files (e.g. wackywheels.yaml). These are assembled with NASM, and the resulting machine code was turned into Ragel patterns. This ended up not working very well for two reasons. The first is that assembly turns out not to be a very good representation of machine code. I often encountered something that couldn't easilly be expressed in NASM syntax. For example, the instruction "mov al, cl" can be encoded either as 8A/C1 or as 88/C8. NASM always generates the former, Wacky Wheels uses the latter (oops). The second problem is that this system allows no good way to deal with minor variations. (For example, a company's second game reuses the sound code from their first, but it's compiled with a newer version of the compiler, which emits slightly different code.) I had a few gross hacks to try to deal with this, but it was awkward and inflexible.

So for later patches I started using Ragel directly. In principle you could just transcribe the bytes to patch as a hex dump, but to keep it a bit readable, I made a big list of Ragel definitions of the x86 instructions I encountered, so you get patterns like this. This looks a bit scary, but you get used to it and it works well.

Or I should say, it works well for Adlib drivers. I haven't had much luck with MIDI drivers. Most Adlib sound drivers have one "initialize Adlib card" routine and one "send Adlib command" routine, and those are easy to identify and replace. I found MIDI drivers to be much more difficult, more I/O code and more complicated control flow. Perhaps I just had bad luck with the games I picked.

Thank-you for the excellent feedback, Peter (and sorry for the late reply!). I've been sidetracked with a few other projects, but you've provided some great direction for when I get started.

And speaking of being sidetracked, here's yet another use-case for the MPU-232...

That is glorious.

And, here's the obligatory potato-cam video, showing portions of Ultima V, Budokan, Zeliard, and Space Quest III with the 200LX.

Mini MIDI Gaming with the HP 200LX and Serdaco MPU-232...

https://youtu.be/FtOAXqwvkIU

https://www.roland.com/global/support/archive … _downloads_n-s/

It works also with Windows 95/98/ME Driver and also on XP/2003 with Roland Serial Out Driver.

Cloudschatze wrote on 2021-09-28, 04:37:

And speaking of being sidetracked, here's yet another use-case for the MPU-232...

Hi Cloudschatze and Happy New Year!

Spent some time over the holidays to test these cool patched games with the MPU-232 😀

I've been testing on a somewhat peculiar setup, Amiga + Goldengate 486, which assigns the Amiga serial to the internal PC (as COM1).

I'm using a DB25 to DB9 cable adapter to connect the MPU-232, and with SoftMPU and the original binaries, the MIDI music comes to life on MT32 😀

Now, when I try the patched games, I first set COM1 to 38400 with SER38400 (or first load SOFTMPU /MPU:330 /OUTPUT:COM1 to get the same effect), but when I start the games alas get no music. The led on MT32 is not blinking either, so seems is receiving no data.

The way SoftMPU configures and sends data over serial is working, so think we should be able to do directly to serial on this particular machine too.

Is there something specific we might need when using a DB 25 serial adapter ?

Or maybe the way serial status is reported ?

If can be helpful, I volunteer to run tests and peek/poke serial ports registers.

Would be great to find a solution to work on more systems.

Thanks for your help!
-max

Ok.

Part of the mystery solved, looking at the insightful output of SoftMPU!

SOFTMPU /MPU:330 /OUTPUT:COM1

-> Serial interface detected at port 2F8 (!)

There appears to be some unexpected behavior in the Goldengate BIOS, when configured as:

COM1 -> Amiga RS232 (MIDI adapter)
COM2 -> Amiga Mouse

-> reports the Amiga RS232 at 2F8 (DOS COM2), when querying for COM1

When configured as:

COM1 -> Amiga Mouse
COM2 -> Amiga RS232 (MIDI adapter)

-> reports COM1/COM2 correctly as 3F8/2F8 - but in this case COM1 cannot be used as it is internally bound to the Amiga mouse

Long story short, on Amiga + Goldengate, even when we set the BIOS to reserve COM1 for Amiga RS232, we must use 2F8 as port address to access it.

The logic is inverted, but easy to fix 😀

With Cloudschazte blessing, happy to reconfigure a set of patches (or new binaries) to use COM2 to cover this scenario (i.e. COM1 not available).

Only one question left:

- why do we need 2 serial to MIDI adapters ?

1) when running games from the Amiga that use MIDI (SQ3DE via whdload and SQ3DE, or SQ4 with scummvm) we need to use an Amiga cable adapter (KA12 serial MIDI interface), as the MPU-232 doesn't appear to work (tried all switch permutations)

2) when running games from the Goldengate PC inside the Amiga, the Amiga adapter no longer works, and we need to switch and plug the MPU-232 into serial to get MIDI music from the PC games

What's the catch ? Byte ordering ?

Thanks for your help!
-max

I made a video on the MPU-232. Check it out. It i did not know about this group when making the video. So there a a few things i could have added.
https://youtu.be/plrvtbWcdiI

sunmax wrote on 2022-01-02, 06:34:

With Cloudschazte blessing, happy to reconfigure a set of patches (or new binaries) to use COM2 to cover this scenario (i.e. COM1 not available).

I haven't gotten around to adapting "adpatch" for this purpose, so have at anything you'd like. For manual COM1 > COM2 changes, you'll want to replace any instances of "F8 03" with "F8 02", and "FD 03" with "FD 02".

I yet need to go through some of the older driver modifications I'd made, and properly bypass the command routines, but they'll all work with the MPU-232 as-is.

What's the catch ? Byte ordering ?

I have no experience with Amiga hardware, but it looks like applicable Amiga games drive the serial port at a MIDI-compatible 31250 bps rate for use with the KA12, which is unsupported by the MPU-232 (for obvious reasons), and for which a "passthrough" setting doesn't exist. I don't know how the Amiga and Goldengate sides share the serial port, but if the 31250 rate can be set and used by the latter, you effectively don't even need the MPU-232.

If the Goldengate side inherits the serial rate set by the Amiga side by default, try manually setting that to 31250 bps, and then attempt to start a game with one of my patched drivers (that you've subsequently patched for COM2). If that works, SoftMPU can be changed similarly, to either modify or defeat its configuration of the serial port baud rate.

Jinxter wrote on 2022-01-03, 21:38:

I made a video on the MPU-232. Check it out. It i did not know about this group when making the video. So there a a few things i could have added.

I think it's important to note that SoftMPU isn't a hard requirement for use of the MPU-232. Software/drivers that already support serial-port MIDI output, or that have been patched to do so, work with it just fine.

Cloudschatze wrote on 2022-01-03, 22:36:

Jinxter wrote on 2022-01-03, 21:38:

I made a video on the MPU-232. Check it out. It i did not know about this group when making the video. So there a a few things i could have added.

I think it's important to note that SoftMPU isn't a hard requirement for use of the MPU-232. Software/drivers that already support serial-port MIDI output, or that have been patched to do so, work with it just fine.

Yes i know now. As mentioned i did not know about this group when making the video.
I will probably make a new video where other uses of the MPU-232 is investigated. I would be grateful for any inputs/suggestions you might have.

I am trying to summarise what I know about the MPU-232 (or similar devices)
- SoftMPU enables MIDI for these devices for 386+ machines
- There are patches for these games: - But why patches for games that needs an 386+ anyway?
CHEX.EXE 713,017 Chex Quest 1/2
DOOM.EXE 715,493 The Ultimate Doom
DOOM2.EXE 709,905 Doom v1.9 and Doom II
HERETIC.EXE 728,031 Heretic v1.2
HEXEN.EXE 923,019 Hexen v1.1
RAP.EXE 474,359 Raptor v1.2
STRIFE1.EXE 753,215 Strife v1.31
- Roland has some Windows drivers for Windows 95/98/ME. and Windows 2000/XP.
- Cloudschatze has made patches for several games. Many of them will run on 8088/286 machines. The patches are found here: https://www.vcfed.org/forum/forum/genres/tand … -the-tandy-pssj Is there one file containing all patches? - I see "digger" suggest using Github?
- SER38400.COM is used to configure the Comport on machines not using SoftMPU. Must be used for the patched games to work?

I hope you see, i am not trying to create work for you guys. Just trying to make what you have made more accessible, and to tell the world about it. So please bear with me.

Jinxter wrote on 2022-01-03, 23:21:

- There are patches for these games: - But why patches for games that needs an 386+ anyway?

Outside of AIL/MSS usage, SoftMPU isn't compatible with most protected-mode titles, hence the need for the additional modified drivers or executables. Concerning such titles, and in addition to the DMX stuff, modified routines are also available for Ultima VII, VIII, Duke Nukem 3D, and some HMI-based games within this same thread.

- Roland has some Windows drivers for Windows 95/98/ME. and Windows 2000/XP.

I'd actually suggest the use of Yamaha's serial MIDI driver for use with the MPU-232, simply because the behavior of the MPU-232 is closer to Yamaha's implementation than Roland's.

- Cloudschatze has made patches for several games. Many of them will run on 8088/286 machines. The patches are found here: https://www.vcfed.org/forum/forum/genres/tand … -the-tandy-pssj Is there one file containing all patches? - I see "digger" suggest using Github?

No, I haven't gotten around to either consolidating distribution, or working on a patching solution.

- SER38400.COM is used to configure the Comport on machines not using SoftMPU. Must be used for the patched games to work?

As concerns "standard" serial port rates and usage, and any of the routines that I've modified, yes. The modifications themselves are not rate-specific, however; it's really just a matter of matching the serial port rate to that of the target intermediary device. For most serial port usage scenarios involving the MPU-232 or any of the RS-232-supporting Roland/Yamaha/Korg devices, that's going to be 38400 bps.

Hi Cloudschatze,

Thanks for your insight and guidance!

You make a good point about the Amiga serial, it's indeed clocked at 31250, so believe the Amiga MIDI adapter works as a pass-through (here are the specs: https://rastport.com/products/KA12/)

The catch we are encountering is:

- when we start the GoldenGate the PC takes over the Amiga Serial port and clock it to 2400 at boot
- using GoldenGate BIOS we can set the COM2 to 38400, 19200, etc.
- it's missing the bit available on Tandy to set serial to 31250
- Amiga hw serial supports it, but cannot be set from the DOS side

Would it be possible to set the MPU232 in "passthrough mode", so that it also work at 31250 ?

Would be great to have a single solution for all vintage platforms Serial MIDI needs 😀

Now for the COM2 patches, attached are:

- COM2B384.COM (to set COM2 at 38400)
- COM2B192.COM (to set COM2 at 19200 - this might works better on Amiga with slower CPU, and MPU232 supports it)

- Indy4 @ 2F8
- Monkey1 @ 2F8
- Sierra (SQ4) @ 2F8

(based on yours)

Also created from scratch:

- Loom @ 2F8

This is for Loom EGA with MT32 patch, so now we can enjoy the Overture via serial MIDI!

Btw: noticed that we also need to invert the logic for status, from jz to jnz (as you did in the others).

The one where I might need some more guidance is GMIDI.MSD from Sam & Max (CD Talkie).

This seems more similar to the Doom scenario, for which you also prepared a patched *.exe.

The ports need to be set (e.g. 2F8) via SETMUSE.EXE and stored in SETMUSE.INI - this is the easy part 😀

Then we still need to patch in the MSD the offset of status (+8 [2F8 -> 2Fd] vs +1 [330 -> 331]) and the logic.

But the port is not hardcoded here, its value is read from the ini.

I'm also attaching it, in case you have some ideas.

Thanks for all your help!
-max

sunmax wrote on 2022-01-10, 06:49:

Would it be possible to set the MPU232 in "passthrough mode", so that it also work at 31250 ?

I don't believe so, no, but Serge should be able to confirm this.

Would be great to have a single solution for all vintage platforms Serial MIDI needs 😀

Do you know if the MIDI-supporting Amiga games set the serial rate as part of their own routines, or does that have to be manually set to 31250 bps beforehand? If the former, it should be possible to identify and modify those routines to instead set the 38400 bps rate supported by the MPU-232. If the latter, have you tried setting the 38400 bps rate from the (Amiga side) serial control settings, and then checked to see if the Amiga titles are able to leverage the MPU-232?

Another option, in lieu of either the KA12 or MPU-232, would be to use an RS-232-supporting tone generator as the intermediary serial MIDI device - most/all of which support both 31250 and 38400 bps rates - allowing you to then just set the switch on the back to the relevant position when switching between Amiga and PC gameplay.

The one where I might need some more guidance is GMIDI.MSD from Sam & Max (CD Talkie).

Patching this driver is on my to-do list...