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.

Fooled by running status. Again and again.

The midi protocol is not very complex. But one thing keeps making me trip: Running statuses. You can send a status byte, and as long as you don't send a new status byte you may keep sending data bytes for the same status. This is very convenient when sending for example filter sweeps etc.

In my work on the MPG-200 this has made me trip several times. Because:

The source for my midi data has mostly been my Moog Little Phatty. It sends running statuses of course. But when I reboot my mpg-200 without restarting the LP or playing a note, the LP don't send the status message again, and the MPG-200, having just booted, has no way of knowing what it is receiving as it has not seen any status message. It has fooled me more than once.

Today it happened again, but in a more subtle way. I have spent the last week trying to figure out a very strange bug I noticed after a large refactoring of the MPG-200 code: After changing the CC for the filter cutoff using sysex, things worked fine when sending the correct CC from my sysex/web midi based pg-200. But after rebooting nothing worked. Sending a sysex clear memory somehow reset things and the CC started working again.

I stripped down the program to the minimum and it still happened. I discovered though, that sending a midi note on had the same effect. Today I had time to think more thoroughly about it and came to the conclusion that it could not be the part of the program that treats the received bytes, it had to happen on reception. So I hooked up my logic probe to the midi rx line and watched what came into the MPG-200.

Guess what - after a restart, the web gui, knowing nothing about the restart, did not resend the status message. That explained almost everything, I had tripped in the running status issue again. But a little more research uncovered a few other interesting things:

Sending a midi note on from the LP actually reset the running status, so the status message was sent again. This surprised me, how does the web gui know that the LP has sent a midi on? I also tried to refresh the web gui to 'restart' the midi interface, but this did NOT work, it still did not send a new status message.

Then it dawned on me. I am using the LP as my midi interface. It is the LP that holds the state, NOT the web midi adapter! So even if the web midi did restart, the LP knew it was currently sending a particular CC, and so did not resent the status - and of course sending a note on merged into the same data stream and made the LP resent the CC status later.

Oh well, I am just glad I figured this out, even though it's a bit embarrassing.

Bootloader working!

I finally got the midi based bootloader for the mpg200 up and running. I have yet to test it with the mpg200 code but a short test program uploads fine. So happy right now :)

Summer 2018 - DAC Mux, Ring mod

Summer is always kind of productive for me. While off on summer holiday to the western parts of Norway, I get time to do some electronics work. This time I've drawn up and ordered a 16 channel sample and hold circuit (DAC mux) to replace the 32 channel one used in the prototype. This one is easier to place and makes it possible to use only 16 channels for parts of the synth.

I also did a v3 of the linear VCA. This time, as for the first version, the trimmers are off-board, but the components are placed on both sides as in v2. The whole card is sort of a double width DIL thingy with the pins for one VCA on one side and the other on the other side. I imagine it possible to place it in a socket and have other parts of the circuit below it - we'll see.

Finally, I did a ring modulator based on the one from yusynth.net, which in turn is almost entirely a copy of the one in the datasheet. This one uses a surface mount MC1496. The circuit and board are finished (but untested), including logo.

Oh, and I have written a midi/sysex-based bootloader - it's almost finished. I will feel much better if I can remotely update any MPG-200 I sell. The bootloader is very simplistic and does not have any flow control, so sysex uploading must be done through a program made by me. Still better than not being able to update at all.

MPG-200 PCBs ordered from DirtyPCBs

I ordered what is hopefully the final version of the MPG-200 cards from DirtyPCBs last night. If all things go to plan I will get approximately 40 boards somewhere next month. Exciting!

WebMIDI and the MPG-200

A couple of days ago I put the final touches on a settings editor that can generate sysex for changing the MPG-200 internal settings like CC mappings and midi channel etc.

I wrote everything using javascript and HTML, and initially made it generate a sysex file that you could download and send using your favourite tool.

As an experiment, I thought I'd make it possible to send the data directly to the device using the newly available WebMIDI standard. I had a few issues but now it seems to work nicely.

I have been using Google Chrome to do the development, and there are a few things to be aware of:

1) In WebMIDI you have to ask the user for access to sysex messages. In Chrome, this cannot be done if the javascript file is accessed as a local file or from a local html file (file://...). Neither can it be accessed through an insecure connection (I assume this means you have to use HTTPS).

To get around this, I installed a tiny webserver (The TinyWeb actually) locally and ran the code through it. Works like a charm.

2) You have to send the complete sysex message in one go - it must start with F0 and end with F7. You cannot send the messages in blocks so the message has to be calculated up front.

