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.
From the Jx3p schematics, I can't see the busy line connected to anything other than +5V through 1k resistor. It isn't connected to the cpu.
ReplyDeleteHave you taken a look at the firmware for the JX where the PG200 serial stuff is handled for special values like 0x80, 0x81 and 0x82?
Interesting - it looks like you're right (unless there's something hidden between the two scans in the manual). I haven't studied the JX-3P schematics beyond the input board, so this was news for me.
ReplyDeleteI suspect that the error was that I mixed midi and pg-200 messages too quickly and that the JX-3P interpreted the midi as pg-200 and vice versa.
I don't have access to the JX firmware, is it available on the net? I have decoded the protocol using a logic probe and haven't felt the need to look at code so far, but thanks for the tip.
I have a disassembly of some version of the firmware and am in the process of trying to understand how it handles the serial stuff. There are dead ends and unreachable sections of the code so this is not trivial.
ReplyDeleteI have a beat up old JX whose panel switches are dead so the way to program it is via the pg200 serial interface which I don't have. I have however several Atmel and Arm gagdets to play with so I figured I could hack something together.
Send me an email at joi kiesel is and I'll send you what I've got so far.
I found the disassembled firmware as well as the bin file, but it didn't help me much. I have however managed to make a stable version of my own program and can now control the JX-3P by midi. I have sadly also discovered that realtime controller changes will not be very good, see my most recent post - switching between PG-200 and midi modes is simply not fast enough. This means that making a replacement for the PG-200 or controlling the JX-3P from a DAW or similar will work very well, but doing a lot of controller changes while playing or similar will not work satisfactory. I cannot see any solution to this that does not also require a firmware change in the JX-#p...
ReplyDelete