VOGONS


First post, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

See here for an overview of this subject :

http://queststudios.com/smf/index.php/topic,3 … 9.html#msg33189

A couple of years ago, I tried using an IBM Music Feature Card (as a MIDI hardware synthesizer, not an interface) with DOSBox. A modern system was running DOSBox and the Roland UM-1X midi interface was connected to the midi-in on the IBM Music Feature Card's breakout box, which was attached to a turned-on vintage PC with the IBM Music Feature Card inserted into an ISA slot. The resulting audio was totally wrong in any Sierra game I tried. At the time, I was unsure there was an issue with the card's settings (since it was being used in its default state), but after reviewing the Technical Reference, the card's default settings will allow data to be sent from an external midi source to the card and memory protection will be off.

Since that time I let the IBM Music Feature Card go. Yesterday I finally acquired a Yamaha FB-01. I connected it to my Tandy 1000 SX with a Roland MPU-401 + MIF-IPC-A inside, fired up all the Sierra SCI0 games and the sound was right. Afterward, I tried the FB-01 with DOSBox, connecting it to the USB based Roland UM-1X midi interface, and the sound was wrong.

The Yamaha FB-01 has a 16-character LED display which can alert the user to what is going on with the synthesizer module. Sierra's games transmit patches to the device, and after the game loads on my Tandy, the LED will read out :

dump/received !!

In DOSBox, after the game loads, the LED will read out :

dump/error !!!

The Yamaha FB-01 is set up per Sierra's instructions. First the unit is turned on, then the memory protect is turned off. If the memory protect is left on (the default setting), then after the game loads, the LED will read out :

dump/protected !

If the dump is received, then the music will play properly. If error or protected comes up, the music will be quite wrong.

So, it seems as though there is an issue with Sierra's driver's transmission of patch information over the emulated MPU-401 interface to the real Yamaha FB-01.

I have used both the official .74 and the latest SVN (9/22/11) from ykhwong and the issue is still present. Also, I used Intelligent and UART MPU-401 settings, delaysysex and cycles at 3,500, 2,500 and 1,000. The bug occurs every time.

Last edited by Great Hierophant on 2011-09-25, 22:53. Edited 1 time in total.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 1 of 12, by robertmo

User metadata
Rank l33t++
Rank
l33t++

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

Reply 2 of 12, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
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.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 3 of 12, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 4 of 12, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

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?

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 5 of 12, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 6 of 12, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

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.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 7 of 12, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 8 of 12, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
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.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 9 of 12, by Srecko

User metadata
Rank Member
Rank
Member

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:


#define SYSEX_SIZE 64

//...
if (!(data&0x80)) {
if (midi.sysex.used>=(SYSEX_SIZE-1))
{
midi.handler->PlaySysex(midi.sysex.buf,midi.sysex.used);
midi.sysex.used=0;//maybe 1
}
midi.sysex.buf[midi.sysex.used++]=data;
return;
}

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

Reply 10 of 12, by chrisNova777

User metadata
Rank Oldbie
Rank
Oldbie

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.

http://www.oldschooldaw.com | vintage PC/MAC MIDI/DAW | Asus mobo archive | Sound Modules | Vintage MIDI Interfaces
AM386DX40 | Asus VL/I-486SV2GX4 (486DX2-80) | GA586VX (p75) + r7000PCI | ABIT Be6 (pII-233) matroxG400 AGP

Reply 11 of 12, by chrisNova777

User metadata
Rank Oldbie
Rank
Oldbie
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..

http://www.oldschooldaw.com | vintage PC/MAC MIDI/DAW | Asus mobo archive | Sound Modules | Vintage MIDI Interfaces
AM386DX40 | Asus VL/I-486SV2GX4 (486DX2-80) | GA586VX (p75) + r7000PCI | ABIT Be6 (pII-233) matroxG400 AGP