VOGONS


Reply 20 of 79, by Garinder

User metadata
Rank Newbie
Rank
Newbie

My previous tests were run with:

mpu401=intelligent
device=default
config=

When I reran the tests with

mpu401=uart
device=win32
config=0

MT32rev0.BAT now passed at 3000 cycles, but failed at 3500 cycles.

Also:

Media Player: ROBINSYX.MID passed

DUMP THEX2.SYX @ 3000 cycles passed

DUMP THEX2.SYX @ 3500 cycles failed

With DosboxtestMT32.EXE:

MT32rev0.BAT with "cycles=max" passed

MT32rev0.BAT with "cycles=30,000" passed

But in some Sierra games, the sysex loading now extends into the introduction, cutting off or postponing the first few notes. This even happens at relatively low cycles (<10,000).

Reply 21 of 79, by Srecko

User metadata
Rank Member
Rank
Member

If you want to insert a delay, best option is (as Qbix mentioned) to set on MPU401 status bit to 1 and return the status byte on port 331 with this bit set. Bit 6 tells the application if mpu401 is ready to receive data on port 330. Of course, you will need to use dosbox timer to change the bit back to 0 after 40ms (or other value). This way you don't stall dosbox, as interrupts and CPU core will run in the meantime.

So, change MPU401_ReadStatus (or whatever it is called) function to also handle bit 6 from some variable which you set to 1 in midi.cpp and set back to 0 from timer callback that you schedule there (for quick info on usage of timers, see e.g. MPU401_Event function).

Reply 22 of 79, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

After finding some time, I did attach the gameport to my Audigy 2 soundcard and connected the Mt32 through that. Apparently it did work since it did work the same as before with the same errors as when it was connected to the break out box. Unfortunately in real Dos it still wouldn't work at all 🙁
So, still no way to test real Dos behavior 🙁

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 23 of 79, by dvwjr

User metadata
Rank Member
Rank
Member

Sorry for the delay in getting back to y'all. Some real-world delays have impacted the MT-32 testing. 😦

The previous MT-32 test versions of DosBox v0.70 were just to confirm that a particular delay strategy will work. In the next few days I should have another test Dosbox version to try. This should be the actual implementation for all rev00 MT-32 Roland synths with get the DosBox MIDI stream.

Thanks for your patience,

dvwjr

Reply 24 of 79, by dvwjr

User metadata
Rank Member
Rank
Member

Back again. 😮

Have some more comments and a new test version of Dosbox v0.70 for rev00 MT-32 Roland synths when using Dosbox v0.70+...

Qbix wrote:

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.

