dh4rm4 wrote:

eh? DOSBox works a treat with my rev00 MT32, SQ3 et al sound correct and all SYSEXes transfer correctly.

Actually, DosBox does nothing to help and only a little to hinder the output of MIDI bytes to the host operating system while in UART mode. Therefore anyone with a rev00 MT-32 Roland synth (ROM version 1.0x) will have buffer overflow or checksum errors unless the particular application, game or driver in question takes into account the need to add a time delay of approximately 40 milliseconds between SYSEXs sent to the rev00 MT-32 to allow proper function. Most game MIDI drivers for the MT-32 do not add such SYSEX delays. Of course any MT-32 with ROM revision 2.0x has no need of any time delays.

Since I don't like wasting my time solving non-existant problems I try to make sure that I have a repeatable problem that can be solved. So in keeping with that mindset, I have a test case from programs I downloaded from the QuestStudios utilities page. One is a DOS utility to DUMP any SYSEX files to the default MIDI device, named strangely enough DUMP.EXE 😁 The other is a test SYSEX file CB.SYX also from the QuestStudios MT-32 utilities page. They are both included in the attached file MT32test.ZIP below.

Anyone with a ROM version 1.0x MT-32 is welcome to try the following simple command-line test in DosBox v0.70: DUMP CB.SYX - and then check their attached MT-32 LED screen for a possible Exc. buffer overflow message to appear. I'm fairly sure it will... 😏

I hope to have my proposed MT-32 rev00 fix code fix testing completed soon so that it might be picked up in the DosBox CVS for inclusion in the next possible v0.71 DosBox release before Qbix pulls the trigger... 😳

I'll be interested to see if other rev00 MT-32 owners can duplicate the buffer overflow messages with this simple test.

dvwjr

Actually, DosBox does nothing to help and only a little to hinder the output of MIDI bytes to the host operating system while in […]
Show full quote

Actually, DosBox does nothing to help and only a little to hinder the output of MIDI bytes to the host operating system while in UART mode. Therefore anyone with a rev00 MT-32 Roland synth (ROM version 1.0x) will have buffer overflow or checksum errors unless the particular application, game or driver in question takes into account the need to add a time delay of approximately 40 milliseconds between SYSEXs sent to the rev00 MT-32 to allow proper function. Most game MIDI drivers for the MT-32 do not add such SYSEX delays. Of course any MT-32 with ROM revision 2.0x has no need of any time delays.

Since I don't like wasting my time solving non-existant problems I try to make sure that I have a repeatable problem that can be solved. So in keeping with that mindset, I have a test case from programs I downloaded from the QuestStudios utilities page. One is a DOS utility to DUMP any SYSEX files to the default MIDI device, named strangely enough DUMP.EXE The other is a test SYSEX file CB.SYX also from the QuestStudios MT-32 utilities page. They are both included in the attached file MT32test.ZIP below.

Anyone with a ROM version 1.0x MT-32 is welcome to try the following simple command-line test in DosBox v0.70: DUMP CB.SYX - and then check their attached MT-32 LED screen for a possible Exc. buffer overflow message to appear. I'm fairly sure it will...

I hope to have my proposed MT-32 rev00 fix code fix testing completed soon so that it might be picked up in the DosBox CVS for inclusion in the next possible v0.71 DosBox release before Qbix pulls the trigger...

I'll be interested to see if other rev00 MT-32 owners can duplicate the buffer overflow messages with this simple test.

I cannot make the Exec. buffer overflow message appear on my 1.07 ROM MT-32 with this test, regardless of cycles. I am using the 5/4/07 CVS.

I'll test this when I get home later today.

I recall that some linux users were having problems with our always ready to send new data implementation of the midi clients.
There might be some rude patch somewhere on this board that helped them.
Srecko once tried to implement the 32 ms waiting period inside dosbox as certain games appeared to need that. (some busy bit). But in the end it wasn't needed and all games worked without it.

Qbix wrote:

I recall that some linux users were having problems with our always ready to send new data implementation of the midi clients.
There might be some rude patch somewhere on this board that helped them.
Srecko once tried to implement the 32 ms waiting period inside dosbox as certain games appeared to need that. (some busy bit). But in the end it wasn't needed and all games worked without it.