3) Running status is not allowed, as with the sysex message each message has to be self contained and complete.

The sysex editor and my WebMIDI code is found on the Xonik webside, but as I said, you cannot use the WebMIDI part directly as it is not served over HTTPS.

MPG-200 final hw version finished

Just finished what I hope will be the final version of the MPG-200 hardware, correcting the small mistakes with the previous verson. Will probably order a batch from dirtypcbs soon.

Free the PG-200!

Around three years ago, in april 2012, I decoded the PG-200 protocol. Using a Saleae logic probe I took a closer look at what happened while using the PG-200, and built a device that converts MIDI CC messages into PG-200 commands. This device, the MPG-200, also receives and transmits MIDI note messages, making it possible to completely control the JX-3P using MIDI.

To my knowledge, at the time I started the project only two other devices existed that could do this - the KiwiTechnics JX-3P upgrade and Patch Editor and the Organix Midi upgrade kit. These both require extensive modification of the JX-3P. Later, Mode machines made a PG-200 clone called the DT-200. I have yet to see the PG-200 protocol fully documented anywhere, but I may have missed something as I have not searched the web lately.

As a tiny gift to the synth community in honor of my daughter's birth, I now release all the information I have gathered. This document is based on the data found in the JX-3P/PG-200 service manual as well as a lot of work done by myself. Feel free to use it in any way you see fit, but I would be really happy if you acknowledged my contribution.

The complete protocol description can be found at http://www.xonik.no/mpg-200/pg-200/pg-200.html

MPG-200 programming through midi cable

I soldered together the first MPG-200 today. I've made a few mistakes - my midi connector does not perfectly fit the board, and the electrolytic caps and transistors would have liked a little more space, but nothing serious.

I have yet to try it out as the mpg-200 firmware has to be adapted to the PIC18F25K50, but I got the programmer working. I've chosen to run the programmer pins, five in total, through the midi connector. The wiring is as follows:

Pin 1: 5V
Pin 2: MCLR
Pin 3: PGClock
Pin 4: PGData
Shield: GND

Now, I do not usually want the shield to be connected to GND, so I've added a jumper that must be removed after programming. Pins 1,2 and 3 are not normally used by midi so those are hardwired, but I've added solder-blob jumpers that can be removed should you use any equipment that use these lines for something else.

Pin 4 is normally midi in, but as long as I have not added the input optoisolator it can be used by the programmer as well.

The Mikroelektronika mikroProg connected to the MPG-200 through a custom cable

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.

Oh the horror!

I have incredibly bad news to bring to the world at the start of the year. To my horror, I've discovered that the switch between midi and PG-200 modes on the JX-3p is scanned like any other key on the front panel of the JX-3P. Using my logic probe on the scan line while turning both a dial and playing notes at the same time, I have observed the following:

• The scan frequency varies widely depending on how much work the JX-3P has to do (as is to be expected I guess)
• The minimum period between two scan cycles is 11.7ms (!) while delays of up to .23 seconds (!!) also occured. This means that the absolute fastest switch between midi and PG-200 data is about 12ms and that I have to use a much higher period to be reasonably sure of not dropping any bytes.

In this screenshot, the first waveform is the serial data (midi/pg-200), the second is the mode-select signal (switches between midi and pg-200), the third is the scanning - notice the big period of blackness in the middle of the screen, here the JX-3P has been working hard and not had the time to scan for changes, resulting in a dropped midi or pg-200 byte. The fourth is the result of the scanning, whenever a scan occurs and the mode select signal is 0, a 1 is returned to the microcontroller - this is seen as long stretches of 1 on the fourth line, in the parts where the scanline still changes rapidly.

This is by far the biggest problem I have faced while working on the mpg-200, and I am afraid this one cannot be solved easily as it is directly related to the way both the hardware and firmware of the JX-3P is built.

I have tried using a "settle time" after changing the mode of about 100ms, that seems to work fine for most hand turned potmeters etc, as long as one does not play fast and turn rapidly at the same time. However, even this means that one has to wait at least 100ms after changing a controller before a new note is pressed (or released). If not, the note will be delayed or not played at all.

So - one can do filter sweeps as long as you hold down the same note, but rapidly changing parameters while playing will probably not work very well :-/


This seems to me like a show stopper for much of what I wanted the mpg-200 to be. It can still be used for tweaking the JX-3P from a daw, but prevents much of the automation that would be cool.

What a bad way to start 2013...

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.