Okay I am dealing with a really weird issue. I have made three of the five cards that I have the parts for. I have tested and confirmed that all three of them are working on a Compaq Presario 2240, which is an AMD K6-233MHz MMX machine with Windows 95. However, whenever I try configure them for some 486 machines, I get an error about timing out waiting for ACK. The cards are configured as I/O:330, IRQ:2/9. I tested all three cards on two separate machines, one of them based off of the UMC 8498/8496 Chipset and the other is an NCR System 3230. What is strange is that both machines work with my MPU-IPC-T card set to the same settings. I'm at a loss as to why I can't get them to work. Neither of the machines have any of the adapter ranges shadowed, and both machines show the 8259A on both IRQ2 and IRQ9. I tried changing the I/O port from 330 to everything else along with the jumpers, what is strange is even though I changed the I/O jumper when running the HardMPU.com it always tries to query the 330 port. I would have thought that I had soldered the cards poorly, but they all work just fine on the Presario 2240 though. I don't know what else to try. So I thought I would ask here and see if there was any suggestions that others who are using these cards can help with.

nathanieltolbert wrote on 2021-09-10, 22:35:

Okay I am dealing with a really weird issue. I have made three of the five cards that I have the parts for.

This usually means something else in the system is using port 330 or IRQ 9. Is there a sound card installed?
When running the config utility, you need to specify the port if it is not set to 330. e.g. 'hardmpu -p 320'. Note that using any port aside from 330 breaks compatibility with a lot of (or most?) games.

Original Sierra On-Line games had issues with MPU-401 cards being set to anything other than 330h. I know later VGA variants has a patch program to change the MPU-401 address from 330h to 320h or what-have you.

I'll look up more info about some games and post an update.

ab0tj wrote on 2021-09-11, 00:39:

nathanieltolbert wrote on 2021-09-10, 22:35:

Okay I am dealing with a really weird issue. I have made three of the five cards that I have the parts for.

This usually means something else in the system is using port 330 or IRQ 9. Is there a sound card installed?
When running the config utility, you need to specify the port if it is not set to 330. e.g. 'hardmpu -p 320'. Note that using any port aside from 330 breaks compatibility with a lot of (or most?) games.

I thought about that, I removed the sound card and so there was nothing consuming the 330 port or IRQ2 or IRQ9. It did not change anything. When I try to configure it for any other port it still reports I/O of 330 regardless of what I put in the hardmpu -p xxx setting. What's really strange is I cannot get it to work with any of my DOS pcs. But all three work fine in a much later machine. I'm scratching my head. It's like the 8259A chip is not willing to share the IRQ with the MPU card. I can't help but think I have configured something wrong somewhere on the board, but the NCR System 3230 doesn't have any jumpers to configure anything, and it has the exact same issue. Just not sure what to do. The cards work great in windows 95 machines, but I was hoping to use them in my DOS 6.22 machines. A side note. The Roland MPU-IPC-T set to the same settings works perfectly fine in both machines, which doesn't make sense to me at all.

-edit- I forgot to note, that I did change the jumper on the HardMPU to reflect the I/O change as well, so 310, 320, and 300 were all set with jumpers as well as trying to run the HardMPU set up as well.

Okay So even with just an AWE32 card in the machine, on games that have always worked with using the aweutil /em:GM get no music. But the games don't lock up. So something on the board must be a setting on the motherboard. Maybe there is a jumper set for IRQ9 for the integrated video card that needs to be disabled? I need to find all of the jumpers for this motherboard, which is a very weird motherboard.

Are these HardMPU-boards cheaper than the PCMIDI from keropi? I ask because I need one or two for my PCs and I only have one PCMIDI and cannot afford another one at the moment 😀

Storm82 wrote on 2021-09-14, 07:34:

Are these HardMPU-boards cheaper than the PCMIDI from keropi? I ask because I need one or two for my PCs and I only have one PCMIDI and cannot afford another one at the moment 😀

Keropi's project is sweet, but these boards have no hidden special sauce burned into the GAL chips. This means you can hack it in new and interesting ways if you want.

Sounds great, compatibility-wise it's the same as keropi's (intelligent mode) ?

They do indeed have intelligent mode.

