VOGONS


HardMPU, anyone?

Topic actions

Reply 380 of 608, by aquishix

User metadata
Rank Member
Rank
Member
the Goat wrote:

I tried launching Monkey Island again to repeat the experiment with the intro music. But unfortunately my experimenting stopped at that point, because I can no longer get Monkey Island to run. It crashes consistently, no matter how many times I reboot etc. Not sure what I'm doing wrong -- or if my copy is bad. At the risk of polluting the topic, any hints for how to properly launch Monkey Island?

(Have you COLD booted? Just curious...)

Secret of Monkey Island is one of those rare gems that will run on an absolute bare bones DOS configuration. I.e., hold down Shift when DOS is booting, to bypass your config.sys and autoexec.bat files, and the game will still run and output to the MT-32. It doesn't even need himem.sys. If you do this and the game is still not working correctly, I would say that you somehow corrupted one of your game files. Just deltree /y your Secret of Monkey Island directory and install it from scratch. If that still doesn't fix it...gremlins.

By the way, Secret of Monkey Island has several command line options that it'll list out if you run the executable with the /? command line parameter(or anything else it doesn't recognize, but that works). The r parameter, for instance, tells the game to use the Roland MT-32.

Last edited by aquishix on 2018-03-11, 08:07. Edited 1 time in total.

Reply 381 of 608, by aquishix

User metadata
Rank Member
Rank
Member
Great Hierophant wrote:

The Secret of Monkey Island uses neither Intelligent Mode nor uploads custom instruments via sysex. You should never reset or power cycle the MT-32 during a game, it will not fix any issues and will wipe whatever instruments or parameters the game has set in the module. You should always reset an MT-32 between running games so that the later game is not using the parameters or instruments from the earlier game. A power cycle is not necessary.

Noted! I'm not in the habit of power cycling my MT-32 in the middle of a running program; I only did it with Secret of Monkey Island because I was desperate to see any change in behavior.

If Secret of Monkey Island truly doesn't use Intelligent Mode, does that mean that the game will play sound correctly through the MT-32 with only a gameport -> MIDI adapter?

Reply 382 of 608, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
aquishix wrote:

Noted! I'm not in the habit of power cycling my MT-32 in the middle of a running program; I only did it with Secret of Monkey Island because I was desperate to see any change in behavior.

If Secret of Monkey Island truly doesn't use Intelligent Mode, does that mean that the game will play sound correctly through the MT-32 with only a gameport -> MIDI adapter?

Yes. It should also work fairly well playing on a Sound Canvas or similar device that emulates the default MT-32 instrument set.

All hail the Great Capacitor Brand Finder

Reply 383 of 608, by aquishix

User metadata
Rank Member
Rank
Member
gdjacobs wrote:
aquishix wrote:

Noted! I'm not in the habit of power cycling my MT-32 in the middle of a running program; I only did it with Secret of Monkey Island because I was desperate to see any change in behavior.

If Secret of Monkey Island truly doesn't use Intelligent Mode, does that mean that the game will play sound correctly through the MT-32 with only a gameport -> MIDI adapter?

Yes. It should also work fairly well playing on a Sound Canvas or similar device that emulates the default MT-32 instrument set.

Well...it doesn't. I happen to have an SC-55MkII. I plugged it in to my CT2800's gameport, ensured that P330 was in my BLASTER environment variable, re-ran diagnose.exe /s, ran the Secret of Monkey Island...and...garbage. Different garbage than I got via the HardMPU, but garbage nonetheless. Similar result hooking my MT-32 up to the CT2800's gameport.

I also configured Doom to use General Midi with the SC-55MkII hooked up, and it played correctly (of course). Just pointing this out so you don't think that the entire setup was malfunctioning.

Reply 384 of 608, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

For the SC-55mkII, the unit needs to be put into MT-32 mode, or it will sound wrong.

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

Reply 385 of 608, by ab0tj

User metadata
Rank Member
Rank
Member

Ok, so I spent some time this morning doing some testing. On my main DOS machine (K6-3+), with a HardMPU, Monkey Island sounds very similar to your "garbled" version. With my AWE32 and a gameport adapter, I just got random notes that didn't even sound like music. If I use SetMul to slow the CPU down, everything sounds great with either option. This leads me to believe Monkey Island is speed sensitive. The machine I test HardMPU cards with is a Pentium... 90MHz, I think? And monkey island has no issues there.

That doesn't really explain why it sounds fine with your Roland MPU, though. I'll have to put mine in the K6 machine and give that a go.

Reply 386 of 608, by ab0tj

User metadata
Rank Member
Rank
Member

