VOGONS


HardMPU, anyone?

Topic actions

First post, by ab0tj

User metadata
Rank Member
Rank
Member

So, we already have the very awesome SoftMPU for intelligent MPU401 operation. But some people (like myself) for some reason prefer a hardware solution. So, here is my idea. Create a port of SoftMPU that runs on a microcontroller, and put it on an ISA card. Instead of the port trapping technique used in SoftMPU, read and write directly from the ISA bus. And, instead of using the UART MPU on a sound card, use the UART on the microcontroller to directly send and receive MIDI data. Basically an MPU-401 clone that should in the end cost under $100.

Creating the hardware wouldn't be very difficult with a microcontroller that has enough GPIO pins. But I may need some help with the firmware, or even better if someone who is a better programmer than I stepped up to write the firmware. I would want to keep it open source so the community can build their own, but also maybe offer PCBs and/or kits for sale to the community.

It's just a crazy idea I've been toying around with. Would anyone actually be interested??

UPDATE 8/22/16 - HardMPU seems to generally work at this point. Bug reports and new code are welcomed. SysEx delay works differently than SoftMPU due to not being able to block the host machine's code execution like SoftMPU can. The delay seems to work for games that need it, but breaks others (that don't need it anyway). You can find the current code and binaries here: https://github.com/ab0tj/HardMPU/

UPDATE 2/7/18 - I generally don't have time to make kits or built boards available "to order" right now, but I do have bare boards available (PM me) and will be listing built boards on a popular auction site as I have time to build them.

Last edited by ab0tj on 2018-02-07, 22:29. Edited 11 times in total.

Reply 1 of 608, by alexanrs

User metadata
Rank l33t
Rank
l33t

This would be very useful for pre-486 or pre-386 machines. IMHO the starting point would be creating a dumb UART MIDI controller using a PIC or an AVR, and once that is working fine just develop an Intelligent MPU firmware for it. As long as the microcontroller is powerful enough, it should work. After that, the sky is the limit xD Even adding a wavetable header shouldn't be hard.

Reply 2 of 608, by dogchainx

User metadata
Rank Member
Rank
Member

I'm always for these types of projects, no matter if they end up being completed or not. It may have been your, or someone else, that has had a similar idea a while back. I can't remember the specifics, but was very similar.

I'll support the project with a thumbs up for now until more specifics are figured out. Compatibility, bugs, unforeseen complications, etc...

EDIT: As was mentioned above, a wavetable header would be AWESOME. MPU401AT clone?

386DX-40MHz-8MB-540MB+428MB+Speedstar64@2MB+SoundBlaster Pro+MT-32/MKII
486DX2-66Mhz-16MB-4.3GB+SpeedStar64 VLB DRAM 2MB+AWE32/SB16+SCB-55
MY BLOG RETRO PC BLOG: https://bitbyted.wordpress.com/

Reply 3 of 608, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie

I've been thinking about putting a microcontroller to MIDI cable between PC and sound module so it could basically perform some of the MPU intelligent mode stuff while only physical dumb uart is needed on PC. But I understand it would not compare to the real thing and would not see the resets to intelligent/dumb modes, and all I really needed was a device with buffer so it can insert suitable delays to SYSEX commands, because my MT-32 does not work in ScummVM properly, I get overflow on MT-32.