This is not a game problem, or a host OS problem, it is rather a rev00 MT-32 Roland synth hardware problem. This revision of the MT-32 Roland synth requries a delay of approximately 40 milliseconds between SYSEX messages. The later revisions of the Roland MT-32 did not have that hardware problem. However, there were quite a few rev00 MT-32 Roland synths sold and currently available on eBay. I have a rev00 ROM version 1.07 that exhibits the SYSEX problems.

Here in this QuestStudios message thread is an example of someone using DosBox with a rev00 MT-32 synth. The problem exists and I have a potential DosBox code-fix for same that I am currently testing/revising.

dvwjr

dh4rm4 wrote:

I'll test this when I get home later today.

As you can see, I tried it and no issues whatsoever. The SYSEX for Colonel's Bequest loaded fine with "** Quest Studios **" displayed on the MT32's LCD.

dvwjr wrote:

Qbix wrote:

The problem exists and I have a potential DosBox code-fix for same that I am currently testing/revising.

dvwjr

I still am waiting for your comments. As you can see my REV 00 MT32 doesn't have the problem you describe and DOSBox doesn't produce or exacerbate the issue either.

Excuse my uninformed question, but how do you tell which ROM revision the MT-32 device has?

No headphone jack. LA32 sound generation chip is an 80-pin PGA. Control CPU is an Intel C8095-90. DAC is a Burr-Brown PCM54 without trimpot; its input signal has a resolution of 15 bits (see below).

* MT-32 with revision 0 PCB, used in units up to serial number 851399.

from http://en.wikipedia.org/wiki/MT-32

Thanks, then I have one as well (Serial 831270) 😀
I'll take a look then, too.

ok, checked, nothing bad happens, it shows the "Colonel's Bequest" and after the program ends, it just still shows ***Quest Studios***
This is with
[midi]
mpu401=intelligent
device=win32
config=3

Same behavior with mpu401=uart
Dosbox CVS from around the May 20th

Edit: works also with the Windows release of 0.70.
If I remember correctly from another thread you started about this (I might confuse you, excuse me if I am) you are using Linux. Are you sure this behavior you witness is not caused by the Operating System, SDL on your system, Sound Card/drivers or Audio System of the OS?

dh4rm4 wrote:

I still am waiting for your comments.

Sorry I could not respond with Instant Messaging speed. Three-quarters of an acre of grass demanded my personal attention... 🤣 Don't worry, I have another test to help isolate the SYSEX failure characteristic of the rev00 MT-32...

Dominus wrote:

Excuse my uninformed question, but how do you tell which ROM revision the MT-32 device has?

I learned on the QuestStudios forum that the ROM version may be determined in the following manner: With the MT-32 powered off, press and hold [PART 4] + [RHYTHM] + [MASTER VOLUME], and while holding those buttons, turn ON the power switch on the back of the unit and the ROM version and date will appear on the LED screen.

Great Hierophant wrote:

I cannot make the Exec. buffer overflow message appear on my 1.07 ROM MT-32 with this test, regardless of cycles. I am using the 5/4/07 CVS.

Thanks to all for the feed back on the rev00 MT-32. I have another set of MIDI SYSEX tests to attempt to demonstrate the failure mode of the rev00 MT-32 when handling SYSEXs. First off, there may be instances of a rev00 MT-32 not having problems in DosBox v0.70 depending on the underlying operating system and its serial/MIDI drivers and associated buffers.

Please find attached to this message the file: MT32rev0.ZIP, which contains the following files:

1.) Dump.exe
2.) Playmid.exe
3.) ROBINSYX.mid
4.) MT32rev0.bat
5.) THEX2.syx

Extract these five files to a common sub-directory called \MT32TEST for future use.

First up is a test of the rev00 MT-32 by the means of a native media player capable of playing MIDI files on the host operating system. DosBox is not used for this initial test. I will use WinXP (SP2) as the example, but of course any host OS supported by DosBox may also be tested. The initial test is to play the ROBINSYX.MID file by the Windows Media Player where the default MIDI music playback device is configured to point the rev00 MT-32 synth. This MIDI file consists of the initial MT-32 SYSEXs sent by the Sierra game "Conquests of the Longbow - The Legend of Robin Hood", but no audio.

