MT-32 Buffer Overflow and Checksum Errors

[Tawmis]

Want to combine laffer's thread to this one?

[laffer]

Good idea making this thread, quite useful information in that post and it was a bit drowned away in my thread.
One thought I had - even though it does say in the text quoted that you should replace your cables, maybe if you mention that replacing the cable has actually been tested out and did indeed fix the issue in some cases (another guy I read a few posts by on another forum also had the identical issue and replacing the cables was the solution for him as well)... so we have a couple of cases where the cables was the confirmed problem.

I was thinking it might make it seem a bit less 'theoretical' for people if they could read that this is a problem others have had and corrected by getting a new MIDI-USB cable.

Maybe it could also be useful to know which cable solved it for me?
Seeing as this cable works perfectly in Vista 64 while the back of the packaging only lists XP and Vista 32 bit as compatible operating systems.

In any case, the name of the cable that finally got it working for me is -
"MIDISPORT Uno, (1-in/1-out USB MIDI Interface) - last part in smaller text underneath the name on the packaging.

[Collector]

Want to combine laffer's thread to this one?

That is the thread that the first post came from. If you merge, MI's post will get buried. The point of copying MI's post was to have it at the top of the stickied thread.

[MusicallyInspired]

Anything by Mark Seibert and/or Ken Allen is sublime. Also, Jan Hammer did the PQ3 soundtrack and it sounds great. He knows his way around synthesizers so it was interesting to see his take on an MT-32 soundtrack. My personal favourite MT-32 scores: KQ5, Camelot, Longbow, SQ3, PQ2, and even KQ6 has a great MT-32 representation of the soundtrack. It's one of the few that had specific attention made to the MT-32 version of the soundtrack as opposed to the later ones that just added MT-32 support as an afterthought backwards-compatible type of thing.

[laffer]

I agree with the people you mention there making awesome music, despite only having heard most of it using adlib (so far).

I've always had a soft spot for Seibert, especially... but they're all good.

Jan Hammer I like because of how he seemingly creates a lot of quite cheesy (but still awesome!) music without any hint of irony


EDIT - just wondering if you know of any easy way to record the MT32 music while playing? I was thinking of maybe recording some 'longplays' featuring MT32 music but I'm unsure of how to record it.

[MusicallyInspired]

Generally one would plug the output of the MT-32 into the Line Input of your sound card. You'd need a Y cable with two 1/4" TS plugs on one end (for the MT-32) and a 1/8" mini-stereo TRS plug on the other end for your sound card. Or failing that, you could get a Y cable with 1/4" plugs on both ends and buy 1/8" adapter for the single end for your sound card.

Then you'd use a sound recorder like GoldWave or a video recorder if you plan on recording a video playthrough. Just make sure that the right inputs are selected for recording in your volume control and that nothing is muted that shouldn't be.

[laffer]

I actually already do have a cable connecting my MT32 to my soundcard (so I get the sound out of my nice speaker setup here)... but when I try recording a game in DOSBox, the resulting video has no music whatsoever?

Seems DOSBox can't record the music produced by the MT32... I know very (!) little about all of this MIDI stuff so I pretty much have to be spoonfed every little detail or I'll surely mess up somehow

EDIT -

The Magic Meadow from Hero's Quest is great, as well. There are many that are wonderful, but off the top of my head, these are what I thought of first.

So I finally got around to playing this game a bit here and I fully agree, very nice tune!
I think I'm going to have to go all out and play through every Sierra game supporting the MT32, been a while since I played most of them anyway.
It's a bit odd I think how the MT32 seems to be so unknown outside of certain groups of people... I find that most of the time I start talking with someone and mention the MT32, they often don't know what it is, even if they quite like older games.
Could that possibly be one of the reasons why emulation hasn't reached a better stage yet? Lack of general interest? Or am I way off?

[Collector]

I think that few designers used the MT-32 as effectively as Sierra. LucasArts used it well, but I think Sierra's efforts were more of a tour de' force.

The MT-32 emulation has not had that many people involved with it. I think some of the very earliest efforts was by Vlad Romascanu, the author of VDMSound. Dean Beeler (Canada Cow) made the first usable version of the emulator in a special build of DOSBox. This was about the time that Roland slapped him with a C&D order because of the ROMs needed. This is why it was never added to the official DOSBox source. Qbix can say more about this, if he wants.

Sometime later, Jerome Fisher (King Guppy) picked it up and started development under the Munt project. Eventually Canada Cow joined his efforts. A Windows driver was the results of this. Sometime around this point, ScummVM incorporated it into the ScummVM code, minus the ROMS.

Munt had been seemingly dead for quite a while with no public updates to the code and no new binaries. The driver as is does not readily install on Vista or Win7 and not at all on 64-bit. There was still work going on in the background, but no communication with the followers of the project.

Not long ago, ykhwong, builder of one of the better known special developmental builds of DOSBox, started to tinker with it and made a build of DOSBox with Munt in it available. Then sergm of the VOGONS board started working on the code, too, but was unable to contact either Canada Cow or King Guppy to join Munt, so he started the Munt Reloaded project in an attempt to pick up where Canada Cow and King Guppy seemingly left off. Sometime later the Munt team found his attempts to contact them. Dean surfaced long enough to let people know about the current efforts of Munt. I believe that they made sergm a member of the Munt team and that some of the Munt Reloaded code will be used with the main trunk.