Anyway, this is quite doable, but I do not recommend specifying the microcontroller yet (I'd prefer something more modern and 32-bit). You need some 74xx glue logic to decode IO port accesses and store data in latches between microcontroller and ISA bus. That could be done with a CPLD easily, and also the CPLD could perform the dumb uart mode easily as well without the microcontroller.

But hey, you can already get clones of the MPU-IPC ISA card, so only thing left is to build your own version of MPU-401 metal box insides.

Reply 4 of 608, by ab0tj

User metadata
Rank Member
Rank
Member

Agreed on all of the above. A wavetable header should not be hard to add. Some glue logic would indeed be necessary but none would be very complicated. I've never worked with a CPLD but it shouldn't be difficult to implement in 74xx logic either.

I think I will start looking over specs and datasheets to get together some sort of plan for the hardware end of things.

Reply 6 of 608, by ab0tj

User metadata
Rank Member
Rank
Member

I did see keropi's post on making a replica card. It seems to be on hold at the moment however. I do wonder if going this way would be better though... No copyright issues to deal with, and new features can be added as necessary since it would be open source.

I would probably invest in one of your replicas if you made more. I do intend on getting a real MPU-401 at some point, and as you well know, they usually don't come with the card.

Reply 7 of 608, by PhilsComputerLab

User metadata
Rank l33t++
Rank
l33t++

I'd suggest another angle that is not as sophisticated as SoftMPU, but still could get most games to run.

When you work with Ensoniq sound cards you notice, apart from shocking FM, that many MT-32 games that wouldn't load before, do work with Ensoniq cards. Now the instruments will all sound off, but the game will load.

This is something in the Ensoniq driver. Someone would likely know more information about this, but some games wait for a response from the MPU401, and if there is no response, they wait for ever and all you get is a black screen.

Ensoniq driver sends this response, thus enabling a wide range of games to load up fine.

The other point I would like to make is that for a hardware solution, it should be a proper hardware solution, not running SoftMPU on hardware, which IMO is silly, as you can just run SoftMPU. It also means that any potential bugs, the Gateway bug comes to mind, will also be present in this solution.

YouTube, Facebook, Website

Reply 8 of 608, by keropi

User metadata
Rank l33t++
Rank
l33t++

music quest clone mpu is happening, cards might not originate from Greece but it's happening

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

Reply 10 of 608, by alexanrs

User metadata
Rank l33t
Rank
l33t
philscomputerlab wrote:

The other point I would like to make is that for a hardware solution, it should be a proper hardware solution, not running SoftMPU on hardware, which IMO is silly, as you can just run SoftMPU. It also means that any potential bugs, the Gateway bug comes to mind, will also be present in this solution.

Isn't that basically what true Intelligent mode MPU-401 interfaces do (but with propertary circuitry/firmware)? The advantage of a hardware solution is that no EMM386/QEMM would be needed, thus enabling it to be used by games that do not work in protected mode. Also it would be perfect for older 386/286/XT machines, just like normal interfaces. Also, one of those with a wavetable header might be a good (and reasonably priced + actually available) way to finally solve that old SB16 "pick your poison" dillema : no way to get good SnR, bugfree MPU, a wavetable header and true OPL3 at the same time.

Keropi's Music Quest clone might also be extended to support a wavetable header, though, and that could be a nifty alternative. And if all one wants is a bugfree wavetable header all that is needed is a UART board, which shouldn't be that hard to implement with a microcontroller.

Reply 11 of 608, by ab0tj

User metadata
Rank Member
Rank
Member

Isn't that basically what true Intelligent mode MPU-401 interfaces do (but with propertary circuitry/firmware)? The advantage of a hardware solution is that no EMM386/QEMM would be needed, thus enabling it to be used by games that do not work in protected mode. Also it would be perfect for older 386/286/XT machines, just like normal interfaces. Also, one of those with a wavetable header might be a good (and reasonably priced + actually available) way to finally solve that old SB16 "pick your poison" dillema : no way to get good SnR, bugfree MPU, a wavetable header and true OPL3 at the same time.

Keropi's Music Quest clone might also be extended to support a wavetable header, though, and that could be a nifty alternative. And if all one wants is a bugfree wavetable header all that is needed is a UART board, which shouldn't be that hard to implement with a microcontroller.

That was my thinking, as well. Sure, you can run SoftMPU on the machine, but that comes with certain limitations. I don't really see how it's not a "proper" hardware solution. And in this case we can duplicate some of the nice features SoftMPU has, like delayed SysEx.

Reply 16 of 608, by ab0tj

User metadata
Rank Member
Rank
Member
PeterLI wrote:

Cool. Keep us up to date. I am sticking with MIFs for now. Somewhat irrational but fun as well.

Will do. That's pretty much why I am going after this project, too. Somewhat irrational but fun anyway.

So far it seems pretty straightforward. I ordered an ISA photo board and a bunch of chips so I can try out some designs. Right now I'm mainly trying to sort out if a PIC chip at 32MHz will be fast enough to keep up with ISA bus timings, or if I need to add extra latches for the data (330h) and control (331h) ports. If it is fast enough, the card will basically be a MIF-IPC-A with a PIC chip attached to it.

Reply 17 of 608, by alexanrs

User metadata
Rank l33t
Rank
l33t

If you remember that the ISA bus runs at about 8MHz, having only four cycles per bus clock might be cutting it a bit too close. If memory serves me right, a read or write operation with no wait states takes four bus cycles, so you need to be sure to have the entire thing using less than 32 instructions. If you factor in Intelligent stuff, this might just be too little.
I'd try something slightly different. I'll try drawing something to help explain what I'm thinking, will post again soon.

Reply 19 of 608, by alexanrs

User metadata
Rank l33t
Rank
l33t

IMHO one drawback of that design is that the PIC still has to stop anything it is doing whenever someone reads from the STATUS port. This might be okay for UART, but I'm afraid wasting the PICs time doing that will cause trouble in Intelligent mode. This is a VERY rough drawing, just something I "scribbled" on PowerPoint. I guess that the example you provided could be adapted to what I'm thinking with the addition of another read latch specifically for the STATUS port, and I liked the way the address decoding is done there.

I made this drawing before really taking a look at that and without really taking a lot of things into account, as I just wanted to explain the what is in my head. The way I envisioned it, you can just update the STATUS GPIO ports during operation and the latch will do the job of returning it to the PC whenever someone reads it, without interrupting the PIC. I also imagine the software having two "queues". The three lines there (PORT&READ|WRITE) should trigger interrupts. Writing either commands or data would put them on the output queue, whereas trying to read from the data port would retrieve the "front" byte in the second queue (and update the STATUS port if the it is empty). The firmware's main loop would then verify if there is incoming data on the MIDI input port and add whatever arrives to the queue (and set the STATUS GPIO pins accordingly) and process the output queue (process commands and pass data through).

Oh, and i forgot about the interrupt. It would take another GPIO pin and a few jumpers to connect it to the desired IRQ. Then the firmware would need to assert it whenever it wants to trigger an interrupt.

Hope all this rambling made some sense and was helpful. I admit I did not research much before conjecturing this, and I'm relying a bit too much on my memory about how this stuff works.

Untitled.png
Filename
Untitled.png
File size
22.13 KiB
Views
16825 views
File license
Fair use/fair dealing exception