On a Win32 system, the MIDI playback chain looks something like this GraphEdit diagram:

Now the MIDI byte buffers in Windows XP exist in the MIDI serial driver, be it of the 16550A UART, USB or MPU-401 flavor. Since the MT-32 itself does not support serial port hardware or software flow control while communicating with an MPU-401 in UART mode, the serial port speed of 31,250 bits/sec and inter-SYSEX time delays are the only way to ensure that the rev00 MT-32 has time to complete any SYSEX processing without suffering from "Exc. checksum error" or "Exc. buffer overflow" type errors.

If the MIDI file ROBINSYX.MID is played via the MT-32 and the LED screen has the words "ROBIN HOOD" when finished, then the SYSEXs were transmitted with no "Exc. buffer overflow" errors. Since DosBox has not yet been involved, any success would indicate that the host operating system and/or drivers are inserting some delays between rev00 MT-32 SYSEX messages. In this case DosBox would not demonstrate any rev00 MT-32 SYSEX problems either...

Another test of a rev00 MT-32 would be to boot to DOS and test the MT-32 by using two of the files listed above: PLAYMID.EXE to play the ROBINSYX.MID file. The program PLAYMID.EXE places any MPU-401 interface into UART mode upon startup, so that any rev00 MT-32 should have errors when playing the ROBINSYX.MID file from real DOS.

Next is the DosBox testing.

Configure DosBox such that the DosBox.conf [midi] section directs the DosBox MIDI output to the rev00 MT-32 synth. Next, mount the \MT32TEST sub-directory which contains the five files that were un-zipped. Finally, simply execute the batch file MT32rev0.BAT to conduct the test. This test will first use the PLAYMID.EXE program to play the MIDI file ROBINSYX.MID within DosBox. The purpose of this file is to send a large number of SYSEXs to the MT-32 and to place the words "ROBIN HOOD" on the MT-32 LED screen. If the words "ROBIN HOOD" do not appear, then an MT-32 rev00 error has occurred. The batch file next executes eleven times the DUMP.EXE program which sends the SYSEX message contents of the THEX2.SYX file to the MT-32. If at the end of the batch file execution, the MT-32 LED screen still has the words "ROBIN HOOD" displayed, then no errors occurred while transmitting SYSEXs to the rev00 MT-32. The purpose of sending the large number of SYSEXs is to make sure that any intermediate buffers are filled.

If you have a rev00 MT-32 and chose to run these two tests - I would appreciate it if you could also report your rev00 MT-32 ROM version, your host operating system, MIDI interface and DosBox version in your replies.

dh4rm4 wrote:

As you can see my REV 00 MT32 doesn't have the problem you describe and DOSBox doesn't produce or exacerbate the issue either.

DosBox itself will not produce any errors on a rev00 MT-32, but it does change the MIDI stream that it receives from an executing application. I thought at first that DosBox in UART mode acted only as a "buffered pipe" between the MIDI 'source' and the OS MIDI handler 'sink' for the MIDI bytes which pass through the MIDI_RawOutByte() function. However, closer examination made me realize that it was actually acting as a filter. 😳 The MIDI stream received is changed when going through the MIDI_RawOutByte() function because the 'MIDI capture' feature of DosBox makes the function act as both a 'filter' and 'sink' because it re-assembles the excluded MIDI 'running status' bytes for both MIDI capture and MIDI re-transmission to the underlying host operating system MIDI handler. If the DosBox MIDI code in the MIDI_RawOutByte() function were acting as a 'buffered pipe' then the exact same number of bytes received by DosBox would be sent to the underlying host operating system MIDI handler routines. Most any MIDI file which uses the bandwidth sparing MIDI 'running status' will demonstrate this fact.

Some minor code changes to the MIDI sections of DosBox v0.70 can add a type of in-band rev00 MT-32 SYSEX delays and a slight change to the MIDI 'running status' byte handling of the MIDI_RawOutByte() function can correct the MIDI stream filtering. However, first the need for rev00 MT-32 inter-SYSEX delays must be demonstrated. 😁

