Well, you know my opinion on the power of the RPi cpu.

As for an MPU401 interface, a big part of any such design is going to be the glue logic with buffering on the ISA bus being a significant part of the IC count. The choice of microcontroller is going to be fairly incidental in the overall BOM cost. Furthermore, with LCD output and a couple of push switches for mode and reset, I'll be short of GPIO to attempt interfacing with the ISA bus.

gdjacobs wrote:

Well, you know my opinion on the power of the RPi cpu.

As for an MPU401 interface, a big part of any such design is going to be the glue logic with buffering on the ISA bus being a significant part of the IC count. The choice of microcontroller is going to be fairly incidental in the overall BOM cost. Furthermore, with LCD output and a couple of push switches for mode and reset, I'll be short of GPIO to attempt interfacing with the ISA bus.

Actually no; I was thinking on removing the glue logic and feeding the ISA signals (through level translators) directly to the pi; do the decoding in software. As for the switches and LCD, those could be moved to I2C to save on pins.

I suspect you'd be inviting problems with timing that way.

gdjacobs wrote:

I suspect you'd be inviting problems with timing that way.

That's what beta testers are for. 😀

stamasd wrote:

Actually no; I was thinking on removing the glue logic and feeding the ISA signals (through level translators) directly to the pi; do the decoding in software. As for the switches and LCD, those could be moved to I2C to save on pins.

how are you going to feed the required number isa pins to the very limited number if pi gpio pins? gpio access times on the PI is slooooooooow. you can toggle a gpio pin at like 8mhz or so in C. thats sitting in a tight loop just toggling it doing nothing else. now, io speed via PRU on the beagle bone black is order of magnitude faster.

doing everything you want to do on the arm side while hitting the pi's gpio for isa bus signals.. I could def see some wobbly timing issues maybe.

@BloodyCactus where do these speed differences come from? just looking at the technical spec of the pi, could you guess that it does max 8mhz on the io pins? if yes, would you explain how?

It comes from benchmarking. The PI might be 1.2ghz or 900mhz but thats not the speed it can hit its external bus (gpio) at. Now I think about it that was the original pi, PI2 in C you could max out about 20mhz? been a while since i looked at the pi under my scope.

This is talking raw C interface, if you use the libraries like wiringPI or python, you dont even hit 10mhz on PI2.

i see, it seems like a lot is wasted here.. at such speeds even fast PATA is not feasible i think.. so for a project like this one (as example, i was thinking about a specialized sound/multimedia (e)isa/vesa/pci device myself) except for a pure fpga, are there any solutions similar to super i/o where you could control many pins fast but still have a freedom to implement whatever protocol you desire? also it seems there is also some need to quickly convert to from analog signals, most dac/adc chips however are slow;

if you dont need an full stack OS underneath, some microcontrollers have plenty of IO and sram+rom, or yes, fpga would give you the fast pin control.

if you need lots of io at speed, yeou cant bet an fpga.

@BloodyCactus thank you for the insight 😀

I've been watching this thread - I'm interested in something similar for a retro build I'm working on. Has anyone considered the ODROID-C2? It has twice the performance of the pi and only costs $10 more. I'm sure it doesn't come close in terms of software support.

simbin wrote:

I've been watching this thread - I'm interested in something similar for a retro build I'm working on. Has anyone considered the ODROID-C2? It has twice the performance of the pi and only costs $10 more. I'm sure it doesn't come close in terms of software support.

See the thread in MT-32 general subforum. I'm working with the Odroid C2, but have ran into some issues and don't have time to deal with them right now. I did get munt to compile on it, but I can't test whether it's actually working properly.

TBH I see the Allwinner-based boards such as Orange Pi as a more suitable alternative. They aren't as fast but much cheaper, and should have plenty of power for munt anyway. I have compiled munt for Orange Pi as well, but it's also pending testing depending on what time I have. If it works that would be a $10 solution.