Ok, round 2... I dug out my "Roland DG" MPU401 and MIF-IPC-B card. This creates a bit of a mess on my workbench 🤣 Guess what? Monkey Island sounds perfect without slowing the machine down, just like you describe. I'd suspect a problem with HardMPU, but it actually seems to do better than my AWE32 in this regard, and I've yet to have this problem with any other game on my K6 machine... So I'm not sure what to think just yet.

Attachments

  • IMG_20180311_133613.jpg
    Filename
    IMG_20180311_133613.jpg
    File size
    287.75 KiB
    Views
    1717 views
    File license
    Fair use/fair dealing exception

Reply 387 of 608, by aquishix

User metadata
Rank Member
Rank
Member
Great Hierophant wrote:

For the SC-55mkII, the unit needs to be put into MT-32 mode, or it will sound wrong.

This comment inspired me to do a more thorough investigation of the matter.

I have very carefully created 25 separate recordings of my MT-32 and SC-55MkII playing various games via different connectors, etc.

The filenames should be fairly self-explanatory, especially since I based the spreadsheet off of them. To listen to the tracks, go here: http://www.hilbertspace.net/stuff/MT-32/

A fairly detailed spreadsheet is downloadable from the same page. I've attached a screenshot of the spreadsheet for anyone who doesn't want to open the .xls file itself.

The takeaway is that the MT-32 does NOT play Secret of Monkey Island correctly on my system unless it is through either the MIF-IPC-B or a gameport along with SoftMPU. SysEx delaying seems to make little to no difference in any of the configurations I tried. Playing MT32EMUL.MID through my SC-55MkII did bring the output pretty close to the genuine MT-32's output, but even before doing that, it was very clear that it was somewhat correct instead of the garbled mess that it is with the HardMPU or gameport -> MIDI cable (WITHOUT SoftMPU, that is!).

If anyone sees any inconsistencies or other errors in this, please let me know. I spent quite a bit of time on this and I want to get it right.

Attachments

  • Roland_Investigation.png
    Filename
    Roland_Investigation.png
    File size
    100.58 KiB
    Views
    1693 views
    File comment
    Screenshot of detailed spreadsheet.
    File license
    Fair use/fair dealing exception

Reply 388 of 608, by aquishix

User metadata
Rank Member
Rank
Member
ab0tj wrote:

Ok, round 2... I dug out my "Roland DG" MPU401 and MIF-IPC-B card. This creates a bit of a mess on my workbench 🤣 Guess what? Monkey Island sounds perfect without slowing the machine down, just like you describe. I'd suspect a problem with HardMPU, but it actually seems to do better than my AWE32 in this regard, and I've yet to have this problem with any other game on my K6 machine... So I'm not sure what to think just yet.

I really appreciate the time you're spending on this -- especially duplicating my results!

What version of SoftMPU did you bake into HardMPU v1.1? I was shocked to discover that SoftMPU v1.91 plays Secret of Monkey Island correctly with both my MT-32 and SC-55MkII (w/ MT-32 emulation set), but HardMPU v1.1 does not.

Reply 389 of 608, by aquishix

User metadata
Rank Member
Rank
Member

Also, some extra info/thoughts after creating the spreadsheet and recordings:

I verified tonight that disabling L1 and L2 cache in my CMOS setup makes both Secret of Monkey Island and Prince of Persia play music correctly to the MT-32 through the HardMPU. Could this mean that the MIF-IPC-B has an unmentioned buffering and rate limiting feature?

Furthermore, I verified that with L1 and L2 cache disabled, Secret of Monkey Island plays its music beautifully through my CT2800's gameport to the MT-32. Nothing else I've tried does, but I've only tried a few things.

With only L2 cache disabled, Abuse's soundtrack seems to be correct, now. (Through the HardMPU. Haven't tried this or anything else with the MIF-IPC-B & MPU-401 after slowing down the PII.)

Tonight has been a joyous and also sad night, because now I'm understanding what's going on a lot better, but I've also concluded that I have to build even more vintage systems because of this. The reason that I had convinced myself that a Pentium II @ 350MHz was going to cover (almost) everything released from 1987 to 1997 was that in my youth, I only had Sound Blaster or SB compatible cards for my audio solutions. The Adlib music on DOS games never seems to screw up or vary at all, really, when playing them on faster or slower machines. (Neither does PCM-based music or CD-audio based music, AFAICT.) The only real problems I can remember encountering while running old DOS games on really fast machines were both graphics related, not sound related. Specifically, the hard-coded velocity of the palette rotation trick employed for water movements in Warcraft, as well as the mouse and keyboard scrolling speeds on both Warcraft and Warcraft II. Similar issues with Alien Legacy, now that I think about it. But these examples are relatively rare in my experience, regardless.

My, my, how owning vintage Roland hardware changes everything.