Thanks again for your time,

dvwjr

1. Native Test - fine. "ROBIN HOOD" displayed on LCD.

2. Ran the batch file included, no errors - "ROBIN HOOD" displayed.

3. As per instructions, ROM version displays "1.07, October '87 Thanks to MASA and Adrian".

delivered at "instant messaging speed".

heh

Glad you ran the tests!

It seems as if your rev00 Roland MT-32 has no problem when playing the ROBINSYX.MID file outside of DosBox, which indicates that the MIDI reproduction chain on your particular system takes care of any SYSEX delays needed by the MT-32 synth. I would be curious as to what is your PC configuration, Operating system, MIDI interface/cabling for the test your ran? Is your MT-32 connected via USB, Serial, MPU-401, chained to anothe MIDI device?

In your case the particular configuration used seems to handle the MT-32 rev00 just fine, so DosBox is no factor in the equation. If possible, could your run the same test under a temporary real DOS boot (that is if you use a hardware MPU-401 interface) to see if your rev00 MT-32 reacts in the same way?

If anyone else has any test results and PC/MIDI configuration to post, feel free to post. 😁

Thanks again,

dvwjr

Here are my results:

Ran DUMP CB.SYX from a command prompt: "Exc. Buffer overflow"

Ran DUMP CB.SYX in DOSBox at 3000 cycles: "** Quest Studios **"

Ran DUMP CB.SYX in DOSBox at 30,000 cycles: "** Quest Studios **"

Ran ROBINSYX.mid in Windows Media Player: "ROBIN HOOD"

Ran MT32rev0 from a command prompt: "Exc. Buffer overflow"

Ran MT32rev0 in DOSBox at 3000 cycles: "Exc. Buffer overflow"

Ran MT32rev0 in DOSBox at 2500 cycles: "ROBIN HOOD"

My computer is an Athlon XP 1900+ running Windows XP SP2.

My MT-32 is "ver1.07 10 Oct, 87". It is connected to the computer via an Edirol UM-3EX USB MIDI interface.

I am using the version of DOSBox 0.70 supplied with DBGL 0.55.

FWIW, before I got the UM-3EX, I had my MT-32 connected to my SC-55mkII, which was connected to the computer's serial port. I would have to slow DOSBox down to about 75 cycles to get most Sierra sysex files to load without an "Exc. Checksum error". (At 75 cycles, it took several minutes for the game to start.)

I don't think I've gotten an "Exc. Checksum error" since getting the UM-3EX and connecting the MT-32 directly to it instead of passing everything through the SC-55mkII.

dvwjr wrote:

what is your PC configuration, Operating system, MIDI interface/cabling for the test your ran? Is your MT-32 connected via USB, Serial, MPU-401, chained to anothe MIDI device?

