Considering a HardMPU for my build: how well do these work in Windows 98? Are they detected (and useful) with the built-in MPU-401 drivers?

Yes.

tbx wrote on 2020-04-27, 04:18:

Considering a HardMPU for my build: how well do these work in Windows 98? Are they detected (and useful) with the built-in MPU-401 drivers?

I haven't done it myself, but I have been told it works without a hitch.

tbx wrote on 2020-04-27, 04:18:

Considering a HardMPU for my build: how well do these work in Windows 98? Are they detected (and useful) with the built-in MPU-401 drivers?

I've used mine in Windows 98 no problem.

ab0tj wrote on 2020-04-08, 15:01:

So I have been testing a new design...

ab0tj wrote on 2020-04-10, 03:27:

I think it'll still be a while before this one is ready for prime time, but it at least works at this point. Now it's time to test, test, test! That's the fun part

Registering my interest!

Hi. Could you please share information where can I order "HardMPU" card?

I have a HARDMPU and it mostly works great. I played through all of KQ4 and it worked flawlessly. However, I am having issues with freezing in KQ5/6. Sam and Max also hates my guts unless I slow the computer down to molasses speed at which point the game runs like garbage. I am not sure any of this is actually working out of the ordinary considering my computer is a P2 266, but even with the L1 cache disabled which slows down the computer a ton, the KQ5/6 lock ups still happen.

I didn't even realize hardmpu had a config utility until researching this, so I tried enabling sysex delay via that utility. One thing I am noticing is that sometimes after a fresh boot hardmpu.com works fine, other times I get "Timed out waiting for ACK". Based on previous responses in this thread my guess is I must have a conflict of some sort, maybe that is causing my other issues as well. I have a weird HP soundblaster clone (AZTech) but I am fairly sure it is using port 300 for its MPU interface. That MPU is using IRQ 9, but changing it to port 13 didn't change any behavior with hardmpu utility. I am not sure the IRQ conflicts matter if the port is not being used?

Any advice appreciated.

^ since you have a PII and 99,9% the board uses ACPI for power management try to go in BIOS and see if you can disable ACPI or chose to use APM.
ACPI is hard-wired to IRQ9 so it does stuff all the time and could mess with your MPU or any other card that wants to use IRQ9

I could find no settings to disable/enable anything related to APM/APCI unfortunately, but I did find settings to reserve IRQs for ISA slots, and I went ahead and reserved all of them for ISA, no idea if this helps at all. I also disabled every power related option I could find, but they were all things like "allow keyboard to turn on computer". None of this appeared to change the behavior of the hardmpu utility timeouts. Another thing I should point out is that the hardmpu utility either consistently works or consistently times out, the only thing that seems to cause the behavior to change is a reboot. Also, on a cold boot it seems to always work, so I'm wondering if me futzing with stuff and doing a ctrl-alt-delete is leaving something in a bad state and messing up my interpretation of the data.

The crashes in KQ5/6 always seem to happen when it is trying to use the SB and MT32 at the same time. Does anyone know the proper way to fully disable MPU401 on an AZTECH card? Maybe not the issue, but trying everything.

Also, anyone reading this thread for the first time to learn about hardmpu, it is fantastic. I am only having issues with three games, and I am confident it is an issue with my system, not with hardmpu itself. I probably have some hardware conflict or just an issue trying to use a P2 for this.

The hardmpu.com utility doesn't use the IRQ, so my money is on an I/O port conflict. Port 330 is the default for a MPU401, so are you sure the Aztech card isn't using that?

Hardmpu is reporting 330, Aztech mpu401 is reporting 300. But honestly, I am not sure how much I trust the aztech.

monsterbaldy wrote on 2020-05-26, 16:40:

Hardmpu is reporting 330, Aztech mpu401 is reporting 300. But honestly, I am not sure how much I trust the aztech.

330, that's what I meant 😁

What happens if you try it without the Aztech card in there?