Okay further testing has been done. I have checked the same machines now with my MPU-IPC-T card and it works in all of my 486 machines, but I cannot get my HardMPU cards to work. I have tested all of the HardMPU cards that I put together and they work in every Pentium or higher machine that I have, including custom built machines and pre-built machines. I am at a loss, because other people are not having these issues at all, so I recognize that it is something on my end, but I cannot isolate what is causing the Time out waiting for ACK. I am guessing that ACK means it sends a HELLO to either the I/O of 330 or the IRQ of 2/9 and it does not get a Acknowledge back from either the IRQ or the I/O port. I'm scratching my head. I am also wondering if the way that the MPU-IPC-T card pulls the I/O port and IRQ is different than how my HardMPU card connects to those resources. The cards work, and in the machines that they work in, they work absolutely fantastically. I just cannot get mine to work in my 486 computers, and I know it's something for me, because it appears from people conversing here they are getting them to work in 286, 386 and 486 machines just fine. It's just me. As I always say, if it weren't for bad luck, I would have no luck whatsoever. 😁

Is it possible to provide the gerber files for this project?

Thank you.

Has anyone had any luck getting in contact with ab0tj? I tried to PM him regarding posting gerbers or even buying a PCB but got no response. To my knowledge there is currently no way of acquiring a PCB for this lovely project

Yet another bump;following this thread in case any gerber files pop up!

This project looks like it has gerber files: https://github.com/PickledDog/hardmpu-wt

tyrells wrote on 2022-05-06, 00:11:

This project looks like it has gerber files: https://github.com/PickledDog/hardmpu-wt

Thanks!

I figured out why the MPU card isn't working in my older machines. It's specifically the VLB and specific PCI machines. It's the Video card. For whatever reason, when the Video card pulls an IRQ, the MPU card won't work. BUT!!! If the BIOS allows me to disable an IRQ for the VGA card, it will work. At least on the PCI 486 systems. I do not know if I can disable the IRQ for the VLB card or built in VLB. But I am wondering that if I do, will it work? So, progress! Thank you so much for creating this design. I need to buy more boards and chips and make several more of these cards. They are great.

nathanieltolbert wrote on 2022-07-14, 18:26:

I figured out why the MPU card isn't working in my older machines. It's specifically the VLB and specific PCI machines. It's the Video card. For whatever reason, when the Video card pulls an IRQ, the MPU card won't work. BUT!!! If the BIOS allows me to disable an IRQ for the VGA card, it will work. At least on the PCI 486 systems. I do not know if I can disable the IRQ for the VLB card or built in VLB. But I am wondering that if I do, will it work? So, progress! Thank you so much for creating this design. I need to buy more boards and chips and make several more of these cards. They are great.

Hi nathanieltolbert - wondering if my challenges with my HardMPU card might be the same as what you were experiencing and hoping you can share a little more information about how your HardMPU behaves.

I've used my MT-32 with DOSBOX and a UM-ONE USB adapter on my regular desktop, and everything worked as expected.

I purchased a pre-made HardMPU v2.0 board from a popular auction site last year for use with a newer MT-32 unit, but I've never had any success in getting it to operate properly. There are signs that the unit is working, but I've never been able to get it to function to drive the same MT-32.

When I power on the MT-32 and then power on the PC with the connected HardMPU card, there must be some communication happening as the display on the MT-32 displays "*** HardMPU ***". The problem is that I can't get the MT-32 to function with any software, and even the HardMPU configuration utility appears to only intermittently can communicate with the MT-32. When repeatedly running the utility, I receive a "ERROR: Timed out waiting for ACK." message upon execution the majority of the time, however every so often, it will return the status screen.

I spoke briefly with the seller at the time, who had recommended verifying no IRQ/address conflicts and disabling ACPI and switching to APM, if possible, to try and avoid conflicts.

I've done that to the best of my abilities by removing the majority of the add-in boards (including the existing sound card) and configuring the remaining boards to avoid conflicts in my old AT&T 486 system (same as described in this https://www.youtube.com/watch?v=OOIABeSrLfU) video. The system is an older 486 with a Cirrus Logic VLB VGA card and lacks PCI slots or more advanced power management. Being short on time, I gave up on it at that point and figured it may have just been an incompatibility of some sort.

