Where possible buy hardmpu card?

Is it possible to combine a hardmpu with an adlib/CMS clone on a single 8Bit ISA card?

HardMPU with Sound Blaster 1.0 and CMS.

dr.zeissler wrote on 2022-10-19, 15:42:

Is it possible to combine a hardmpu with an adlib/CMS clone on a single 8Bit ISA card?

Search for PicoGUS, it is an interesting project. Certainly you can do adlib/cms & hardmpu on the pico.

yyzkevin wrote on 2022-10-21, 02:55:

dr.zeissler wrote on 2022-10-19, 15:42:

Is it possible to combine a hardmpu with an adlib/CMS clone on a single 8Bit ISA card?

Search for PicoGUS, it is an interesting project. Certainly you can do adlib/cms & hardmpu on the pico.

Hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm. That would be a fun project.

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

Hi nathanieltolbert - wondering if my challenges with my HardMPU card might be the same as what you were experiencing and hoping […]
Show full quote

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.

Yes. You are seeing the same sort of behavior I was seeing. I have done more testing and I have found something very interesting while testing. Certain 486 VLB systems have the ability to turn off the IRQ for the VGA card, and that works great and it works with that. However if you have both a VLB video card *and* a VLB IDE/Floppy controller, then you will encounter the same issue. And unlike the VGA, you cannot disable any sort of IRQ for the IDE and Floppy controller. As far as I can tell this has something to do with the chip that allows for extended IRQ and DMA. For whatever reason 486 machines don't allow for sharing or changing IRQ and DMA, which results in the card failing. I think that it might have something to do the VLB devices taking priority when it comes to address and IRQ/DMA allocation in the system. If you are using a VLB machine that doesn't have built in IDE and floppy control, using a standard 16 bit ISA I/O controller card seems to work well, and I have tested this in the 5 boards that I have to test with. However, the instant I install a VLB I/O controller the HardMPU stops working. What is interesting is that using a Roland MPU-IPC-T card works regardless. So there must me something in the communication with the system that causes the HardMPU to not do the same as the IPC-T card does to allocate the Address, and IRQ resources. This is about all that I have been able to test. And with PCI boards I don't have much I can say. Some work fine, and others don't work at all. Strangely on a couple of my PCI 486 boards they claim to have VLB IDE controller built in and those don't appear to work. And that may be the cause. But I do know that every Socket 7 board that I have tested has worked fine. Maybe later intel chips modified resource allocation?

I built up a HardMPU-WT today, just waiting for the ATMega1284P. Can't wait to give it a go

Anyone interested in a bare PCB? I have a few leftovers. These were quite a bit more expensive than the usual fare, even from JLCPCB. Gold fingers, chambered edges.

That's a cool looking card. Does it support connecting a joystick to it or strictly MIDI using the adapter cable?

Just MIDI through the 15 Pin jack, or the wavetable header on the board. It then outputs through the 1/8" jack on the back or the 4 pin internal header.

That looks great @mbarszcz. PCB looks great and assembly is really neat and clean!

I need to build a couple more of these cards. Unfortunately, I haven't ever made my own pcb, and I don't know if I can do it. I wonder if the creator of this project has any more boards available for sale. Maybe they will have time to stop by again sometime and let us know. That board made by mbarszcz looks super cool. I see that the project for that has gerber files, but I have never made my own PCB before, and I don't know how to do it actually. I wanted to make a some snarkbarker cards back in the day, but I never got up the courage to try.

I can give you a rundown of how I had mine made and which options I used if you like.

I have 3 of them in different PCs and they're all working great.

mbarszcz wrote on 2022-12-22, 04:50:

I can give you a rundown of how I had mine made and which options I used if you like.

I have 3 of them in different PCs and they're all working great.

I saw your link to the repository. When I look at the schematics, there's a bunch of different files. Do I submit all of them to the PCB manufacturer, or is there a specific one? I just haven't done this before. I really would like to make my own card as well at some point, but I think I need to start off with an easier board layout to try to come to grips with the programs to make PCBs. I would appreciate any advice you have.

I've been porting HardMPU code over to PicoGUS. While debugging intelligent mode support, I've noticed a few things. I've been using Fredrik Pohl's Gateway by Legend Entertainment because it uses intelligent mode heavily, with IRQs and timers.

- Reading the status register on port 331 isn't implemented. Am I not understanding how it works on the HardMPU? I had to copy code over from DOSBox to get it working again.
- Initialization of tempo_rel is to decimal 40 instead of hex 0x40. This makes the tempo wrong. Is that why MPU401_TIMECONSTANT is set to 58000 instead of 60000? If anyone with an actual HardMPU could compare the tempo of the intro song for Gateway with this video, let me know if the tempo is right: https://www.youtube.com/watch?v=c3NhTcpWcf4

mbarszcz wrote on 2022-12-22, 04:50:

I can give you a rundown of how I had mine made and which options I used if you like.

I have 3 of them in different PCs and they're all working great.

I would love to get a rundown on this. I have never made my own run of PCBs before, and so any tips and suggestions is super appreciated.

Does HardMPU still require EMM386 and a 386 processor?

no it doesn't

chjmartin2 wrote on 2023-02-18, 04:13:

Does HardMPU still require EMM386 and a 386 processor?

No, it uses a microcontroller for handling SoftMPU related routines.

How do I get one?

nathanieltolbert wrote on 2022-10-21, 04:54:

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

Hi nathanieltolbert - wondering if my challenges with my HardMPU card might be the same as what you were experiencing and hoping […]
Show full quote

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.

Yes. You are seeing the same sort of behavior I was seeing. I have done more testing and I have found something very interesting while testing. Certain 486 VLB systems have the ability to turn off the IRQ for the VGA card, and that works great and it works with that. However if you have both a VLB video card *and* a VLB IDE/Floppy controller, then you will encounter the same issue. And unlike the VGA, you cannot disable any sort of IRQ for the IDE and Floppy controller. As far as I can tell this has something to do with the chip that allows for extended IRQ and DMA. For whatever reason 486 machines don't allow for sharing or changing IRQ and DMA, which results in the card failing. I think that it might have something to do the VLB devices taking priority when it comes to address and IRQ/DMA allocation in the system. If you are using a VLB machine that doesn't have built in IDE and floppy control, using a standard 16 bit ISA I/O controller card seems to work well, and I have tested this in the 5 boards that I have to test with. However, the instant I install a VLB I/O controller the HardMPU stops working. What is interesting is that using a Roland MPU-IPC-T card works regardless. So there must me something in the communication with the system that causes the HardMPU to not do the same as the IPC-T card does to allocate the Address, and IRQ resources. This is about all that I have been able to test. And with PCI boards I don't have much I can say. Some work fine, and others don't work at all. Strangely on a couple of my PCI 486 boards they claim to have VLB IDE controller built in and those don't appear to work. And that may be the cause. But I do know that every Socket 7 board that I have tested has worked fine. Maybe later intel chips modified resource allocation?

Again that is non-sense. There is no new allocations or something. To make the compatibility to work the VLB i/o board had to be exactly same design as ISA in hardware, irq and addresses as ISA so DOS and windows to work otherwise would require a IDE VLB driver for the VLB IDE chip.
If the MPU-IPC-T worked while the hardMPU failed then something is not quite right with HardMPU. This needs to be debugged properly and revise the HardMPU's hardware or firmware. There was same issue on a clone soundcard and the person who designed this found the issue in firmware for the sound card clone and fixed it.

Cheers,