So, I played all of King's Quest 4 with no issues, and that game ONLY uses the MT-32, it does not use the SB. All of the games I am having trouble with use both the MT-32 and the SB. I wonder if the thing to try is just to buy a different soundblaster, maybe a real one. The sound profile of the AZTech I have is kind of hissy anyways. I just don't want to do all the research... 🤣.

I spent some time messing with the AZTech settings, and if I set the IRQ to anything but 5 for the SB device it doesn't work correctly at all. I'm wondering if it is secretly also using port 330 for something even though it's configured for 300.

I tried KQ6 for a while with just the Roland configured, no soundblaster, and it seemed fine. I ordered a legit soundblaster... so when that comes I'll test and see if issue with both SB and Roland active at the same time goes away.

Update: I don't think the kQ6 locking up issue has anything to do with the hardmpu. I tried playing it for a while with just the soundblaster configured and it crashed in the same way. I think KQ5/6 just hates running on a faster machine.

There are cache controlling software out there that'll slow down the machine or other software that'll slow it down to the right speed.

Or run SoftMPU and a TSR removal software (mark before SoftMPU with delaysysex, and tsr-rem after the game exits in a batch file). Maybe that might fix it.

monsterbaldy wrote on 2020-06-07, 19:41:

Update: I don't think the kQ6 locking up issue has anything to do with the hardmpu. I tried playing it for a while with just the soundblaster configured and it crashed in the same way. I think KQ5/6 just hates running on a faster machine.

I've had issues with QFG3 running on SCI1.1, as have many people. KQ6 runs on the same generation of engine, so I'm not surprised it has issues as well.

My MT-32 does that on a Music Quest MPU401 clone card as well if the CPU is quicker than 33MHz (386 speed) with King's Quest V and VI. With the CPU cache controlling software, it slows it down to a 33MHz 386 and the MT-32 runs happily without hiccups. And this is on my 486 with a CPU that runs at 133MHz (Am5x86WB-P75).

So I setup a Pentium 133 with hardmpu and a CT2290 and I am getting some kind of conflict. Some games run fine, but others just lock up.

The hardmpu utility times out waiting for ACK. (OOPS. It's actually timing out waiting for DRR? OOPS. Nevermind it's both? Usually ACK though)
Jones, Sam and Max, Monkey Island are fine.
PQ2, Wing commander lock up.

I am guessing PQ2/WC program the MT-32 vs fire and forget? Same behavior even with l1 cache disabled.

My guess is the SB is conflicting, does anyone know the way to fully disable the SB from using it's MPU? I set the jumper to disable, but diagnose still detects it on port 330, and cannot detect it on 300. Maybe I should re-enable it and then try and set it to port 300. I did diagnose /dmpu for setup and still getting the same behavior. I am not sure that really disables the mpu vs just doesn't add explicit config for it.

EDIT: I found the root cause, it was that I am an idiot. I was going to sell the p133 and SB and forgot that I had re-enabled the MPU. Once I disabled it everything is awesome.

I thought I'd have a go at making my own PCB and the hardMPU seemed like a great place to start - It's been sitting on my to-d0 list for 2 whole years, stopped by a hard drive failure and I'm back at it again. Thank you for sharing the schematic ab0tj, it was very educational to me. Sadly I still have very little clue of what I'm doing.

I thought I'd got the board design just right and assembled it all, but it doesn't work. So today, in between watching DS9 (in the pale moonlight was excellent) and enjoying some whiskey I thought I'd take a look at it with fresh eyes. I've had lots of time to think about this in every moment away from a screen. Hopefully I've found the fault - whoops!:

These were the first two packages I placed on the schematic, sadly I didn't re-check everything before I started on the board layout. Hopefully this is the full extent of the fault, just pins 1 and 11 swapped on the 74LS374. It would make sense, there are no shorts, the MCU is programmed correctly with the right fuses set, but the ISA bus doesn't communicate to it.