PG-200 busy line

When building the MPG-200 for the JX-3P, I discovered that the busy line is hardwired via a pullup resistor to +5V, in effect tying it to logic high.

Because of this, I decided to ignore it altogether. But when trying to get the MPG-200 to work with the MKS-30, I discovered that this synth actually DO control the line.

So what actually happens when the busy line is pulled low?

As expected, the PG-200 does not transmit anything while the line is low. Still, I was curious what happened afterwards, when the line was released again - did the PG-200 just ignore whatever had happened during busy, did it queue up events or did it send the new stable status?

Well, a bit of both really. It keeps the last state from before it was blocked. Then, once busy is cleared, it sends first the state it had before blocking, and then the state after blocking. This happens for both switches and potentiometers.

Mmmmyeah... just one more bug.

I found the bug today. It wasn't the software - it is hardware related.

I have connected pin 2 of the midi connector to the PIC's MCLR. For some reason, when several midi messages arrive rapidly, the processor reboots. I assume it's induced noise on the line as I don't think the little phatty outputs anything on pin 2 (and it doesn't happen when just one or two messages arrive).

Fortunately, I foresaw that it could be a problem and added a solder blob jumper. After removing this the mpg-200 works as it should (but it cannot be programmed of course).

I have added a temporary normal jumper, so now things work again. I can just remove this jumper before shipping.

Btw: the midi connector didn't fit so i had to remove some of the copper and drill a new hole for the shield connector. Rookie mistake...

Stand alone prototype finished

The first fully functional MPG-200 prototype was finished and shipped yesterday. It features automatic switching between midi and pg-200 mode (with a small modification to the JX-3P), and tries to minimise the fact that switching cannot be done very quickly. In particular, it stores any note off messages received while in pg-200 mode and sends them as soon as it reverts back to midi mode.

The following features have been implemented:

• all switches and pots from the PG-200 except for write and manual
• midi passthrough - lets all midi messages not destined for the mpg-200 through
• note off protection to prevent hanging notes
• automatic switching between midi and pg-200 mode to allow full control of the JX-3p from a DAW or similar
• three modes - pg-200 only (blocks midi but keeps delay to a minimum), safe mix (mixes midi and pg-200, but ensures that no message is interpreted as the wrong type by the jx-3p by introducing a "safe time" between modes), mix (switches instantly).
• queueing of messages in case they arrive faster than the mpg200 can handle them.
• default CC-to-pg200 mapping

Still to be implemented are

• Config of CC-mapping and other parameters via sysex, stored to flash memory
• Configurable midi channel
• Autosensing of when the jx-3p has noticed a mode change
• Configurable ranges for the potmeters

The mpg-400 prototype. The "production model" will be using an 8 leg microcontroller with a built in crystal, and will be using at least 7 parts fewer than the prototype.

Ping without Pong!

Eureka! The final major mystery is solved!

Last night I got the MPG-200 working, but when I powered it up again this morning, nothing happened. It was completely dead again and the JX-3P didn't react to any of the input - just the way it has been for the last few weeks.

I opened the JX-3P again and measured the logic signals going to its microcontroller, and sure thing, they were coming through just as they did last night. Still, no reaction.

It then occured to me - what if the PG-200 sends a special message when booting up? To 'ping' the JX-3P, telling it that it's present?

I reconnected the PG-200 and this time I started the recording before turning on the power on the JX-3P. And what do you know - there, just before the first output from the PG-200 controllers, it sent two bytes: An address with the value 128 and an empty (0) data byte.

It actually doesn't send the Ping on startup, it seems it waits untill the first time a controller is changed. I have to look into it to see if this is significant. Anyway, after implementing the same scheme on the MPG-200 (or rather, just sending the Ping 1 second after startup), it works like a charm! Now the MPG-200 works every time :-D

I have however managed to consistently overloading the JX-3P by sending to many bytes. I assume that this is because I ignore the busy-line. When this happens, the JX-3P shuts down (the microcontroller at least) and it stops producing sound. It is quickly fixed by turning power off/on, but this has to be fixed.

Finally - the MPG-200 is alive!

Success at last! Tonight the MPG-200 successfully controlled the JX-3P for the first time! The current circuit uses the same japanese transistors as the PG-200, but I am still not sure that is necessary. I have tweaked the delays between the address and data bytes (the timing in the PG-200 is about 70uS between the last low of the address byte and the first low of the data byte) and between two blocks of data (PG-200: at least 17.5mS). The current delays for the MPG-200 are 91uS and 20.4mS respectively.

Now I have to get this to work with a more custom delay (or at least drop bytes instead of queueing them up, currently I get a 'delay'-effect of sorts instead of stepping. I also need to figure out how to generate bit masks for the switches. 

Almost there - MPG200

Well, I thought that tonight would be the night when I got the MPG-200 up and running with the JX-3P for the first time. Alas, I failed miserably ;-)

I've checked the output from both the MPG-200 and the PG-200, and they both output the same signals. BUT - I've forgotten that I implemented running status support on the MPG-200 (which means that the midi device generating the CC messages does not have to send the controller number again as long as it is the same controller as the previous one). The JX-3P on the other hand, does not support running messages, so it has to explicitly get a controller (or address as it is called in the PG-200 service notes) message for every data message. I have forgotten to implement this and instead just send the new controller value. Not a hard thing to fix, but missing none the less.

Here is a picture of my setup btw:

To the left is a macbook connected to a saleae.com logic probe, which I used to decode the PG-200 signals. The white square to the right of it is a prototype card/solderless breadboard, with all the necessary electronics (except for the microcontroller and associated circuitry) for interfacing the JX-3P. Behind that is my good old Mikroelektronika EasyPIC3 development kit, connected to a different PC (behind the synth). This kit holds the microcontroller. To the right of it, just beneath the big screen is the JX-3P, and below it is the guts of the PG-200 (the box is actually under it). To the far right is my Australian Redback edition Little Phatty which I only use as a midi controller in this setup.

Ask google

For a while now I've been working on the MPG-200 (Midi enabled PG-200). One of the challenges is that while midi is 8 bit serial, the PG-200 runs 9 bit. Because of this, I've been trying to use a normal output pin for transmitting data to the JX-3P, while reading midi using the built-in UART on the microcontroller (PIC 18F series).

Aside from some rather ugly code, I've had some trouble getting the "bit banging" to work fast enough - I tried to send one bit at the time through an interrupt routine, but even with almost no code in the interrupt handler, the minimum delay between invocations was higher than I needed to achieve 31.25kHz transmission.

I did successfully implement a method where data was sent in one go, with NOP instructions in between bits for timing, but that takes a full 1/4000 of a second for each byte, in which time the microcontroller cannot do anything else.

So, to try to figure out how everybody else do their bit banging (...), I asked Google. The first post I found was this: http://www.embedded.com/design/embedded/4006445/Tricks-with-PICs. Here, I discovered something cool. The PIC family can actually transmit 9 bit while still receiving 8 bit! All my problems suddenly vanished :-D

The moral of the story is: Ask google, there's always someone who has done what you want to do before you :-)