Core2Duo 2.6ghz (Allendale OC'd), 2GB DDR2 667mhz RAM, 7800GT, i965 motherboard.

MT32 is connected via M-Audio O2 USB controller. PC -USB-> O2 -DINMIDI-> MT32.

Windows XP SP2.

could your run the same test under a temporary real DOS boot (that is if you use a hardware MPU-401 interface) to see if your rev00 MT-32 reacts in the same way?

Sorry, can't help you there as my interface is USB hosted.

Okay, here come my results.
System Intel P4 3.06 GHz Hyperthreading, 1GB Ram.
Soundcard SB Audigy 2 Platinum Pro, meaning there is a breakout box (correct word?) connected to the sound card. To this my MT32 is connected.
MT32 Firmware 1.07 (10 Oct, 87) (thanks for telling me how to tell this)

Windows XP SP2 playback via Media Player Classic: Mt32 shows Robin Hood
Dosbox CVS: always shows Robin Hood
(Interestingly the Windows test did not work while Dosbox was running, didn't know it "claims" the midi device all the time, though it makes sense now that I think of it 😀)
Dos: I have no idea if I could run this directly with a SB Audigy 2 or if I'd needed to run some Dos drivers first. Once upon a time, I *did* have a boot disk with the SB Live! drivers. Supposedly these are also good for an Audigy.. but where is that disk and is it worth to test?

Edit: Found the drivers online, along with a patch to make them work for an Audigy2. And after rebooting a couple of times (damn, I forgot vital things all the time, like making sure the paths to programs in the autoexec actually exist) the Audigy2 was properly initialised...
BUT playmid.exe could not access the Mt32. Most likely because the breakout box is not setup by the drivers 🙁

Edit2: Now that I have come so far, I'll try to find my old cables and reattach the joystick bracket and will try to find the midi connector cable for the joystick port...

My thanks to forum members dh4rm4, Dominus and Garinder for testing and reporting their rev00 MT-32 MIDI configurations. This helps greatly in narrowing down the required MT-32 SYSEX delay code for DosBox v0.70+.

Well, we really have a MIDI interface hardware selection to choose from now...

Dominus has an Intel P4 (3.06GHz), WinXP (SP2), with a Creative Audigy 2 Platinum Pro as MIDI interface.
MT-32 ROM version 1.07
Results:
Media Player: Test of ROBINSYX.MID = Passed, with "ROBIN HOOD" displayed with no errors.
DosBox v0.70 CVS: Test of MT32rev0.BAT @ max cycles = Passed with "ROBIN HOOD" displayed with no errors.
DosBox v0.70 CVS: Test of MT32rev0.BAT @ 6000+ cycles = Failed with 'Exc. Buffer overflow' message displayed.
DosBox v0.70 CVS: Test of MT32rev0.BAT @ 3000 cycles = Passed, with "ROBIN HOOD" displayed with no errors.
Real DOS: Possible but not yet tested.

dh4rm4 has an Intel E4300 (2.6GHz), WinXP (SP2), M-Audio O2 mobile MIDI controller as MIDI interface.
MT-32 ROM version 1.07
Results: Test of ROBINSYX.MID = Passed, with "ROBIN HOOD" displayed with no errors.
DosBox v0.70 CVS?: Test of MT32rev0.BAT @ 3000 cycles = Passed, with "ROBIN HOOD" displayed with no errors.
Real DOS: Not possible with USB MIDI interface.

Garinder has an Athlon XP 1900+, WinXP (SP2), Roland UM-3EX USB MIDI 3x3 interface.
MT-32 ROM version 1.07
Results:
Media Player: Test not run.
WinXP Command Prompt: Test of MT32rev0.BAT = Failed, with 'Exc. Buffer overflow' message.
DosBox v0.70: Test of MT32rev0.BAT @ 3000 cycles = Failed with 'Exc. Buffer overflow' message displayed.
DosBox v0.70: Test of MT32rev0.BAT @ 2500 cycles = Passed with "ROBIN HOOD" displayed with no errors.
Real DOS: Not possible with USB MIDI interface.

Also, my test results:

dvwjr has an Intel P4 640 (3.2GHz), WinXP (SP2), MIDI interface is Southbridge 16550AFN serial port (COM1:) with Yamaha CBX driver v2.00 to Roland SC-88VL to Roland MT-32.
MT-32 ROM version 1.07
Results:
Media Player: Test of ROBINSYX.MID = Failed, with 'Exc. Buffer overflow' message displayed.
DosBox v0.70: Test of MT32rev0.BAT @ max cycles = Failed, with 'Exc. Buffer overflow' message displayed.
DosBox v0.70: Test of MT32rev0.BAT @ 5000 cycles = Failed, with 'Exc. Buffer overflow' message displayed.
DosBox v0.70: Test of MT32rev0.BAT @ 650 cycles = Passed, with "ROBIN HOOD" displayed with no errors.
Real DOS: Not possible with Roland computer serial port interface.

Note: If you ever get either the MT-32 errors: 'Exc. Buffer overflow' or 'Exc. checksum error' I would recommend that you power-cycle the MT-32. Once such errors have occurred, the MT-32 is much more prone to the same errors on subsequent MIDI data byte transmissions. The key is to prevent said errors from ever occurring in the first place.

So forum member dh4rm4 does not have rev00 MT-32 errors with DosBox at 3000 cycles (other speeds unknown), while Dominus, Garinder and dvwjr do have errors with DosBox, depending on emulated CPU cycles. I would please ask that the MT32rev0.BAT test be re-run with CORE=dynamic and CYCLES=max one more time and the results reported. Edit: Or try increasing cycles manually instead of 'cycles=max'.

The best way to handle the special case of the rev00 MT-32 would be for the host operating system MIDI parser/render/driver to insert time delays between MT-32 SYSEX strings. Given the age of the MT-32 and limited user base, this will most certainly not happen. On the other end, the various MT-32 DOS drivers could be modified to insert such delays give the time to dis-assemble and patch DOS drivers over a decade and a half old... Without those two solutions, then drastically lowering the DosBox emulation cycles seems to be the only other solution for a Roland rev00 MT-32 synth.

Of course it is evident that slowing down the emulation speed of Dosbox can pass the MT-32 SYSEX messages at a slow enough speed so as to allow the rev00 MT-32 to process each SYSEX without errors. However, the downside is that not all games would send any required SYSEX strings at the beginning of the game initialization, some send further SYSEX strings during game play. These variable intra-game SYSEX transmissions would defeat the Dosbox cycle slowdown strategy. The other work-around method recommended is to pre-send the game SYSEX messages with a SYSEX loader by extracting the SYSEX strings from the game resources. This works for games where the SYSEX strings are sent during the game initialization phase, as long as one has a user community such as QuestStudios to support such a methodology. Still, the best answer is a modification to DosBox to provide some DOSBOX.CONF [midi] section options to provide transparent support and to prevent the user from having to consider such Rube-Goldberg work-arounds to play games with proper MT-32 hardware support.

Given DosBox, we are in a perfect position to modify the DosBox MIDI_RawOutByte() function, which is as far a we are concerned IS the DOS MT-32 driver. 😀 So, I have a modified version of the DosBox v0.70 release which adds two additional line items to the [midi] section of the Dosbox.conf configuration file.

1[midi]
2# mpu401          -- Type of MPU-401 to emulate: none, uart or intelligent.
3# device          -- Device that will receive the MIDI data from MPU-401.
4#                    This can be default,alsa,oss,win32,coreaudio,none.
5# config          -- Special configuration options for the device. In Windows put
6#                    the id of the device you want to use. See README for details.
7# mt32rev00       -- Set true for Roland MT-32 revision 00 synthesizers.
8#                    The MT-32 revision 00 models have ROM version 1.0x only.
9# mt32rev00spin   -- Optional extra delays for Roland MT-32 revision 00 synthesizers.
10
11mpu401=uart
12device=win32
13config=0
14mt32rev00=true
15mt32rev00spin=0

Attached to this message is the file: TESTMT32.ZIP which contains two files:
1.) DosboxtestMT32.EXE
2.) ReadME.txt

