HardMPU, anyone?

Discussion about old sound cards, MIDI devices and sound related accessories.

Re: HardMPU, anyone?

Postby aquishix » 2018-3-11 @ 05:51

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-3-11 @ 08:07, edited 1 time in total.
User avatar
aquishix
Member
 
Posts: 161
Joined: 2018-3-10 @ 22:24
Location: Fort Worth, TX

Re: HardMPU, anyone?

Postby aquishix » 2018-3-11 @ 06:10

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?
User avatar
aquishix
Member
 
Posts: 161
Joined: 2018-3-10 @ 22:24
Location: Fort Worth, TX

Re: HardMPU, anyone?

Postby gdjacobs » 2018-3-11 @ 06:43

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.
User avatar
gdjacobs
l33t++
 
Posts: 6348
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: HardMPU, anyone?

Postby aquishix » 2018-3-11 @ 08:05

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.
User avatar
aquishix
Member
 
Posts: 161
Joined: 2018-3-10 @ 22:24
Location: Fort Worth, TX

Re: HardMPU, anyone?

Postby Great Hierophant » 2018-3-11 @ 15:52

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
User avatar
Great Hierophant
l33t
 
Posts: 2396
Joined: 2003-4-27 @ 08:20

Re: HardMPU, anyone?

Postby ab0tj » 2018-3-11 @ 19:15

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.
ab0tj
Member
 
Posts: 203
Joined: 2015-7-16 @ 16:38
Location: Colorado, USA

Re: HardMPU, anyone?

Postby ab0tj » 2018-3-11 @ 19:45

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 :lol: 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
ab0tj
Member
 
Posts: 203
Joined: 2015-7-16 @ 16:38
Location: Colorado, USA

Re: HardMPU, anyone?

Postby aquishix » 2018-3-12 @ 05:00

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
Screenshot of detailed spreadsheet.
User avatar
aquishix
Member
 
Posts: 161
Joined: 2018-3-10 @ 22:24
Location: Fort Worth, TX

Re: HardMPU, anyone?

Postby aquishix » 2018-3-12 @ 05:09

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 :lol: 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.
User avatar
aquishix
Member
 
Posts: 161
Joined: 2018-3-10 @ 22:24
Location: Fort Worth, TX

Re: HardMPU, anyone?

Postby aquishix » 2018-3-12 @ 09:29

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.
User avatar
aquishix
Member
 
Posts: 161
Joined: 2018-3-10 @ 22:24
Location: Fort Worth, TX

Re: HardMPU, anyone?

Postby keropi » 2018-3-12 @ 09:51

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.
User avatar
keropi
l33t++
 
Posts: 7077
Joined: 2003-9-08 @ 06:45
Location: Greece

Re: HardMPU, anyone?

Postby aquishix » 2018-3-12 @ 10:38

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 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.
User avatar
aquishix
Member
 
Posts: 161
Joined: 2018-3-10 @ 22:24
Location: Fort Worth, TX

Re: HardMPU, anyone?

Postby ab0tj » 2018-3-12 @ 13:42

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.
ab0tj
Member
 
Posts: 203
Joined: 2015-7-16 @ 16:38
Location: Colorado, USA

Re: HardMPU, anyone?

Postby aquishix » 2018-3-12 @ 22:56

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: viewtopic.php?t=54916

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.
User avatar
aquishix
Member
 
Posts: 161
Joined: 2018-3-10 @ 22:24
Location: Fort Worth, TX

Re: HardMPU, anyone?

Postby ab0tj » 2018-3-12 @ 23:07

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.
ab0tj
Member
 
Posts: 203
Joined: 2015-7-16 @ 16:38
Location: Colorado, USA

Re: HardMPU, anyone?

Postby ab0tj » 2018-3-13 @ 14:40

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 :D
ab0tj
Member
 
Posts: 203
Joined: 2015-7-16 @ 16:38
Location: Colorado, USA

Re: HardMPU, anyone?

Postby ab0tj » 2018-4-01 @ 21:30

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.
ab0tj
Member
 
Posts: 203
Joined: 2015-7-16 @ 16:38
Location: Colorado, USA

Re: HardMPU, anyone?

Postby cricket » 2018-4-05 @ 06:46

Hi,

sorry for the dump question, but where can I get the HardMPU PCB?
Is it being sold here?

Thanks and Regards,

Jens
User avatar
cricket
Newbie
 
Posts: 19
Joined: 2018-4-03 @ 07:06
Location: Speyer, Germany

Re: HardMPU, anyone?

Postby Cbb » 2018-4-08 @ 20:51

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?
User avatar
Cbb
Newbie
 
Posts: 37
Joined: 2017-8-09 @ 13:07
Location: Saint Petersburg

Re: HardMPU, anyone?

Postby ab0tj » 2018-4-13 @ 18:40

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, 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.
ab0tj
Member
 
Posts: 203
Joined: 2015-7-16 @ 16:38
Location: Colorado, USA

PreviousNext

Return to Sound

Who is online

Users browsing this forum: Fagear, FreddyV, root42 and 3 guests