So in conclusion, I can put this all to rest for myself, because I have a path forward for my vintage gaming project(s). However, it looks like I've exposed a corner case for HardMPU (*especially* because SoftMPU was working correctly, even with the high CPU speed!) that should be explored and corrected. It might even turn out to shed some light on the inner workings of the whole Roland device chain. (MIF-* --> MPU-401 --> MT-32)

It's particularly interesting to me that the MIF-IPC-B prevents timing issues from screwing up the music on the MT-32 with Secret of Monkey Island while the gameport --> MIDI approach with my CT2800 does not. It's almost a logical conclusion that MIF-IPC-B is doing *some* kind of buffering or rate limiting, even if it wasn't designed to prevent problems like what I've experienced with the HardMPU. However, the fact that the SysEx delay feature of the HardMPU did not also correct it is baffling. Makes me want to understand exactly how the various delay techniques work in these different solutions.

Reply 390 of 608, by keropi

User metadata
Rank l33t++
Rank
l33t++

This is why I mentioned earlier that p1 is the absolute max for gaming with MPUs and MT-32 and even that needs some tricks like L1 cache disabling.
95% of the time it's the game's drivers that crap out due to speed.

You might get lucky and have MI work OK with the Roland card but not HardMPU but if you try more games you might find the exact opposite situation .
Also keep in mind that ACPI is hardcoded at IRQ9 and some games don't like sharing and love their IRQ2/port330 setting. You might get lucky and have a slot1 mobo that ACPI can be disabled but they are rare AFAIK.

Both games and hardware were not made for fast systems, that's the reality of it and building a slower system is unavoidable IMHO.

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 391 of 608, by aquishix

User metadata
Rank Member
Rank
Member
keropi wrote:
This is why I mentioned earlier that p1 is the absolute max for gaming with MPUs and MT-32 and even that needs some tricks like […]
Show full quote

This is why I mentioned earlier that p1 is the absolute max for gaming with MPUs and MT-32 and even that needs some tricks like L1 cache disabling.
95% of the time it's the game's drivers that crap out due to speed.

You might get lucky and have MI work OK with the Roland card but not HardMPU but if you try more games you might find the exact opposite situation .
Also keep in mind that ACPI is hardcoded at IRQ9 and some games don't like sharing and love their IRQ2/port330 setting. You might get lucky and have a slot1 mobo that ACPI can be disabled but they are rare AFAIK.

Both games and hardware were not made for fast systems, that's the reality of it and building a slower system is unavoidable IMHO.

When you wrote that about the P1 being the max, I knew you knew what you were talking about and I was just hoping that it was more of an issue of getting things to work or tolerating things instead of preventing abject malfunction. I was encouraged in that belief by the fact that Kings Quest IV, Space Quest III, Rise of the Dragon, and several other games were performing so beautifully with the MT-32...or so I thought. Once I slowed down the system to a 386SX15 level of performance, I started noticing that it wasn't just total malfunction that could happen when the MT-32 wasn't being treated how it wants. I noticed subtle differences in note timing and duration, sounds that were inaudible at the higher CPU speed but came through clearly when slowed, sound tracks that were perfect *except for a single instrument*, etc. It's really unbelievable how sensitive of a device the MT-32 is/was. At least, the 1st generation ones. I'm very eager to get my hands on a 2nd gen MT-32 and do a lot more testing.

My Tekram motherboard -- the P6B40-A4X -- is a fantastic board. It has 1 AGP slot, 4 PCI slots, and 3 ISA slots. I have ACPI disabled in the CMOS. It lets me control L1 and L2 cache separately. It lets me enable or disable pretty much every feature of the board, which has been a blessing recently. It's a perfect basis for a "tweener" system.

I use batch files to control various aspects of the system, including shoving my CT2800 away from port 330 so whatever interface card I'm using for the MT-32 can work its magic. Getting the IRQs and related resources correctly configured with a combination of PCI, PnP-ISA, and non-PnP-ISA was challenging to say the least. (ESPECIALLY because the Gravis Ultrasound's DOS installation program is a bug-ridden, deceptive pile of garbage.) I've had 5 or 6 cards in this system for a week or two, now, working harmoniously together.

I got a full height 19" rack for my main computer room, and I'm going to be creating rackmountable vintage DOS systems that each will cover a ~5 year span ranging from the 286 to the P3/P4, so that I get full coverage with no compromises. This experience with the MT-32 has beaten some sense into me. I really thought I was going to get away with 1 system. I should've known better.

Reply 392 of 608, by ab0tj

User metadata
Rank Member
Rank
Member
aquishix wrote:

Could this mean that the MIF-IPC-B has an unmentioned buffering and rate limiting feature?

No, the MIF-IPC is a simple interface to connect the MPU-401 to the ISA bus. Any "magic" is happening in the MPU itself.