stamasd wrote:

simbin wrote:

I've been watching this thread - I'm interested in something similar for a retro build I'm working on. Has anyone considered the ODROID-C2? It has twice the performance of the pi and only costs $10 more. I'm sure it doesn't come close in terms of software support.

See the thread in MT-32 general subforum. I'm working with the Odroid C2, but have ran into some issues and don't have time to deal with them right now. I did get munt to compile on it, but I can't test whether it's actually working properly.

TBH I see the Allwinner-based boards such as Orange Pi as a more suitable alternative. They aren't as fast but much cheaper, and should have plenty of power for munt anyway. I have compiled munt for Orange Pi as well, but it's also pending testing depending on what time I have. If it works that would be a $10 solution.

Ah cool, I hadn't heard of the Orange Pi before. Do we still need that $50 Roland UM-ONE cable, or does another (cheaper) working cable exist?

TBH if you're planning on using a modern PC you'd be probably be better off with just using Dosbox with munt as the external munt box won't bring anything new. And if you're planning on using it on a retro box, it could be connected in any which way you want: MIDI cable from MPU401, joystick port, serial port etc.

stamasd wrote:

TBH if you're planning on using a modern PC you'd be probably be better off with just using Dosbox with munt as the external munt box won't bring anything new. And if you're planning on using it on a retro box, it could be connected in any which way you want: MIDI cable from MPU401, joystick port, serial port etc.

I have the setup you describe with DOSBox and it works great. Now I'm building a dedicated retro box with retro parts. I thought I read something about people having issues with cables other than the UM-ONE.

The Um-One or equivalent is only required if you plan to use USB. A true retro box wouldn't be using that.

simbin wrote:

Ah cool, I hadn't heard of the Orange Pi before. Do we still need that $50 Roland UM-ONE cable, or does another (cheaper) working cable exist?

I think some confusion arises because you refer to the UM-ONE as a "midi cable" when it actually is a "midi interface". The UM-One (like any other USB Midi Interface) is basically the modern equivalent of the MPU-401 - it is designed to interface midi equipment with the computer so that they can communicate correctly. Maybe what's confusing is that the UM-One comes with the cable built-in when older interfaces had to have separate midi cables plugged into them 😀

Re: using the UM-One
The Pi 2 supports using the integrated UART on the GPIO header for MIDI in/out. One must then build the isolation/current loop circuit, but this is the same as building a sound card MIDI adapter and is very well documented.

The Orange Pi may support a similar method, but I haven't looked to see if the Orange Pi is compatible with the kernel module in question.

MMaximus wrote:

simbin wrote:

Ah cool, I hadn't heard of the Orange Pi before. Do we still need that $50 Roland UM-ONE cable, or does another (cheaper) working cable exist?

I think some confusion arises because you refer to the UM-ONE as a "midi cable" when it actually is a "midi interface". The UM-One (like any other USB Midi Interface) is basically the modern equivalent of the MPU-401 - it is designed to interface midi equipment with the computer so that they can communicate correctly. Maybe what's confusing is that the UM-One comes with the cable built-in when older interfaces had to have separate midi cables plugged into them 😀

Thank you for the explanation - I was definitely confused. I'm a newbie to retro sound hardware. I just knew I needed a sound card back in the day and didn't even know about all these fancy interfaces. 😀

gdjacobs wrote:

Re: using the UM-One
The Pi 2 supports using the integrated UART on the GPIO header for MIDI in/out. One must then build the isolation/current loop circuit, but this is the same as building a sound card MIDI adapter and is very well documented.

The Orange Pi may support a similar method, but I haven't looked to see if the Orange Pi is compatible with the kernel module in question.

Now if there's just a way to have a toggle switch to select either SC-55 or MT-32 😀

The work being done on Pi and other mini computers is terrific, but I'm wondering if anyone has the skill, time and passion to write a front-end or something like that for Windows to use on a standard notebook with MIDI interface?