Need some input from those of you folks who have worked with the VB link port before I pursue this idea further…

I’m looking into implementing the MIDI protocol over the VB link port for better in-game music. MIDI communicates using basically RS232 but at 31250bps — my question is: is the VB link port fast enough to support this, and if so is it possible to either leverage the link port hardware and set the baud rate somehow or perhaps control the data pins directly, handling the bit timing in software?

Short answer… No. I’m not familiar with MIDI, but I’m very familiar with RS232, and The link port is synchronous while RS232 is asynchronous. I can’t say that it’s IMPOSSIBLE if you’re REALLY clever, but I can’t think of any good way to make it work (especially at 31250bps).

You don’t get any manual control of the Rx and Tx lines in software… basically, you load an 8 bit register, then tell it to go… in Master mode, it clocks those bits out at 50KHz. It’ll clock them out faster in slave mode, but you’ll need an external crystal (which you could possibly make work using a crystal at 8*31250). The 8 bits are automatically clocked into a register. You do have software control of one open collector pin, but that’s not very helpful if you need bidirectional communication.

If you’re really looking for ideas to make it work, here’s a doc I’ve looked at before to do something similar on a TI DSP: http://focus.ti.com/lit/an/spra633c/spra633c.pdf . The McBSP is much more configurable than the VB link port though.

IMO, I’d use a microcontroller between the VB and MIDI to convert the synchronous signal to asynchronous… or possibly even just use an SPI UART device (the VB link port is very similar to SPI).

DogP

If your goal is to simply use the VB as a synth to compose music, it may be easier to make a soft-synth out of the VSU emulation code from RBoy or Mednafen. It wouldn’t be 100% accurate, but probably close enough to get songs made, which could then be tweaked by testing on hardware. Maybe Linus Akesson, the maker of the “Chipophone,” would like to help 😉

Otherwise, I agree with DogP, but would add that A) since (AFAIK) the VB really only has to be a consumer of messages, the controller input is another viable choice (although it’s still synchronous and very different from RS232/MIDI) and B) you could also implement a UART on the cartridge bus.

Well, I assume the VB isn’t just a consumer, since he said better in-game music… which means that the VB would have to request music to be played. And yeah… if you want to modify a cartridge, you have a lot of options, like adding a UART to the cart bus, as well as mixing the raw audio into the audio stream right on the cart.

DogP

DogP wrote:
Well, I assume the VB isn’t just a consumer, since he said better in-game music… which means that the VB would have to request music to be played. And yeah… if you want to modify a cartridge, you have a lot of options, like adding a UART to the cart bus, as well as mixing the raw audio into the audio stream right on the cart.

DogP

Well, if blitter wants the VB to generate MIDI messages to control a synthesizer, it would only be a producer and the controller port wouldn’t be useful at all…

I was under the impression that he wanted to compose VB music with MIDI instruments/software while hearing what it actually sounds like on the VB in real-time. The songs thus made would then play fine on a stock VB with no hardware enhancements. I think there was a MIDI port on the debugger unit for this very purpose, although it may have been output-only (to check the output of the VPU?) or bi-directional.

However, a synthesizer on the cart controlled by MIDI(-like) messages and mixed in with the audio would totally rock (to use a bit of a pun ;-))!

AFAIK there was no MIDI port on the debugger… do you have a link where that’s referred to?

DogP

RunnerPack wrote:
Well, if blitter wants the VB to generate MIDI messages to control a synthesizer, it would only be a producer and the controller port wouldn’t be useful at all…

Correct. The driving force behind this project is that sound on the VB– music in particular– frankly sucks. 😛 The basic idea is to make up for the VB’s lack of its own soft-synth and patches by having it drive an external synth while in-game.

DogP wrote:
And yeah… if you want to modify a cartridge, you have a lot of options, like adding a UART to the cart bus, as well as mixing the raw audio into the audio stream right on the cart.

