Just a matter of time I think. With small computers becoming more powerful, someone will build something like an Atom based wavetable board that runs Munt.

The limiting factor there would be power draw through the waveblaster connector. The average Atom dissipates more energy as heat than a Roland SCB-55/SCD-15 draws at maximum. To be compatible with the average sound card with waveblaster header, whatever approach would have to be pretty lean on power.

It would be fun to see, though... Just like the SCC-1 led to the SCD-15+MPU-401/AT, it'd be interesting to see a waveblaster successor to the LAPC-I.

Or have something like a floppy molex power connector? Maybe a future Pi will have enough power efficiency...

philscomputerlab wrote:

Or have something like a floppy molex power connector? Maybe a future Pi will have enough power efficiency...

And, hopefully, a decent enough analog audio out. IF it doesn't get removed and provide áudio through HDMI only like the BeagleBone.

One issue with putting the MT-32 in a Waveblaster form factor is that the MT-32 circuitry takes up a lot of PCB real estate. If you take the LAPC-I, you can obtain most of the essential circuitry you would need for a Waveblaster card by cutting it down the middle between IC19 and IC22. The result is still long and rather heavy by Waveblaster standards. I think it may fall off some of the shorter cards with Waveblaster headers, and you can forget about using an MPU-401AT unless you find a way to support it.

Yeah, that's a good point, GH. And it highlights how such project could be undertaken.

A straight form-factor conversion would require a LOT of reverse engineering of the connections between IC's and the IC's themselves to see what real-estate is available and what opportunities could exist for replacement by newer, more tightly integrated (but functionally equivalent) components. I've tried to find a datasheet for the LA32 chip (either DIP or QFP versions), but I haven't found one in the public domain.

An emulated approach, for example a MUNT derivative running on an embedded CPU, has the potential to be much more compact and integrated. Although, an emulated approach has it's own challenges (e.g., enough processing power, aux power, accurate emulation of all the LA32 interfaces).

In either case, with a waveblaster approach, all the MPU-401 functionality is offloaded to the host adapter... or it's just moot if installing on an external host like a DoxBox or Serdaco board. We can also safely omit any kind of amplified or headphone output and leave that to the host as well.

This makes me wonder if anyone has ever compiled MUNT for the Raspberry Pi and observed the performance on one.

QBiN wrote:

This makes me wonder if anyone has ever compiled MUNT for the Raspberry Pi and observed the performance on one.

I know someone on Overclockers Australia had it running on an Atom netbook processor.

Yo. Atom N270 with about 50% cpu usage. I believe a reasonably fast ARM Cortex processor could run it as well.

gdjacobs wrote:

Yo. Atom N270 with about 50% cpu usage. I believe a reasonably fast ARM Cortex processor could run it as well.

Nice to see you here 😀

With an eye towards using MUNT in an embedded GM/CM-32L emulator, I want to check performance on some of the cheaper options for ARM processors. I don't have access to an ARM A7 processor, but I do have ARM A9 devices.

I did some testing with DOSBOX on my RK3066 based TV box providing two A9 cores at 1.6ghz. This was with Turbo Dosbox, so a patched, single binary version. The results were almost correct. HoC ran with minor glitching on the audio output which sounded like the same buffer under runs I was getting on the Atom N270 before optimizing the binary.

At this point, I'm unsure of the quality of the compile time options used. There might be additional performance available. The biggest issue presently is that Turbo NAS does not have dual threads for MUNT as well as the DOSBOX core. I may install a chroot environment to allow me to use MUNT as I do in my Netbook, with separate MUNT and DOSBOX binaries communicating through a MIDI interface. Although this doesn't provide a great advantage to the Atom (maybe a little bit if a pipeline stalls), a proper multicore processor like the RK3066 will benefit greatly.

QBiN wrote:

This makes me wonder if anyone has ever compiled MUNT for the Raspberry Pi and observed the performance on one.

Sucks on an overclocked Pi, runs fine (but with hight CPU usage AFAIR) on an OCed PI2. The biggest issue is the atrocious analog sound output of the Pi/Pi2, as it isn't even a 16-bit ADC. Also JACK2 libary needs to be compiled from source, as the one in Raspibian's repositories are broken. Also you need to enable optimizations when compiling, as without them not even the Pi2 stands a chance.

I think that the best approach would be to use an FPGA to replicate the essential functions. There are four main chips on the MT-32/CM-32L, the Microprocessor, the Bus Interface Unit, the LA32 and the Reverb chips. There is also a DAC chip. In addition, you would need ROM and RAM and voltage level adapters considering the capacity of the FPGA you would have to use.

Why would this be the best approach? It is much easier to replicate hardware with hardware than with software. With the FPGA, you can reconfigure it to fix bugs.

Certainly, an FPGA would be a great way to implement MT-32 in a daughtercard form factor. With MUNT and GM/GS being essentially off the shelf software solutions, MT-32 and SC-55 can be installed in the space of a 5.25" drive while avoiding reinventing the MT-32 in Verilog.

the main problem with such cool projects is that they need people that have both the motivation and knowledge to design the boards and write the software... the more complex the project the more difficult to find such people ... and this one is a complex project.

And FPGA developers are quite rare comparatively.

This is an idea:

Get the enclosure from a busted CD/DVD drive, use some plastic/rubber/tape to isolate the inside, fixate the components (and zip-tie stuff like the UM-ONE), make a cable with a female DIN conector and use a perfboard (or etch a simple board) with a molex connector (for power - as I do not trust getting it from the sound card) and a waveblaster connector. Install MUNT, configure its ALSA server and aconnect to bridge the MIDI in to MUNT and have that start automatically. Then just run a flat cable from the drive to the sound card. Oh, and you might need to add a little buffer opamp for the line out, taking advantage of the waveblaster's 12V and -12V line and put a decoupling capacitor between the USB sound card's line out and the IC. Oh, and using an optocoupler between the header's MIDI pin and the UM-ONE's MIDI input is probably needed as well.

IMHO making it an extarnal module would be more useful, even replacing the UM-ONE with something like this, adding a Line Out jack and a separate power brick.

My ex was (maybe still is) a FPGA developer but he since changed scope of his professional life when there were no job positions that required such skills in his area.

I also wonder, how good are compilers and their optimizations are on ARM architecture anyways?

The advantage of the software approach is that you can also install Timidity on Linux and switch between MT32 mode and GM + nice Soundfont. I did this with an old Pentium M laptop, and works fine, I just need to set up a way to automate switching between the two modes.