was Roland UM-1X midi interface working properly with any other midi module with dosbox?

robertmo wrote:

was Roland UM-1X midi interface working properly with any other midi module with dosbox?

That had occurred to me, and I forgot to put my original observations in the first post. My Roland UM-1X has been a rock-solid MIDI interface. It has worked perfectly with all my Roland LA devices, including the MT-32 and CM-32L, all my GM/GS/XG MIDI modules, including a Roland SC-55 and Yamaha MU10XG, whether in Windows XP or 7. It will transmit MT-32 midi files with embedded sysex and also sysex dumps using a program like MIDIEX.

My memory may be a bit hazy here, but as I recall, I once tried using DOSBox in a Win9x machine some years ago when I still had the IBM Music Feature Card. The motherboard had two ISA slots, and for the MIDI interface I was using my Roland MPU-401 + MIF-IPC-A. Win9x will recognize this ancient hardware and the interface will work without an issue even on a Pentium III machine. I believe I connected the midi out on the Roland MPU-401 to the midi in on the breakout box of the IBM Music Feature Card, which may or may not have been in the same system. I further believe I tried using the FB-01 driver natively and through DOSBox, with the former working and the latter failing.

In short, I do not believe that my USB midi interface is the issue, especially as MT-32 sysex works like a charm.

Seems like the problem has been discussed previously:
IBM Music Feature Card/Yamaha FB-01

Increasing the size of the SysEx buffer in DOSBox from 1024 bytes to something large enough to hold the 6222 byte SysEx messages used by the Sierra FB-01 drivers appears to be a significant part of fixing the problem.

In the linked thread there is a mention that the first 6222 byte SysEx message isn't always reliably received. When starting the first large message, the Sierra FB-01 driver transmits two sequential 0xF0 bytes, which results in DOSBox sending an invalid 2-byte SysEx message (0xF0 0xF7) ahead of the large message. I don't know if the host will actually send it or not, but it's possible that the invalid message could be problematic for the host or the FB-01. Perhaps dropping undersized SysEx messages will improve the reliability of that first 6222 byte SysEx message.

So it has, I completely forgot about the issue. A real MPU-401 has a 2Kx8 SRAM with the highest address line unconnected, leaving only 1K for the microcontroller. I assume that functions as the buffer for everything.

Cloud's really old modified DOSBox still works, but its version .72. Could there be a setting added to increase the midi buffer from 1024 to 8192 be added so the problem could partially disappear?

AFAICT the buffering is an aspect of MIDI handling, not MPU401 emulation. Messages are buffered and given to the host interface in their entirety.

A setting would be a conservative approach, but why not simply increase the fixed buffer size? I suppose there could be host limitations or other reasons; but it seems more likely that the current buffer size is just a practical limit based on typical game requirements.

I'm curious if ignoring the duplicate SysEx start byte (thus preventing the additional and invalid SysEx message) will help in this case. The attached Win32 build of current source has an 8K SysEx buffer and a condition to ignore the repeated start byte. Please try it with your FB-01 to see if the initial transfer errors persist.

I'm curious if ignoring the duplicate SysEx start byte (thus preventing the additional and invalid SysEx message) will help in this case. The attached Win32 build of current source has an 8K SysEx buffer and a condition to ignore the repeated start byte. Please try it with your FB-01 to see if the initial transfer errors persist.

I definitely notice an improvement. When I first start this DOSBox, then a Sierra game, I get a dump/error !!! followed by a dump/received !! as the game loads. The next time I load that game, or any other Sierra game, I only get dump/received !! I am not certain whether the result has changed from Cloud's build.

That initial error was what I thought might be cured, but apparently it is not. Does the music sound right despite the error, or only on subsequent runs when you don't get the error? Do you have to restart DOSBox to avoid the error on subsequent runs, or just run the game again in the same session? Does delaysysex help?

I am guessing that the first of the 6222 byte SysEx messages is getting the error, but I can't be certain. It's strange that a subsequent run does not show the same error. I added log messages to record the MIDI streams of two successive runs of SQ3 (with FB01.DRV from Laura Bow), and the streams are identical.

I've read that some MIDI devices are not only sensitive to delays between SysEx transfers, but also to the rate of transfer. DOSBox gives complete messages to the host, and I don't think it has a way to slow down the transfer. It's probably not significant in ordinary cases, but there are 6K messages in this case.

ripsaw8080 wrote:

That initial error was what I thought might be cured, but apparently it is not. Does the music sound right despite the error, or only on subsequent runs when you don't get the error? Do you have to restart DOSBox to avoid the error on subsequent runs, or just run the game again in the same session? Does delaysysex help?

The music seems to sound the same whether I get a dump error/received message or just a dump received message, but I have not made a rigorous examination. I do not have to restart DOSBox, just quit the game and restart it. Delaysysex does not help, it only introduces artifacts into the sound.

Sending a part of the sysex could be possible (and help here in combination with low cpu cycles?), according to the (googled)
http://www.oktopus.hu/imgs/MANAGED/Hangtechni … ecification.pdf, Page 330, "multiclient drivers".

Could be done like:

1
2#define SYSEX_SIZE 64
3
4//...
5if (!(data&0x80)) {
6  if (midi.sysex.used>=(SYSEX_SIZE-1))
7  {
8    midi.handler->PlaySysex(midi.sysex.buf,midi.sysex.used);
9    midi.sysex.used=0;//maybe 1
10  }
11  midi.sysex.buf[midi.sysex.used++]=data;
12  return;
13}

edit: unlikely to work on alsa output which requires start and end sysex bytes in output buffer.

this is alot of the reasons why i created my site oldschooldaw.com in the first place. because modern day midi over usb is not capable of the same level of performance the old serial interfaces were... not to mention even the intellgient uart that was originally part of the mpu design. modern day 'midi over usb' seems to not be capable of transmitting sysex properly.. due to the packeted nature of usb as opposed to the continuous stream of an oldschool intelligent serial UART. in my opinion the entire music industry (and computer MIDI in general regardless of platform, mac vs pc vs ? )was dealt a blow it still hasnt fully recovered from when the industry forced the obsolesence of serial midi in favour of usb around 1999.

its about flow control + the resulting malformed code/syntax. ..
in order to dissect this problem further u would have to find some wayto capture the midi data and visualize it + compare it visually
the result i think u would find is just slightly retarded/garbled in comparison to the original... much like mistyping a dos command theres little room for error with these types of system exclusive commands.

is there any way u could re-try this experiment removing the USB from the picture..?
id be very interested to confirm that the culprit is the USB midi interface (the fact that its USB.. not the particular brand/make/model) that is causing the errors.. but its very possible that dosbox is the root of the problem aswell.

ripsaw8080 wrote:

I am guessing that the first of the 6222 byte SysEx messages is getting the error, but I can't be certain. It's strange that a subsequent run does not show the same error. I added log messages to record the MIDI streams of two successive runs of SQ3 (with FB01.DRV from Laura Bow), and the streams are identical..

ok now perhaps this is more related to timing..
the difference between a
continuous steady stream.. 1-0-1-0-1-0-1-0-1-0-1-0
vs a packeted stream 1-0-1-0-----1-0-1-0-----1-0-1-0
if u catch my drift.. the usb transmits the data in small groups of packets.
the result is the same but the handshaking + timing .. not so much..

It's a bug in the FB-01 driver: *START HERE* SoftMPU 1.91 - Software Intelligent MPU-401 Emulator

However, one still needs a patch for DOSBox to handle the large SYSEX messages.