Mixing in the audio via the pins on the cart, now there’s a good idea! Hadn’t thought of that. 😀

You don’t get any manual control of the Rx and Tx lines in software… basically, you load an 8 bit register, then tell it to go… in Master mode, it clocks those bits out at 50KHz. It’ll clock them out faster in slave mode, but you’ll need an external crystal (which you could possibly make work using a crystal at 8*31250). The 8 bits are automatically clocked into a register. You do have software control of one open collector pin, but that’s not very helpful if you need bidirectional communication.

OK… I assume that open collector pin is the Ctrl line on the link port… how is this controlled in software? David Tucker’s VB Programmer’s Manual doesn’t provide much documentation on that, and neither does the Dev Wiki at the moment… does anybody know?

IMO, I’d use a microcontroller between the VB and MIDI to convert the synchronous signal to asynchronous… or possibly even just use an SPI UART device (the VB link port is very similar to SPI).

Thanks for the suggestion– after doing some further research I think I may have found a solution with the MAX3100 SPI UART driven by a 1Mhz crystal. Now I’m not a EE/CE major– my degree is in programming– and electronics are more of a budding hobby for me, so I admit I don’t know much. 🙂 Do you think the +5v pin on the VB link port could handle a total draw of ~10mA for the entire circuit?

OK… I assume that open collector pin is the Ctrl line on the link port… how is this controlled in software? David Tucker’s VB Programmer’s Manual doesn’t provide much documentation on that, and neither does the Dev Wiki at the moment… does anybody know?

Yeah, it’s the COMCNT pin… you control it by writing to the COMCNT Control Register (0x02000004). Bit 1 is the value to write, Bit 0 is the read value. I assume you’re familiar with how open collector pins work.

Thanks for the suggestion– after doing some further research I think I may have found a solution with the MAX3100 SPI UART driven by a 1Mhz crystal. Now I’m not a EE/CE major– my degree is in programming– and electronics are more of a budding hobby for me, so I admit I don’t know much. 🙂 Do you think the +5v pin on the VB link port could handle a total draw of ~10mA for the entire circuit?

Yep… the +5V pin is shared throughout the system, and it can easily handle an extra 10mA.

DogP

DogP wrote:
AFAIK there was no MIDI port on the debugger… do you have a link where that’s referred to?

DogP

No, but I may be thinking of the SNES debugger(s)…

Here’s a first draft of my interface schematic. It’s mostly based on the MIDI electrical spec but with the MAX3100 (http://datasheets.maxim-ic.com/en/ds/MAX3100.pdf) acting as a UART for the VB. Looking for feedback on the following, forgive my ignorance on the electronics as I freely admit to being a n00b at this…

1) The numbers coming off the left side of the MAX3100 correspond to the VB link pins. Is it safe to connect these directly?

2) I’m confused what “Clock” means on the VB side… is that the clock signal, or a pin for an external clock if desired? If the latter, I’m assuming the Synch In/Out pins make up a clock signal– would it be possible to combine these to satisfy the MAX3100’s requirements? I’m aiming for bidirectional MIDI communication.

3) Is the 10K resistor a suitable pullup for the COMCTL line?

There are probably other things that need addressing/may set off some alarms… Any and all additional feedback would be appreciated before I start ordering parts. 🙂

Attachments:

1. 

   midiboy_rev1.png
   

I’m not familiar with the MIDI interface part, but the UART part looks fine. Connecting directly shouldn’t be a problem, since you’re connecting input to output, and vice versa.

The clock pin on the VB side is an input or output, depending on whether the VB is set as the master or slave for the connection. In this case, you’d need it to be master (output), since the MAX3100 needs to be a slave on the SPI bus. Also, the sync pins aren’t exactly a clock… the sync out is a 50hz signal corresponding to the mirror oscillation, and though I’ve never looked closely at it, I assume that if the sync in pin actually does anything, it syncs the mirrors.

The 10k pullup should be fine.

DogP