I think that the unused, left-over "#define RAWBUF 1024" in MIDI.CPP shows that someone might have tried at one time to implement a circular buffer for MIDI bytes in combination with the DATA READ READY (bit #6) on the MPU-401 STATUS/COMMAND port. However, you are correct, games do not need any delay, it is the rev00 MT-32 hardware which does...

Srecko wrote:

If you want to insert a delay, best option is (as Qbix mentioned) to set on MPU401 status bit to 1 and return the status byte on port 331 with this bit set. Bit 6 tells the application if mpu401 is ready to receive data on port 330. Of course, you will need to use dosbox timer to change the bit back to 0 after 40ms (or other value). This way you don't stall dosbox, as interrupts and CPU core will run in the meantime.

So, change MPU401_ReadStatus (or whatever it is called) function to also handle bit 6 from some variable which you set to 1 in midi.cpp and set back to 0 from timer callback that you schedule there (for quick info on usage of timers, see e.g. MPU401_Event function).

I looked at the potential to use the emulated MPU-401 DRR status (bit #6) signaling in combination with the Dosbox timer callback functionality but rejected that particular 'out-of-band' delay approach, because of what I saw as a "three bounds" problem for implementing rev00 MT-32 Roland synth SYSEX processing delays.

The first bound is that any use of the MPU-401 interface DATA READ READY (bit #6) of the means that the MSDOS game's MT-32 driver must be able to deal with this bit being set high, for whatever time it is necessary it be raised by the emulated MPU-401 interface. Some of the early MSDOS MT-32 drivers had very tight counters, in the byte value range (256), which limited the amount of time the driver would spin in a wait loop for the MPU-401 DRR bit to clear, so that a MIDI byte could be transferred to the MPU-401 interface DATA port. Even modern compilations of older MSDOS games - such as the recently released Sierra "King's Quest Collection" still ship with the original 1989 MSDOS MT-32 drivers. Given the nominal 40 milli-seconds (40,000 µs) inter-SYSEX delay required for the rev00 MT-32, this approach would fail unless the user understood that a properly patched MSDOS MT-32 driver must be found and installed. Add to this the fact that any rev01 or later MT-32 (or related Roland derivative synth) would not need such an updated MSDOS MT-32 driver - more potential confusion concerning replacement of archaic MSDOS MT-32 drivers by novice users in the year 2007... Plus this particular methodology creates far too long a wait for Dosbox, or the game/driver to sit in an emulated MPU-401 interface DRR spin loop. This strategy implies that the MIDI byte time-delay queue resides in the application.

NewRisingSUn wrote:

It's not that the LAPC can't run at 8.33 MHz, most likely, it doesn't care about bus speed at all. The issue is not what the LAPC runs at in and of itself, but how much delay a single write to its ports will enforced by the ISA bus hardware, and at 8.33 MHz, a single port read/write will cause a delay of about 0.12 µs, whereas at 4.77 Mhz, a single port write will cause a delay of about 0.21 µs. (Edit note: Dosbox v0.70 uses 1.0 µs I/O port Reads and 0.75 µs I/O port Writes.)

MIDI has a baud rate of 31250, or 3125 bytes (10 bits per byte) per second, thus requiring a delay of 320 µs between bytes. Sierra's MT32.DRV waits at most 256 port reads, or 256*0.21 µs ~ 55 µs, probably more since I'm not counting the delay caused by the 8088 LOOP instruction, but even when taking that into account, it's obvious that Sierra walked a *very* tight line with that driver, probably relying heavily on the MPU-401's FIFO buffer, too. I noticed if I reduce the wait count in the driver from 256 to 200 port reads, it already fails.

To summarize: the LAPC will happily work in all ISA slots; it's just a few really crappy sound drivers like Sierra's that require some ultra-precise bus timing. Other software is more defensive in their programming, and thus doesn't have that problem. The 8-bitness of the LAPC only comes into play to cause the 4.77 MHz bus timing required for Sierra's tight timing loop.

Source: QuestStudios MT-32 forum Author: NewRisingSUn.

The second bound is that any commitment of a Dosbox fixed time-delay callback for rev00 MT-32 SYSEX processing would not currently take into account the fact that said delay is not necessary for non-SYSEX MIDI bytes output immediately following the end of an MT-32 SYSEX string directed to a rev00 MT-32 synth if the total transmission time of the non-SYSEX MIDI bytes equals the required inter-SYSEX delay time. This fact introduces a need for variable timing for post-SYSEX MIDI byte transmission that a straight 'out-of-band' fixed timing delay approach would not support. Given that Dosbox accepts MIDI bytes written to its emulated MPU-401 interface at any time (MPU-401 DRR bit always clear) a circular MIDI byte buffer would have to be implemented in the Dosbox MIDI_RawOutByte() function to allow this type of 'out-of-band' time delay approach to work properly. Such a strategy implies that the MIDI byte time-delay buffer resides inside of Dosbox.

THe third bound is that each host operating system supported by Dosbox has a MIDI API chain with different latency characteristics, not to mention latency differences in the various hardware MIDI interfaces supported. These hardware MIDI interfaces might be an original ISA MPU-401, a Sound Blaster-type MPU-401 (UART), a modern PCI based MIDI interface adapter, Serial port, USB MIDI, or USB MIDI with custom USB-MIDI drivers. The varying latencies are also modified further by the different sized data buffers present in both the MIDI interface hardware and its associated driver software. From previous replies concerning MT-32 testing on this message thread, it is apparent that even on a common operating system such as WinXP (SP2), that different processor speeds and MIDI interface hardware/drivers require some ability to 'tune' any rev00 MT-32 delay function on a per PC workstation basis. So a straight, fixed 40 milli-second timing delay in all cases is out, variability per system is in... This would be somewhat akin to the Dosbox 'FrameSkip=' parameter which might need to vary depending on the hardware CPU/GPU display combination to deliver similar performance.

Source: System-Level MIDI Performance Testing PDF file.
Source: A Survey of Real-Time MIDI Performance PDF file.
Source: The Truth about Latency Sound On Sound magazine, September 2002.

The latest test version of a modified Dosbox v0.70 Windows executable is DosboxTest4MT32.EXE, which is included in the attached file TEST4MT32.ZIP below.

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

mpu401=uart
device=win32
config=0
mt32rev00=true
mt32rev00spin=0

When testing the DosboxTest4MT32.EXE file, the Dosbox.conf [midi] section variable 'mt32rev00=true' must be present for the default SYSEX delay to be applied to MT-32 SYSEX strings. The other [midi] section variable 'mt32rev00spin=0' may be changed to add or subtract from the default internal delay number compiled in Dosbox of '64', which is implicit as 'mt32rev00spin=0'. This default internal delay number was derived from testing with a Yamaha CBX v2.00 MIDI serial port driver which connects my PC workstation to a Roland SC-88VL, which then connects to the Roland rev00 MT-32 synth. This serial port based MIDI combination probably has one of the lowest MIDI latencies as compared to PCI based MPU-401 or USB MIDI interfaces, so that negative numbers could be used for 'mt32rev00spin=?' to lower the 'in-band' delay functionality for the higher latency MIDI interfaces. Of course, if the MT-32 error messages 'Exc. Buffer overflow' or 'Exc. Checksum error' appear, then the 'mt32rev00spin=?' variable must be increased until the error messages disappear. This 'in-band' strategy implies that the MIDI byte time-delay queue resides in the host operating system's MIDI interface buffer(s), serviced by a thread separate from that which executes the DosboxTest4MT32.EXE program file.

Garinder wrote:

But in some Sierra games, the sysex loading now extends into the introduction, cutting off or postponing the first few notes. This even happens at relatively low cycles (<10,000).

I would be happy if the same testing could be repeated with the attached version of DosboxTest4MT32.EXE at Dosbox cycles above 10,000 to see if there is still any "loss of notes" or "postponement" of the first few notes of said Sierra games. On other game fronts, I tried the new DosboxTest4MT32.EXE with "Lemmings 2: The Tribes", it seemed to work - no buffer overflows, but I am not that familiar with the Roland MT-32 sound of that particular game to be sure everything is OK.

The attached file TEST4MT32.ZIP which contains the file DosboxTest4MT32.EXE should have that file copied in the same directory as a current default Dosbox v0.70 installation. Another ZIP file: MT32rev0.ZIP which contains files for testing can be found as an attachment to the 13th posting on page 1 of this message thread along with instructions as to how to use the included files.

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

The special "test case" compile of DosBox v.070 (DosboxTest4MT32.EXE) should, again, be 'thrown away' after testing any rev00 MT-32 Roland 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 for WinXP (SP2) - then the code will, of course be submitted for consideration of acceptance as another small CVS code revision where further testing may be done for other Dosbox supported operating systems.

Please let me know if this test solution works for any rev00 MT-32 Roland synth, with whatever MT-32 MIDI file or game(s) you throw at it... 😁 If you specify your hardware and MIDI interfaces, and the DosBox cycles (dynamic or normal) for any failures or sucesses - it would be greatly appreciated.

Thank you for your time,

dvwjr

Attachments

  • Filename
    TEST4MT32.ZIP
    File size
    794.6 KiB
    Downloads
    672 downloads
    File comment
    DosboxTest4MT32.EXE and ReadME.txt file included
    File license
    Fair use/fair dealing exception

Reply 25 of 79, by =zum=

User metadata
Rank Newbie
Rank
Newbie

I'm just curious, but I've done the mt32rev0.bat test with dosbox 0.70 and my mt-32 rev01 (not 00, for non-confusion I got serial number 893276), and the first time it went ok, but when I got to repeat it 11 times, it always shows the buffer overflow error! Is this normal? My cycles were 3000 with frameskip 0, I attempt to test "test4mt32.zip".

Reply 26 of 79, by dvwjr

User metadata
Rank Member
Rank
Member
=zum= wrote:

I'm just curious, but I've done the mt32rev0.bat test with dosbox 0.70 and my mt-32 rev01 (not 00, for non-confusion I got serial number 893276), and the first time it went ok, but when I got to repeat it 11 times, it always shows the buffer overflow error! Is this normal? My cycles were 3000 with frameskip 0, I attempt to test "test4mt32.zip".

=zum=,

Thanks for your curiosity! I myself have MT-32 serial #890770, while you have MT-32 serial #893276. According to the Wikipedia article on the MT-32, the classification of Roland MT-32 synths can be summarized as follows:

Serial #           PCB Revision      ROM version       Generation
*********************************************************************
?????? - 851399 Rev00 Version 1.0x 1st
851400 - 950499 Rev01, "old" Version 1.0x 1st
950500 - ?????? Rev01, "new" Version 2.0x 2nd

According to the Wiki info, both you and I have a Rev01, "old" PCB version, which in essence means that both of us have a rev00 MT-32. 😁 That is, you will suffer from MT-32 'Exc. Buffer Overflow' errors if there is not a sufficient delay between SYSEX strings. So the error you described is to be expected with your particular MT-32 synth. Only if your MT-32 ROM version is in the 2.0x range would you avoid any MT-32 SYSEX delay related errors.

If you try the test version of 'DosboxTest4MT32.EXE', you might be able to avoid these errors during your testing of the 'mt32rev0.bat' file if the [midi] section has 'mt32rev00=true' in your Dosbox.conf configuration file. Remember that you can increase the delay factor by making the 'mt32rev00spin=0' value larger until any 'Exc. Buffer overflow' or 'Exc. Checksum error' no longer appear. If you ever get these error messages, please power-cycle your MT-32 before continuing any testing.

If you get a chance to document your PC/midi/MT-32 configuration it would be appreciated...

Thanks for your interest,

dvwjr

Reply 27 of 79, by =zum=

User metadata
Rank Newbie
Rank
Newbie

OK, I've done the 'DosboxTest4MT32.EXE', with 3000 cycles as always and with this midi options:

mpu401=uart
device=win32
config=0
mt32rev00=true
mt32rev00spin=0

And it went OK!! The Sysex messages are delivered without problems of any kind, just... something weird happens:

hangza3.png

Your build hangs horribly at this point and I've got to close it with task manager! I don't know.

Then the MT-32 then wont receive any sysex message!! I'm afraid something happened!!
EDIT: Just restarted my system and all worked ok!

By the way these are my spec:

Pentium 4, 2.8 GHZ
512 MB Ram
Windows XP (SP2)
I've got a USB Adapter EDIROL UM-1 MIDI INTERFACE connected to MT-32
How I can view my own rom version?

Reply 28 of 79, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

How I can view my own rom version?

just the way you did. The serial tells you which ROM version you have.
Now that the test worked for you, with original Dosbox, can you do it again with higher cycles? Since with 3000 it worked for me as well, but crapped out on higher cycles.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 29 of 79, by =zum=

User metadata
Rank Newbie
Rank
Newbie
Dominus wrote:

How I can view my own rom version?

just the way you did. The serial tells you which ROM version you have.
Now that the test worked for you, with original Dosbox, can you do it again with higher cycles? Since with 3000 it worked for me as well, but crapped out on higher cycles.

Original dosbox wont work for me. See above. (Maybe you're telling CVS?)

Reply 31 of 79, by Garinder

User metadata
Rank Newbie
Rank
Newbie

I can't tell any difference between the old build and the new one.

With both builds, Police Quest 2, Colonel's Bequest, Rise of the Dragon, Space Quest 3, and probably most other games that start intro music soon after loading the sysex file will have the first few notes delayed or cut off if the cycles are high enough.

This happens because the game is going fast while the sysex loading is being slowed down. The graphics start before the MT-32 finishes loading the sysex file, and the notes that go along with the first graphics can't play until the sysex is done loading.

Reply 32 of 79, by dvwjr

User metadata
Rank Member
Rank
Member
=zum= wrote:

How I can view my own rom version?

From a previous message in this thread:

dvwjr wrote:

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.

You most probably have the ROM version 1.07 in you MT-32.

=zum= wrote:
And it went OK!! The Sysex messages are delivered without problems of any kind, just... something weird happens: [picture] […]
Show full quote

And it went OK!! The Sysex messages are delivered without problems of any kind, just... something weird happens: [picture]

Your build hangs horribly at this point and I've got to close it with task manager! I don't know.

Then the MT-32 then wont receive any sysex message!! I'm afraid something happened!!
EDIT: Just restarted my system and all worked ok!

There was a programming mistake with my debugging code in the DosboxTest4MT32.EXE build. I believe that error is now fixed in DosboxTest5MT32.EXE in the TEST5MT32.ZIP file attached to this message. If you have the time, please try your tests of 'MT32rev0.bat' again with the new build. The problem was that a variable was being decremented twice, which in some cases would pass a zero or negative value to the host operating system MIDI string output. That is why you had an application 'hang'...

=zum= wrote:

Original dosbox wont work for me. See above. (Maybe you're telling CVS?)

The original Dosbox v0.70 or the latest CVS build will do nothing to help a rev00 Roland MT-32 synth, unless someone has implemented some MT-32 SYSEX delay code. 😀

dh4rm4 wrote:

Zum when your machine stops sending midi data to your MT32, just disconnect the USB to MIDI adaptor and reconnect it. That's much quicker than a reboot and it should fix the problem.

=zum=, excellent advice from dh4rm4 if your USB/MIDI connection was problematic after executing the buggy DosboxTest4MT32.EXE build. You should also power-cycle (off/on) your MT-32 synth after any testing runs that cause any MT-32 errors. Yes, using an MT-32 SYSEX reset is possible, but a 'quick and dirty' power-cycle is faster. 😀

Garinder wrote:

I can't tell any difference between the old build and the new one.

With both builds, Police Quest 2, Colonel's Bequest, Rise of the Dragon, Space Quest 3, and probably most other games that start intro music soon after loading the sysex file will have the first few notes delayed or cut off if the cycles are high enough.

Garinder, thanks again for your valuable input, as I do not have access to many games supporting the Roland MT-32 synth. My 'DosboxTest4MT32.EXE' (has bug) and the latest 'DosboxTest5MT32.EXE' builds have the 'in-band' inter-SYSEX delay algorithm finalized. However, the base-line default inter-SYSEX delay is not much different from the original test version, so your observation is correct. My only current access to games supporting the Roland MT-32 are "Lemmings 2: The Tribes", "Great Naval Battles North Atlantic: 1939-1943", and the recently re-released Sierra "Kings's Quest Collection". The QuestStudios forum also provides many Sierra MT-32 MIDI and SYSEX files for testing and comparison.

Garinder wrote:

This happens because the game is going fast while the sysex loading is being slowed down. The graphics start before the MT-32 finishes loading the sysex file, and the notes that go along with the first graphics can't play until the sysex is done loading.

I was hoping that most Sierra games supporting the MT-32 synth would be like 'King's Quest I (VGA)' or 'King's Quest IV' which seemed to 'hide' the initial massive MT-32 SYSEX loads in an opening or initial main menu. Evidently not... 🙁

Since your WinXP (SP2) MIDI chain involves an Roland UM-3EX USB 3X3 MIDI interface (with custom Roland USB MIDI drivers??) you now have the ability to 'fine-tune' the inter-SYSEX delay factor used for your particular PC/MIDI/MT-32 chain. Your Roland USB MIDI interface may have different delay characteristics than my serial port attached Roland SC-88VL/MT-32 combo. This may help somewhat with the cumulative initial delay that you encountered with the Sierra games that you mentioned. Here is what you may do to test and configure the 'DosboxTest5MT32.EXE' build:

[midi] 
# mpu401 -- Type of MPU-401 to emulate: none, uart or intelligent.
# device -- Device that will receive the MIDI data from MPU-401.
# This can be default,alsa,oss,win32,coreaudio,none.
# config -- Special configuration options for the device. In Windows put
# the id of the device you want to use. See README for details.
# mt32rev00 -- Set true for Roland MT-32 revision 00 synthesizers.
# The MT-32 revision 00 models have ROM version 1.0x only.
# mt32rev00spin -- Optional extra delays for Roland MT-32 revision 00 synthesizers.
# (MAY BE positive or negative, range: -59 to 1023.)

mpu401=uart
device=win32
config=0
mt32rev00=true
mt32rev00spin=0

Please perform the following tests with the 'DosboxTest5MT32.EXE' with core=dynamic and cycles=auto so that the cycles are at 3000 for the following. Since the USB MIDI interface seems to have a greater latency than the PC MIDI serial port interface, you might try to adjust down the delay factor for your particular USB MIDI attached rev00 MT-32 by decrementing the variable assignment 'mt32rev00spin=0' by one using the previously uploaded 'MT32rev0.bat' test with the 'DosboxTest5MT32.EXE' build. Repeat this decrementing testing until you get either 'Exc. Buffer overflow' or 'Exc. Checksum error' messages, then increment 'mt32rev00spin=' until the error messages go away. Once you have the error-free 'mt32rev00spin=' value, add seven to that number and that is the 'magic' delay factor for your PC/MIDI/MT-32 combination. Others might have to increment the 'mt32rev00=0' value above zero to get the properly delay factor for their particular PC/MIDI/MT-32 chain.

Once you have arrived at a 'mt32rev00spin=' delay factor, it should be good for core=dynamic and cycles=3000 to 10000. Above ~10000 cycles you might have to increase the delay factor. Most of the Sierra and other games from the MT-32 era should work fine between those cycle ranges.

Thanks again to everyone for your input and feedback,

dvwjr

Attachments

  • Filename
    TEST5MT32.ZIP
    File size
    794.65 KiB
    Downloads
    572 downloads
    File comment
    DosboxTest5MT32.EXE and ReadME.txt files.
    File license
    Fair use/fair dealing exception

Reply 33 of 79, by Garinder

User metadata
Rank Newbie
Rank
Newbie

Ok, for me mt32rev00spin=-36 or higher passes and mt32rev00spin=-37 or lower causes an "Exc. Buffer overflow". That makes my magic number -29.

dvwjr wrote:

You should also power-cycle (off/on) your MT-32 synth after any testing runs that cause any MT-32 errors. Yes, using an MT-32 SYSEX reset is possible, but a 'quick and dirty' power-cycle is faster. 😀

You can also reset your MT-32 by holding down [MASTER VOLUME] and then pressing [RHYTHM]. When "** All Reset OK? [1]" appears, press [1].

Reply 34 of 79, by dvwjr

User metadata
Rank Member
Rank
Member

Garinder,

Thank you very much for your test results. With this 'tuned' delay for your PC/USB MIDI/MT-32 chain, did you still have synchronization delay problems with the game MIDI and video that you mentioned previously? I have the sense that only some custom patching of the AGI/SCI timer scripts could compensate for the in-band inter-SYSEX delays performed by the DosboxTest5MT32.EXE build. It seems that the original game programmers might have used a rev01 or rev02 MT-32 (or derivative) synth which means they never built in any delay mechanism for the older rev00 MT-32s slower processing of SYSEX strings.

It is interesting to note that the greater latency of the [PC/USB MIDI/MT-32] chain versus the lower latency [PC/SERIAL PORT/MT-32] chain confirms my thought that a negative 'mt32rev00spin=' number would be necessary so that the USB MIDI inter-SYSEX delays would not be excessive. I hope that more examples are generated to add to the results.

Garinder has an Athlon XP 1900+, WinXP (SP2), Roland UM-3EX USB MIDI 3x3 interface, (USB driver unknown)
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.

DosboxTest5MT32.EXE : Test of MT32rev0.BAT @3000 cycles (dynamic) = "ROBIN HOOD" displayed with no errors.
[midi]
mt32rev00=true
mt32rev00spin=-29

dvwjr 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.

DosboxTest5MT32.EXE : Test of MT32rev0.BAT @ 3,000 cycles (dynamic) = "ROBIN HOOD" displayed with no errors.
DosboxTest5MT32.EXE : Test of MT32rev0.BAT @10,000 cycles (dynamic) = "ROBIN HOOD" displayed with no errors.

[midi]
mt32rev00=true
mt32rev00spin=0

If anyone else has results from the DosboxTest5MT32.EXE (Dosbox v0.70) test build, please feel free to post your PC/MIDI/MT-32 configuration and results. The more results the better! 😀

I have also attached the file TEST6MT32.ZIP which removed my debugging code from the included 'DosboxTest6MT32.EXE' build and also changed some of the parameters in the Dosbox MIDI capture area. I believe that the slightly different MIDI capture is a bit closer to the original. Again, this test build is only for Dosbox version 0.70, not the newer Dosbox v0.71 release.

Thank you for your time,

dvwjr

Attachments

  • Filename
    Test6MT32.zip
    File size
    807.29 KiB
    Downloads
    616 downloads
    File comment
    DosboxTest6MT32.EXE and ReadME.txt files.
    File license
    Fair use/fair dealing exception

Reply 35 of 79, by Garinder

User metadata
Rank Newbie
Rank
Newbie
dvwjr wrote:

With this 'tuned' delay for your PC/USB MIDI/MT-32 chain, did you still have synchronization delay problems with the game MIDI and video that you mentioned previously?

Yes, the delay problem is still there, though it may be slightly better now.

dvwjr wrote:
Garinder has an Athlon XP 1900+, WinXP (SP2), Roland UM-3EX USB MIDI 3x3 interface, (USB driver unknown) MT-32 ROM version 1.07 […]
Show full quote

Garinder has an Athlon XP 1900+, WinXP (SP2), Roland UM-3EX USB MIDI 3x3 interface, (USB driver unknown)
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.

DosboxTest5MT32.EXE : Test of MT32rev0.BAT @3000 cycles (dynamic) = "ROBIN HOOD" displayed with no errors.
[midi]
mt32rev00=true
mt32rev00spin=-29

The ROBINSYX.MID Media Player test passed and I am using Edirol UM-3 Driver Ver.1.0.2 for Windows XP.

Reply 36 of 79, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

On my rev.0 MT-32, the following settings are required for Speedball II: Brutal Deluxe to run without buffer overflow exception messages:

mt32rev00=true
mt32rev00spin=232
cycles=3000

That's a big delay, takes a while to get into the game. It might form a nice test-case for the MT-32 midi buffer problems?!

Reply 37 of 79, by dvwjr

User metadata
Rank Member
Rank
Member
rcblanke wrote:
On my rev.0 MT-32, the following settings are required for Speedball II: Brutal Deluxe to run without buffer overflow exception […]
Show full quote

On my rev.0 MT-32, the following settings are required for Speedball II: Brutal Deluxe to run without buffer overflow exception messages:
.
.
.
That's a big delay, takes a while to get into the game. It might form a nice test-case for the MT-32 midi buffer problems?!

Perhaps you could record the MIDI sequence which includes enough of the particular series of MT-32 SYSEX messages which require such a large delay. Please use the same Dosbox v0.70 test build #6 above as the MIDI capture has been modified. It is strange that so much delay is necessary but a MIDI capture of the complete game startup sequence, until you are actually in the game, would be a help. I recently purchased the "Police Quest" and "Space Quest" re-releases from Amazon to look at the MT-32 rev00 problem again since I did not get enough feedback in the past.

Glad you looked into the MT-32 rev00 again as my worst test case so far is the MUSE output of one of the Monkey Island games. Probably will have to combine a Dosbox counter for number of reads of the MPU-401 I/O port before shifting to my external MIDI delay procedures...

Thanks for the input,

dvwjr

edit: fix spelling

Reply 38 of 79, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

maybe implement the ready to send bit in dosbox itself (at the speed of a rev 000). This would elimate the need the need for configuration parameters). I think Srecko once coded something like this, but he had problems with one game recognising the mt32 then. This might currently not be an issue anymore as our PIC is better as well

Water flows down the stream
How to ask questions the smart way!

Reply 39 of 79, by Srecko

User metadata
Rank Member
Rank
Member
Qbix wrote:

maybe implement the ready to send bit in dosbox itself (at the speed of a rev 000). This would elimate the need the need for configuration parameters). I think Srecko once coded something like this, but he had problems with one game recognising the mt32 then. This might currently not be an issue anymore as our PIC is better as well

I don't remember well, but I think that was for the status bit (for reading data from the MPU).

So, as dvwjr wrote before, the approach with "ready to send" bit would break some old games that use counter up to 256 for checking that bit before giving up. As dosbox cpu emulation is faster than very old PC's (unless you set up very low CPU cycles), those games would give up before a rev 000 timer resets the bit. So maybe current approach from dvwjr is the best option.

Btw... dvwjr, how does your patch achieve throttling? Does it block dosbox main thread when it puts a delay, or is it buffering the data(sysex only, right?) and sending it out at a fixed rate?