MiSTer FPGA Forum

Hello, new member here. Also a relatively new MiSTer user, with just a couple months under my belt.

Not sure about gate array size or other system limitations, but I had the idea of adding a midi device to the audio output leg of applicable system cores. Once the MIDI device core is mapped, it may be easier to implement into the correct cores.

I like the MS32-pi as a device solution, but it's not entirely necessary if we have room on the FPGA, plus downstream audio mixing can happen before the physical output. Additionally, the device doesn't need to be swapped for cores that can not take advantage of MIDI.

Benefit: MIDI audio is a hugely upgraded experience anywhere it is applicable. This makes the upgraded experience the default for all users on relevant cores.

Just tossing the idea out there for discussion.

The only known reverse-engineered 100% accurate MT-32 project I'm aware of would be prohibitively large to put in FPGA even if not shared with another functional core. I just don't see how it'd fit into the MiSTer (from a LE perspective).

I would like to see various MIDI synth dedicated cores (Roland, Yamaha, etc.). Hook up a USB MIDI adapter and a MIDI keyboard, etc. controller to use it. If it has physical buttons, put those on the screen and use a mouse to click them or assign computer keyboard keys.

How many components is the MT-32?

Alpha434 wrote: ↑Tue Dec 24, 2024 6:37 pm

How many components is the MT-32?

LEs? Won't know until someone creates it. Total implementation complexity? Based on https://github.com/nukeykt/Nuked-SC55, I'd wager rather high. It is currently the gold standard for emulation accuracy.

Nukeykt is working on a low-level MT32 emulator similar to Nuked-SC55.

https://x.com/nukeykt/status/1860025870712471655

HarborSeal wrote: ↑Tue Dec 24, 2024 9:41 pm

Nukeykt is working on a low-level MT32 emulator similar to Nuked-SC55.

https://x.com/nukeykt/status/1860025870712471655

This might be better if you can't get MIDI to fit on the FPGA core if you can get the emulation into the Mister operating system instead.

Why would midi require or even benefit from FPGA simulation? Sure audio is timing sensitive but is there really that much there in old synth modules that a recent Pi wouldn't handle just as accurately? You're not really getting analogue synth hardware from an FPGA anyway, right?

Bas wrote: ↑Mon Dec 30, 2024 10:06 pm

Why would midi require or even benefit from FPGA simulation? Sure audio is timing sensitive but is there really that much there in old synth modules that a recent Pi wouldn't handle just as accurately? You're not really getting analogue synth hardware from an FPGA anyway, right?

Of course you're correct, hence the MT32-pi. I think the concept here is potentially not needing an external device at all.

rhester72 wrote: ↑Mon Dec 30, 2024 10:11 pm

Bas wrote: ↑Mon Dec 30, 2024 10:06 pm

Why would midi require or even benefit from FPGA simulation? Sure audio is timing sensitive but is there really that much there in old synth modules that a recent Pi wouldn't handle just as accurately? You're not really getting analogue synth hardware from an FPGA anyway, right?

Of course you're correct, hence the MT32-pi. I think the concept here is potentially not needing an external device at all.

That's my ideation, as well as better integration in general. Something that I've seen commented is that people who added the mt32-pi to their mister don't often use them because of the additional hassle of plugging it in. If MIDI is integrated, either into the FPGA or ARM side, then the user experience improves for everyone and the mister is a better product.

I'll just put this on my personal wishlist next to Retrotink 4k-style upscaling. Maybe a high definition sound and video daughterboard instead of the analog board is my direction, since I use my mister to play on a 98" flatscreen.

ARM isn't viable - even overclocked, software MUNT results in very noticeable dropouts, which is how the user port solution came to be in the first place. You hit a LE wall (and noticeable absence of any FPGA code!) trying to do it in-core (because it would have to sit astride the actual core you want to use it), which is why I don't think it can happen.

rhester72 wrote: ↑Wed Jan 01, 2025 3:37 pm

ARM isn't viable - even overclocked, software MUNT results in very noticeable dropouts, which is how the user port solution came to be in the first place. You hit a LE wall (and noticeable absence of any FPGA code!) trying to do it in-core (because it would have to sit astride the actual core you want to use it), which is why I don't think it can happen.

Doesn't the MT32-pi use the raspberry pi's arm chip to emulate?

It's possible my original solution is still the best, but with waiting for the DE25 chip and just limited to workarounds for the current mister hardware.

Sure does, and I guess rhester72 meant the ARM on the MiSTer. That's quite underpowered compared to the later Pi iterations. My Pi4B runs MUNT without breaking a sweat, plays the intro to Space Quest III without a hitch. Compared to a real MT-32 it even sounds less noisy.

Bas wrote: ↑Thu Jan 02, 2025 8:44 pm

Sure does, and I guess rhester72 meant the ARM on the MiSTer. That's quite underpowered compared to the later Pi iterations. My Pi4B runs MUNT without breaking a sweat, plays the intro to Space Quest III without a hitch. Compared to a real MT-32 it even sounds less noisy.

I do understand the mister's arm processor is limited. Maybe it's a daughter-board solution that sits where our analog I/O boards are.

There are cases that slap a Pi Zero 2W on the side for a very snug setup. That would have been my plan if the Pi4 wasn't already in my box of assorted nerd goodies. We should give at least some credit to the MiSTer ARM: it's dual core, but one core peaks at a steady 100% use when running a core. Any Linux "housekeeping" will glitch MUNT on the remaining core if it's strained.

How does your mt32 pi do downstream audio mixing? Do you need to disconnect stuff when you change to a non-midi core?

There are no issues with simply keeping the mt32pi connected at all times. Mine is and I'm just using the console cores most of the time. When a core is using the mt32pi, the audio from the mt32pi is transferred over the "fake USB" port on the MiSTer and audio mixing "just works".

Yeah - tbh the only reason not to keep it connected always is to use SNAC adapters (which I actually do quite a bit).