Since this works with my AWE32 and gameport adapter with the system slowed down, that means Monkey Island uses UART mode. UART mode is simple: the bytes that the game writes to the MPU-401 are to be sent to the MIDI device, no further processing happens. UART mode is one place where HardMPU actually doesn't share much code with SoftMPU so I don't think it is a software version issue. The fact that it *does not* work with with the AWE32 without slowing down the system makes me think this is a timing problem. That is to say, the interface is letting MI get ahead of the MIDI stream somehow and bytes are getting lost. I have a few ideas of how this could be happening so I'll dig into the source code when I have some time.

Reply 393 of 608, by aquishix

User metadata
Rank Member
Rank
Member
ab0tj wrote:
aquishix wrote:

Could this mean that the MIF-IPC-B has an unmentioned buffering and rate limiting feature?

No, the MIF-IPC is a simple interface to connect the MPU-401 to the ISA bus. Any "magic" is happening in the MPU itself.

Since this works with my AWE32 and gameport adapter with the system slowed down, that means Monkey Island uses UART mode. UART mode is simple: the bytes that the game writes to the MPU-401 are to be sent to the MIDI device, no further processing happens. UART mode is one place where HardMPU actually doesn't share much code with SoftMPU so I don't think it is a software version issue. The fact that it *does not* work with with the AWE32 without slowing down the system makes me think this is a timing problem. That is to say, the interface is letting MI get ahead of the MIDI stream somehow and bytes are getting lost. I have a few ideas of how this could be happening so I'll dig into the source code when I have some time.

I also found this: MPU-401/Compatible UART-mode Buffer Reference

According to that chart, the MPU-401 at or above v1.3 has, in UART mode, an MPU Transmit Buffer of 256 bytes, and an MPU Receive Buffer of 1744 bytes. Could the explanation be that simple? Since UART is asynchronous, when bytes are sent too quickly over a gameport, there's data loss, but not via the UART mode on MPU-401?

But I've read that even normal UARTs have buffers; one web page claims that 16KiB - 64KiB is typical. I program in C and Java(and other languages), so I've dealt with plenty of buffered and unbuffered I/O...but perhaps not at a low enough level to see this clearly.

Reply 394 of 608, by ab0tj

User metadata
Rank Member
Rank
Member
aquishix wrote:

According to that chart, the MPU-401 at or above v1.3 has, in UART mode, an MPU Transmit Buffer of 256 bytes, and an MPU Receive Buffer of 1744 bytes. Could the explanation be that simple? Since UART is asynchronous, when bytes are sent too quickly over a gameport, there's data loss, but not via the UART mode on MPU-401?.

There's a 10k ring buffer in the HardMPU code, which is used in both UART and intelligent modes. It needs a large buffer to make SysEx delay work since it can't pause execution of the game code like SoftMPU can. It might be interesting to see if changing the buffer size makes things better or worse.

I still think it's a timing thing preventing the bytes from even making it into the buffer to begin with. But I haven't tested that theory yet.

Reply 395 of 608, by ab0tj

User metadata
Rank Member
Rank
Member

Found the problem. The way buffer was set up didn't really help anything other than SysEx delay. Anyone who has the ability to program new firmware into the Atmega that wants to try out the beta version, PM me 😁

Reply 396 of 608, by ab0tj

User metadata
Rank Member
Rank
Member

The new version of the firmware has been in use by myself and a few others for a while now, and no problems have been reported. I think at this point it is generally safe to use the new version. I have pushed the changes to GitHub, along with a new firmware binary image. All new HardMPU's will also ship with this version. Thanks guys.

Reply 398 of 608, by Cbb

User metadata
Rank Newbie
Rank
Newbie

How to update the firmware?
I've dowloaded some stuff from github and there in the BIN section I see references to avrdude, which not included in the package.
But it seem s that it's just half of the whole way so I will need to use some programmer to connect the ATMega chip to USB (?) port.
Can someone make exact instructions (like on card assembly) how to update the firmware?

Reply 399 of 608, by ab0tj

User metadata
Rank Member
Rank
Member
Cbb wrote:
How to update the firmware? I've dowloaded some stuff from github and there in the BIN section I see references to avrdude, whic […]
Show full quote

How to update the firmware?
I've dowloaded some stuff from github and there in the BIN section I see references to avrdude, which not included in the package.
But it seem s that it's just half of the whole way so I will need to use some programmer to connect the ATMega chip to USB (?) port.
Can someone make exact instructions (like on card assembly) how to update the firmware?

If you don't have an AVR programmer, you'd need one of the cheap USBASP (with 6pin adapter) programmers from eBay/Amazon/etc.
Install avrdude and drivers for the usbasp and then use the programming script to update the firmware on the card.