MT32-Pi Why?

[olsenn]

I don’t understand why a discrete mt32-pi hardware is needed for the MiSTer project; why can’t they just implement the Roland Mt-32 logic in the FPGA fabric for the applicable cores such as AO486 implements SoundBlaster in soft core? Why is a separate raspberry pi and dedicated hardware required for a little midi plugin?

[Bas]

Because it's not a little midi plugin.

[HarborSeal]

Unlike the Yamaha OPL2 and OPL3 chipsets which are used in Adlib and Soundblaster cards, there is no FPGA implementation of the MT32 available.

The only MT32 emulator available is Munt, which is used in the MT32-pi. Thankfully, Munt is open-source, so a developer that wants to implement MT32 in FPGA will have a reference to work from.

[bbond007]

I don’t understand why a discrete mt32-pi hardware is needed for the MiSTer project; why can’t they just implement the Roland Mt-32 logic in the FPGA fabric for the applicable cores such as AO486 implements SoundBlaster in soft core? Why is a separate raspberry pi and dedicated hardware required for a little midi plugin?

Even if there was a HDL implementation of of the MT-32/CM-32l it might not fit into the ao486 core. It is my understanding that the core is already near full capacity.

You can run MUNT on the HPS, however the CPU is underpowered for the purpose and there may be tempo irregularities.

[DevilHunterWolf]

Even simpler technology (compared to modern devices) can take more space than expected to replicate in FPGA. The Roland MT-32 was basically a professional synthesizer so it was no slouch in technology for its time. It could also be reprogrammed on the fly which is why MT-32 playback on a MIDI can still sound wrong even if you tried to change it for the correct General MIDI instruments. It's unfortunately not going to squeeze in to a small bit of FPGA space even if someone wanted to try to implement it natively for MiSTer. And even MT32-pi has a bit more requirements than expected. While a Pi 2 is technically supported, it struggles and needs lower quality output settings to work. That's why a Pi 3 and above are the recommended Pi devices and also why people recommend the separate Pi instead of trying to run Munt on the DE10-Nano itself.

Between the MT32-Pi's native MiSTer settings, MiSTer's own dedicated menu for control, and assembled products like the MT32-Pi Lite for cheaper and smaller devices, it's not too bad to get MT32-Pi working with MiSTer. And there's the added benefit of General MIDI support with FluidSynth on the MT32-Pi so it's possible to load up a Roland Sound Canvas SC-55 for games that support it. Those two things alone make it worth it (in my opinion) and that's before even diving into the possibilities of other SoundFonts. Doom with Sega Genesis music? Sam and Max with realistic trumpets? Why not? That's the great thing about projects like this that would be impossible if it was just a bare bones MT-32 implementation.

[dmckean]

a little midi plugin?

The MT-32 was a pretty sophisticated piece of hardware in 1987. It cost $700 which is $1800 in today's money. Replicating it would probably require it's own core. All the cores that benefit from it (AO486, Minimig, X68000, etc..) are already very large.

1280px-Roland_MT-32_Oldtype_Revision_1_PCB_View.jpg (250.74 KiB) Viewed 6308 times

[Malor]

I don’t understand why a discrete mt32-pi hardware is needed for the MiSTer project; why can’t they just implement the Roland Mt-32 logic in the FPGA fabric for the applicable cores such as AO486 implements SoundBlaster in soft core? Why is a separate raspberry pi and dedicated hardware required for a little midi plugin?

Consider that few people particularly want to spend the extra money for a Pi and an interface board, even though they aren't insanely expensive. Doing it the way it's being done is a real PITA compared to just loading a core onto the FPGA, so there must be good reasons for doing it this way.

The MT32 was a complex beast, and MUNT is the only freeware recreation that I know of. That project has taken years. It's not a simple thing at all. Doing the same thing in FPGA would be a lot harder, so someone would have to burn a noticeable chunk of their life making it work.