More recently, I've also tried the board in my NuXT Rev C 8088/V20 computer, and, unfortunately, it behaves in the exact same manner despite being a significantly earlier system. This system has a Trident VGA card and built-in XT IDE adapter, but there isn't much else for a conflict to exist. In the NuXT, I've tried changing the IRQ and memory address for the HardMPU card and modified the HardMPU command line accordingly, but still get the same behaviour. I expect the same results with applications but understand that most of the MT-32 compatible applications are likely hardcoded to look for an MPU-401/MT-32 on the default IRQ2/330h address --- tried my hand at modifying the Turbo Pascal source and recompliing Scott Baker's Roland MPU-401 Intelligent MIDI Player project (https://github.com/sbelectronics/midiplay), but was not able to get this to work with either the defaults or the modified IRQ/memory addresses to match how the board is configured.

Just wondering if this type of behaviour is similar to what you were seeing or if any of the community members might have any ideas.

CB27044 wrote on 2022-09-19, 15:04:

Just wondering if this type of behaviour is similar to what you were seeing or if any of the community members might have any ideas.

As this might affect the MIDI communication to the device and since I didn't see you mention anything about this: are you using a proper adapter cable (i.e. one that isolates via optocouplers) to connect from the card to the MT-32?
If you can trace the midi signal pins from the DB-15 to the DIN, then this might be worth changing out (and would also explain why it's working with the USB adapter cable).

MJay99 wrote on 2022-09-19, 16:29:

CB27044 wrote on 2022-09-19, 15:04:

Just wondering if this type of behaviour is similar to what you were seeing or if any of the community members might have any ideas.

As this might affect the MIDI communication to the device and since I didn't see you mention anything about this: are you using a proper adapter cable (i.e. one that isolates via optocouplers) to connect from the card to the MT-32?
If you can trace the midi signal pins from the DB-15 to the DIN, then this might be worth changing out (and would also explain why it's working with the USB adapter cable).

Thanks, MJay99.

Good idea --- I didn't give any thought to the fact that it could potentially be a cabling issue. I am using the cable that was supplied by the seller with the HardMPU card when connecting the MT-32 to the HardMPU interface - it looks like a custom DB9 (M) with a 5-pin DIN (F) labelled "IN" (not used) and a 5-pin DIN (M) labelled "OUT" that is connected to the "IN" on the MT-32. I haven't opened the hood on the DB9 side, but guessing that the cable is wired as outlined in the build instructions (https://github.com/ab0tj/HardMPU/raw/master/B … e%20HardMPU.pdf). Since the Roland UM-ONE is its own cable and seems to work, I'll double-check the continuity to confirm the PINs on the cable are as expected, but I am not sure whether the design incorporates the type of circuit isolation you were describing.

Thanks!

My, it's already been a bit since I built one of these and I seem to have forgotten that optocouplers are specified for the RXD and not for the TXD side.
So, your cable, if built according to the PDF, should actually be fine and working, though it never hurts verifying the simple things, of course.

Re-reading your message though, I found this part now (which really disqualifies my first idea about the cable):

"The problem is that I can't get the MT-32 to function with any software, and even the HardMPU configuration utility appears to only intermittently can communicate with the MT-32. When repeatedly running the utility, I receive a "ERROR: Timed out waiting for ACK." message upon execution the majority of the time, however every so often, it will return the status screen."

Looking at the code, the config tool seems to mainly be trying to read from the port given to it (either its default of 330 or the explicitly given port via the command-line:

1void show_help(char *name) {
2    cprintf("Initializes the HardMPU card with the given options.\r\n\r\n");
3    cprintf("Usage: %s [-p (port)] [-dfgsh]\r\n\r\n");
4    cprintf("  -p: Specify port number (default 330)\r\n");
5...

1void wait_for_ack(int port) {
2    time_t timeout = time(NULL) + 4;
3    for (;;) {
4        while (inp(port+1) & MPU_DSR) {
5            if (time(NULL) > timeout) {
6                cprintf("ERROR: Timed out waiting for ACK.");
7                exit(1);
8            }
9        }
10
11        if (inp(port) == 0xfe) break;
12            
13        if (time(NULL) > timeout) {
14            cprintf("ERROR: Timed out waiting for ACK.");
15            exit(1);
16        }
17    }
18}

So, if you're 100% sure that no other (network) card, soundcard, etc. uses the address configured for the HardMPU (either its default of 330 or any other jumpered one AND the correct address is given to the config tool), then the hardware or flashed firmware of the card might move into question... but an occasionally shown status of the card might indicate an address conflict more than a hardware issue to me.