The special "test case" compile of DosBox v.070 should be 'thrown away' after testing any rev00 MT-32 synth and reporting any success/failure on this message thread. If the MT-32 rev00 SYSEX delay function works on Serial, USB and MPU-401 MIDI interfaces - then the code will, of course be submitted for consideration of acceptance as another small CVS revision. If the delay modification does not work, then it would be best if extraneous code does not keep floating around the Internet... 😀

Please let me know if this test solution works with whatever file or game you throw at it...

Thanks for your time,

dvwjr

Edit: Changed Dominus information to reflect his new test results below.

Previous test was with core and cycles auto (so cycles should have been at 3000).
Tested with core=dynamic, cycles=max -> no error
Tested with core=dynamic/normal, cycles=6000 and more -> Exec buffer overflow at the "Dump.exe THEX2.SYX" part everytime near the end.
Only shows I should have tested more extensively before instead of the quick runthrough. Sorry about that.
Why cycles=max don't behave the same is a mystery to me.

With your exe:
At core=dynamic and cycles=41000 still runs without error.

then the code will, of course be submitted for consideration of acceptance as another small CVS revision. If it does not, then it would be best if extraneous code does not keep floating around the Internet.

Nope, no matter what the powers that be decide, a path that fixes a certain behaviour should be kept around. The patch tracker on sf.net is a perfect place for those. Someone else will run into the problem again in the future and then it is nice to have a patch around, no matter that it didn't go into mainstream CVS.