If anyone is interested, you can read the ongoing discussion on the VOGONS MT-32 forums. Qbix can correct me if I have any of this way off.

[laffer]

Thanks, that's a very interesting read!
I haven't been following MT32 emulation closely at all, all I knew was it's not very good so far.

Emulation was my first encounter with anything MT32 though... back when I first heard of the thing (I had no idea what an MT32 even was for the longest time, learning just how very much better it sounds came as a bit of a shock), I immediately tried emulating it, using a custom DOSBox build, I forgot what it was called.

But yeah, the results were quite disappointing and I quickly completely gave up on using an emulated MT32... I found I preferred adlib, as bad as it sounds, to partly messed up MT32 music.

[Qbix]

Here's a quote from NewRisingSun on the Quest Studios forums regarding MT-32 errors:

"Buffer Overflow" means the data arrives too fast for the MT-32 to handle. As stated previously, second generation units don't have this problem, as no data can arrive too fast for these models to handle. Reasons why this problem can occur:

the game programmer just didn't care
the game programmer only tested with a second/third generation model
the game programmer did insert the necessary delays, but timed them by counting CPU cycles.
Only in the last case will slowing down your system/DOSBox do any good.

"Checksum Error" is distinct from the "Buffer Overflow". It means that some data got lost before it arrived at the MT-32. This can happen because:

the game programmer counts CPU cycles to wait for the next available MIDI cycle (signaled by the MPU-401's "Data Receive Ready" bit) before sending a data byte. On fast computers, it finishes counting before the next MIDI cycle occurs, and so the game just gives up on sending that particular byte, thus losing it. Obviously, this is a different speed issue than the one causing the "Buffer Overflow".
the sound card/laptop/USB-to-MIDI's drivers don't handle large amounts of MIDI data properly and lose data. Update drivers.
the cables used are broken or not connected properly. Check connections and replace cables.
Only in the first case will slowing down your system/DOSBox do any good. Since you've said it doesn't, check the other reasons.

In the SVN of DOSBox there is now some code that will insert delays when writing to your real MT32. (you can enable it through the midiconfig parameter)
This should make DOSBox is little more friendly with games that write too fast and cables that don't buffer.

[MusicallyInspired]

I actually already do have a cable connecting my MT32 to my soundcard (so I get the sound out of my nice speaker setup here)... but when I try recording a game in DOSBox, the resulting video has no music whatsoever?

Seems DOSBox can't record the music produced by the MT32... I know very (!) little about all of this MIDI stuff so I pretty much have to be spoonfed every little detail or I'll surely mess up somehow

Sorry I seemed to have missed this. Yeah, if you record with DOSBox's record feature you're only going to get sound outputted from DOSBox itself and not any other source of software let alone another sound input on your sound card. You'd have to use either something other than DOSBox to record your videos (like FRAPS maybe or CamStudio) or you'd have to record your DOSBox video while simultaneously recording the MT-32 through your Line Input with another sound recorder and then put them together in a video editing program like Windows Movie Marker or something. Though, it's possible lining them up would require some work. That's all I can really think of.

It'd be nice if DOSBox had a feature while recording to also record from a specific sound source selected from the volume control. But then again, Vista and 7's volume control works completely different than XP and earlier in that it lists software sound sources rather than sound card sources.

[laffer]

Thanks for the explanation, that helped a lot... gave me the idea to google for apps to record whatever is going in through the Line-In port... found a simple little app which seems to do that perfectly.

As you pointed out though - the problem might be to sync the video and the audio 100% correctly if I make some longplays... especially stressful as these are games where I prefer to save from time to time, meaning I have to stop the video every time (to make it seamless... can't have a save prompt popping up here and there... and the same if I should accidentally die somewhere, which is easily done in many of these games).
So that means I'll end up with plenty of gameplay clips to sync with audio clips.

Then again, I'm thinking it might not have to be 100% synced, being very close (like just a percentage or two off) could probably still be good enough, and would be quite a bit easier.

[laffer]

Seeing as this thread has both Checksum Errors and Buffer Overflow in the title, I figured I might as well post this question here -

In some games, such as Dagger of Amon Ra, I get a Buffer Overflow error while loading the game if I have the cycles set at a level where the game runs as quickly as I want it. Music sounds fine though, so not sure if it matters... what exactly does this error affect?

Anyway, by having a really low cycle count while launching the game (3000 always seems to work fine), I avoid the error... so my question is - after I've loaded the game with so few cycles, can I then increase them to the speed I want?
Can it cause any more errors after the game has loaded?

[Collector]

From the DOSBox README:

CTRL-F11 Slow down emulation (Decrease DOSBox Cycles).
CTRL-F12 Speed up emulation (Increase DOSBox Cycles).

[laffer]

Yes, I have been using those already (to slow DOSBox down to avoid the error and then speed it up again after the game is running)... my question is - does increasing the speed after having had it set low to avoid the error while loading... does that cause any problems? Or is the loading part the only "speed critical" part?