Relay LCD signals from one device to another with the same display.
Ken Hamilton wrote 07/11/2021 at 14:22 • 1 pointHi, I have a Kurzweil K2000RS sampler from the early 90s. Because of the form factor it can be uncomfortable to program the machine for long periods as the front panel is typically vertical when on a desk or mounted in a rack. Using an angled rack would go a long way to fix this but because of the size and bulk of the machine (plus noisy fan and power transformer) that can also present challenges.
What I’d like to do is build a desktop remote controller that includes a duplicate of the front panel controls and display.
I’ve done a few upgrades to the machine including replacing the LCD Display and installing a SCSI2SD board in place of the original SCSI hard drive. In the process I got to see how things were connected to the display and front panel: https://helium.deepgreen.ca/dave/K2000R_Display/K2000R_Display_Upgrade.html
Each component, Display and Panel buttons, are connected to the main board via their own 20 pin ribbon cable. The LCD is a Toshiba T6963 based 240x64 parallel display.
I don’t have an electronics background but have done a bit of coding. The naïve idea I have is to create 2 custom boards. One installed inside the Kurzweil and the other within the remote controller with some sort of fast connection between the two preferably delivering both power and data that could be of a reasonable length (2m would be fine but 20m would be awesome so the main unit could be racked somewhere out of sight). I’m guessing that simply running two 20-pin cables externally will fail after a certain distance due to eventual capacitance, resistance and interference issues.
The internal board would be inserted internally between the main board and both the display and front panel respectively allowing the signals to pass though directly and also be duplicated and transmitted to the external board so that its display and controls are in sync. For the Desktop Remote I would build a custom panel so I could use my own choice of mechanical switches and encoders etc. I imagine that for the display it would just be relaying the signal one way from the Kurzweil to the desktop remote but the front panel would be 2 way as there are a number of LEDs that change either via direct button presses or software during the synth editing process.
Regarding power, that may be an issue. Apparently they beefed things up a bit for the K2500 series but the K2000 is well known for its barely adequate power supply. They have a 12V connector for an internal SCSI hard drive option but you had to be very careful which one you installed as it may consume too much power and not work. There were lots of reports of that being unreliable even with factory solutions. As for my unit, I replaced the built in floppy for the SCSI2SD card. Both use 5V so that was a direct swap. The original display had a separate 5V connection to power the backlight but the new display only uses 3.5V and is getting that from the 20pin cable directly from the mainboard. So there is some power budget between the spare 5V and 12V cables but weather that is enough to drive say two 3.5V micro controllers (one internal and one remote )and another 3.5V external display is an open question. Maybe I would have to forego powering the internal display when using the remote as an option.
I’m in the process of deciphering the Kurzweil’s SysEx implementation and have found some pretty good resources as this can reproduce the buttons and reading the display via MIDI. The main issue with this approach is the fact that the Kurzweil is pretty underpowered for processing the volume of messages that may be required while also playing the instrument - which you would want to do while editing and there are inherent delays . All this is pretty instant when you are using the front panel controls directly and it’s that experience I want to reproduce on the remote controller. Also, using the onboard sequencer is a non-starter due to the constance screen refreshes required.
When I’ve searched online, the closest I have found of people wanting to something similar is with the goal of capturing the actual text and/or values displayed on the LCD where for me I only want to be able to to retransmit the raw display signals, like-for-like to a remote display of the exact same type. That way I leaving all the processing on the Kurzweil without SysEx clogging the process.
So my question is how feasible is this?
ask
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
A search came up with this very detailed app note on driving the T6963: https://www.lcd-module.de/eng/pdf/zubehoer/t6963.pdf I don't know if you could design some kind of buffer to take those input signals to the module and drive another display at the end of a cable. Of concern are the timings of the various operations, will those of the local display suffice for the secondary display? If that proves problematic you could design a microcontroller to read and decode the signals and relay the commands to another microcontroller controlling the secondary display. This would have the advantage of reducing the cable width, potentially to a single pair of signal wires carrying SPI, I2C, or another protocol, in addition to the common ground.
For power you could use additional power supplies for the secondary display, as long as it shares a common ground with the main power supply.
Are you sure? yes | no
Thanks Ken, that PDF covers a lot of ground. I also came across the following project here that looks to be along along a similar path.
https://hackaday.io/project/166220-domsnif-dot-matrix-lcd-sniffer-bluetooth-adapter
There hasn't been much activity posted recently but the progress looked promising with the existence of a working prototype. My requirements are slightly different in that I want a physical remote LCD for a dedicated device rather than virtual but if it can be done then the virtual route opens other possibilities such as displaying multiple device screens at once on a PC monitor. I was hoping if I used the same display on the remote side there may be a way of transmitting the signals "as is" (maybe with an acceptable or imperceptible delay) without having to decode anything.... well there would have to be some sort of encoding to stream all the signals via a fast connection and decode on the other end.
For my purpose I don't need to "know" what the display is telling me for data scraping purposes but just that the remote display receives the same signals and can produce the same output. Maybe the only way to do that reliably over a distance is to decode the instructions at the source to ensure nothing is lost in transit.
There is also the issue of the front panel buttons, LEDs and rotary encoder. That appears to be just a switch matrix that may prove much easier to deal with. That said, sending button messages via MIDI SysEx is probably fast enough if a direct method is problematic.
This is a link to the K2000R service manual: Page 115 shows the LCD connection and page 127 shows the front panel controls:
https://www.synthxl.com/offwp/Kurzweil_k2000_k2000r_service_manual.pdf
n messages via MIDI SysEx is probably fast enough if a direct method is problematic.
This is a link to the K2000R service manual: Page 115 shows the LCD connection and page 127 shows the front panel controls:
https://www.synthxl.com/offwp/Kurzweil_k2000_k2000r_service_manual.pdf
he progress looked promising with the existence of a working prototype. My requirements are slightly different in that I want a physical remote LCD for a dedicated device rather than virtual but if it can be done then the virtual route opens other possibilities such as displaying multiple device screens at once on a PC monitor. I was hoping if I used the same display on the remote side there may be a way of transmitting the signals "as is" (maybe with an acceptable or imperceptible delay) without having to decode anything.... well there would have to be some sort of encoding to stream all the signals via a fast connection and decode on the other end.
For my purpose I don't need to "know" what the display is telling me for data scraping purposes but just that the remote display receives the same signals and can produce the same output. Maybe the only way to do that reliably over a distance is to decode the instructions at the source to ensure nothing is lost in transit.
There is also the issue of the front panel buttons, LEDs and rotary encoder. That appears to be just a switch matrix that may prove much easier to deal with. That said, sending button messages via MIDI SysEx is probably fast enough if a direct method is problematic.
This is a link to the K2000R service manual: Page 115 shows the LCD connection and page 127 shows the front panel controls:
https://www.synthxl.com/offwp/Kurzweil_k2000_k2000r_service_manual.pdf
Are you sure? yes | no