Remember, synths are outboard devices to most of the computers they worked with. (the IIGS's Ensoniq synth chip being a notable exception.) Games on the PC just sent serial signals to port 330, and then everything else was handled on the synth. Sending the MIDI signals to a Pi is exactly like sending them to a real synthesizer. The Pi ends up being a very tiny MT32.

The main reason to emulate in FPGA is to improve latency, but in this case, the latency is already part of the design. The MT32-Pi is a drop-in replacement for the original, and is finished and ready to go, so that's the smart thing to use. Yes, it costs $75 or $85, but it fits the use case exactly, and puts no load on the FPGA. That means the components there can be saved for emulation that benefits from low latency.

[spark2k06]

Couldn't the MiSTer Linux environment itself be used to listen via UART to what the core transmits and mount the MT32 emulation there?

[spark2k06]

I didn't say anything, I didn't realise that there is already a Munt emulator...sorry.

[Mr. Encyclopedia]

I have a MT32-pi hooked up to my MiSTer for a few reasons:

- Playing Midis in Windows 95 is very nostalgic for me, and having high-quality midi synth for PC games that support it is a huge benefit to me.
- I don't use the user port for SNAC or anything else.
- I already had a RPi3 sitting around doing nothing.

[DevilHunterWolf]

Speaking of playing MIDIs on Win95, I'm actually finding that to be the definitive way to play older MIDI files. I dug up an old backup of fan made video game music MIDI files and I found they don't always play properly on modern hardware. Some just play at double speed, for example. SoundFont playback is also unexpectedly unreliable. On my modern machine, I have the plugin for foobar2000 that uses BASSMIDI and VLC which uses FluidSynth. It's not every file but occasionally I'll come across a MIDI that will have missing instruments in one or the other. It's not just only a BASSMIDI problem or just only a FluidSynth problem. Both of them do it in different songs. But if I boot up the Windows 95 image on my MiSTer and use the MT32-Pi, they all play perfectly. No speed issues, no missing instruments, no problems at all.

MiSTer and MT32-Pi have become my best way to play MIDIs. It completes the nostalgia of playing MIDIs when proper OSTs were too hard to find and too large to store. There's probably some explanation for all the issues but I'm happy just to throw all the MIDIs into an ISO and easily load it up on the AO486 core.

[Malor]

I didn't say anything, I didn't realise that there is already a Munt emulator...sorry.

The problem with hosting it on the DE-10 is that the ARM CPU is too slow to run MUNT well.

Speaking of playing MIDIs on Win95, I'm actually finding that to be the definitive way to play older MIDI files. I dug up an old backup of fan made video game music MIDI files and I found they don't always play properly on modern hardware. Some just play at double speed, for example. SoundFont playback is also unexpectedly unreliable. On my modern machine, I have the plugin for foobar2000 that uses BASSMIDI and VLC which uses FluidSynth. It's not every file but occasionally I'll come across a MIDI that will have missing instruments in one or the other. It's not just only a BASSMIDI problem or just only a FluidSynth problem. Both of them do it in different songs. But if I boot up the Windows 95 image on my MiSTer and use the MT32-Pi, they all play perfectly. No speed issues, no missing instruments, no problems at all.

MiSTer and MT32-Pi have become my best way to play MIDIs. It completes the nostalgia of playing MIDIs when proper OSTs were too hard to find and too large to store. There's probably some explanation for all the issues but I'm happy just to throw all the MIDIs into an ISO and easily load it up on the AO486 core.

I think FreeDOS provides a really good DOS MIDI player, which I think works fine with other DOS versions. Using that in DOSBox-X running its built-in MUNT or Fluidsynth engines would probably also work well. Or you could just put it on the Mister, I think it would probably work fine there, too.

[thisisamigaspeaking]

I didn't say anything, I didn't realise that there is already a Munt emulator...sorry.

Not sure if a post got deleted that you were responding to. I believe the emulators are there on the ARM cores on MiSTer but they don't perform very well.

It does seem a little excessive I'll agree. I'm looking at the total cost of a MT32-Pi and it is getting pretty steep with the current scarcity and high prices of RPis. I'm glad I have an extra 3 B+ on hand. Damn cool to have a MT32 though, considerable how unobtainable yet widely supported they were in the 80s and 90s.

[throAU]

I don’t understand why a discrete mt32-pi hardware is needed for the MiSTer project; why can’t they just implement the Roland Mt-32 logic in the FPGA fabric for the applicable cores such as AO486 implements SoundBlaster in soft core? Why is a separate raspberry pi and dedicated hardware required for a little midi plugin?

Even outside of space considerations:

Probably because its trivial to implement via software (now, via MUNT - the work has been done), doesn't require fpga cycle accuracy (its designed for connection to a host computer via a MIDI interface which is.... lets say very old and slow).

i.e., there already exists a pretty darn good solution that is pretty cheap to implement and is usable with other platforms as well. Its probably not that it *couldn't* be implemented, but you'd need to include it in every platform's core, etc. Unlike the soundblaster, the mt32 is relevant to more than just the pc.

As above the onboard HPS (ARM cpu) struggles as its not quite fast enough to run MUNT properly in software along with whatever else it does. The ARM onboard the DE10-Nano really is quite underpowered. Seems its literally just a intended to be an OS host/bootloader for FPGA management. Which is fine, if you aren't trying to use it for things it wasn't designed for.

[FoxbatStargazer]

I will say that the overclock kernel that was floating around here, allowing you to set the ARM to 1.2 ghz, goes a long way with MUNT/fluidsynth on the HPS. It's still not quite perfect but it's much closer to making an external unit feel optional. Wish they would add that support to the official kernel.

[Malor]

DE-10 boards are scarce and expensive, so the Mister project probably doesn't want to put anyone's hardware at risk. If someone is technically adept enough to find and replace the kernel with a custom one, they're presumably clued in about cooling requirements. By forcing people to substitute their own kernels, the devs have a perfect "NO YUO!" response; if someone cooks their Nano, they've got no beef with the project. They did it wholly to themselves.

Maybe if someone coordinated with Terasic to get details on whether or not overclocking is safe, or how it could be made safe, it could end up being a default part of the project, but that seems pretty unlikely to me. Terasic is unlikely to ever give the nod to any kind of official overclock.

Right now, the only real need for the faster CPU is for MT32 emulation, and with the excellent outboard Raspberry Pi option, there's a perfect solution already available. It's expensive, but it's 100% safe.

[Neocaron]

1.2ghz would never cook the arm on the de10. The arm OC is absolutely awesome and has been stable for months and months! You get faster interface, faster unzip, faster updates, even dosbox has been brought into the very playable realm thanks to this and of course munt too. So if you can have extra ram or physical stuff in the DE-10 that were not meant to be there either, I don't see why you wouldn't allow OC on a chip that can clearly support it.

It sucks even more to not have it in main when you consider that it would help for hybrid cores. The Terasic team clearly stated that the Mister projet was already outside of the spec of the DE-10. So to say "it's not safe" is a weird line to have... There is also this idea that OC will kill things when it really doesn't. (Unless you play with high voltage and high heat but that is clearly not what we have here with the OC.)

I would also argue that extra addons are more damaging to the DE-10 or the daughter boards because you add complexity, and risk of failure.
While a safe OC just play with the current logic on the main board.

[dmckean]

One of my two MiSTers isn't even stable with the overclock. The last thing we need to be doing is adding features into Main that are only stable if you won the silicon lottery. Just no.

[Malor]

1.2ghz would never cook the arm on the de10. The arm OC is absolutely awesome and has been stable for months and months!

On your hardware. So far. It could last for years, or it could blow up tomorrow. That's the nature of overclocking.

The risk/benefit ratio may be acceptable for you, but if the project itself starts overclocking stuff, it's accepting all the risk while getting almost none of the benefit.

I would also argue that extra addons are more damaging to the DE-10 or the daughter boards because you add complexity, and risk of failure.

Plugging an MT32Pi into the machine is far less risky than an overclock.

[Neocaron]

One of my two MiSTers isn't even stable with the overclock. The last thing we need to be doing is adding features into Main that are only stable if you won the silicon lottery. Just no.

What's the amperage of your power supply? That could be the issue. Mine is 5amp.

The sillicon lottery exist to a point. I'm sure 1.1 or even 1.0 would be stable for everyone and you still get a 30% boost for pretty much any task using the arm. I understand the logic, I just think it's overzealous to be so cautious for this, when you consider all the things that we have been doing with a piece of kit not design for any of it anyway.

[Neocaron]

1.2ghz would never cook the arm on the de10. The arm OC is absolutely awesome and has been stable for months and months!

On your hardware. So far. It could last for years, or it could blow up tomorrow. That's the nature of overclocking.

The risk/benefit ratio may be acceptable for you, but if the project itself starts overclocking stuff, it's accepting all the risk while getting almost none of the benefit.

I would also argue that extra addons are more damaging to the DE-10 or the daughter boards because you add complexity, and risk of failure.

Plugging an MT32Pi into the machine is far less risky than an overclock.

Have you seen the infos about the arm chip inside the De-10? And again OC doesn't not kill anything. High voltage and heat kills electronics.

[Malor]

OCing doesn't always work. You're asking for people to be frustrated, and then they'll show up asking for help. The support burden will increase at least somewhat, and maybe a fair bit, and there's no easy way to tell how much. Further, we'll have to explain, over and over and over again, how to disable overclocking before any real troubleshooting of many complex problems can be done.

Your idea has mostly disadvantages for the project as a whole, with relatively small gains. It's a thoroughly bad idea for it to be the default choice. Those who really want to overclock can seek out a custom kernel and do it themselves. Everyone else will get a project that drives their hardware within its official specification, which is basic, sane behavior that every user has the right to expect.

[pgimeno]

The MT32 is a complex hardware with a CPU in it. It would take a fair amount of a core to build it into the FPGA; I know the ao486 in particular is pretty short in FPGA space, so it might not fit. The particular CPU used seems rare; developing a hardware emulation for that CPU is probably much more effort than doing it in software like Munt is doing.

As for OC, to me "goes a long way" does not cut it.

[Malor]

The biggest problem is the extremely short supply on Pi units. The Zero 2 W is apparently pretty acceptable for MUNT, and costs $15, so the saved expense running MUNT on the DE-10 wouldn't be dramatic. If it was easy to buy those, there just wouldn't be much need to mess around with other solutions.

[FoxbatStargazer]

It's weird how all these CPU overclocking objections don't apply to the scaler, which is being overclocked to hit 1440p and 1536p and is easily accessible even in the ini_settings, users can also freely specify higher pixel clocks with custom video modes until the chip can't keep up. I don't mind if you need to source your own script to set the ARM clock, just have the support there in the kernel and the user can go find/make the scripts if they want to or just type into the command line.