TR707 LCD Replacement Project - Page 1
Forum section: electronics / projects

author: Peacefrog
author_rank: Contributor
timestamp: December 25, 2020, 07:50:41 pm
content: I have an old Roland TR707 drum machine with a very faded LCD display, which seems to be a common problem per numerous threads on the internet.I've tried to improve it (checking the voltages, cleaning the Zebra strips, replacing the polarising film, etc) but all to no avail - and given it's not backlit, I wondered if I could do better and replace it with something more modern.It uses a HD61602 controller (service manual here:https://www.synthxl.com/wp-content/uploads/2019/07/Roland-tr-707-service-notes.pdf), and taking advantage of the Xmas break, I broke out the logic analyzer to understand the protocol. Things are actually pretty simple - each LCD segment corresponds to a bit in the controller ram, and a two byte sequence selects the address then the value to write.The interface itself is comprised of Reset, Write Enable, and Chip Select lines along with an 8-bit data bus. I originally wondered if I could prototype an MCU-based translation using an Arduino Micro, but the period of the lines toggling is ~1us - which I believe to be too fast to monitor by GPIO interrupts (at least with this board).I'm much more acquainted with software than hardware, but I think my options are therefore:- Move to a beefier MCU (STM32?), although I'm wary of spinning monitoring interrupts when the display needs attention, too- Look at building something with an FPGA- Build hardware that could buffer the bus values so an MCU could interpret it at a more leisurely rate- Per one of Dave's videos, look at designing a custom replacement LCD that works with the original controller (even if I have to design a new PCB)Can anyone suggest better options? Thanks in advance!

author: coromonadalix
author_rank: Super Contributor
timestamp: December 25, 2020, 11:23:58 pm
content: the lcd is specially made for the roland, adding a beefier mcu wont help unless you need to reformat the data to fit say an t6963 lcd ?? and you may need a minus -12vdc to make them work on some models.My guess would be to order a new lcd controller and see what the change will do ?another small thread herehttps://www.eevblog.com/forum/beginners/hd61602-lcd-driver-ready-pin/

author: coromonadalix
author_rank: Super Contributor
timestamp: December 25, 2020, 11:25:02 pm
content: other stuff and lcd routineshttp://www.chriskann.com/TR707/TR707_CPU_Format.html?i=1

author: Peacefrog
author_rank: Contributor
timestamp: December 25, 2020, 11:56:52 pm
content: Thanks! Yeah - it's a custom LCD, so I'd have to recreate it, pins and all. That's why I headed for the MCU option; it'd act as an translator between the LCD controller commands and a modern LCD or OLED.I guess I'm wondering - if I *did* want to translate the signals, 1 us interval and all: what's a solution that would cope with that signal speed?

author: ozcar
author_rank: Frequent Contributor
timestamp: December 26, 2020, 12:02:14 am
content: Quote from: Peacefrog on December 25, 2020, 11:56:52 pmHow about a Teensy?But...The second link provided by Coromondalix says that there has to be a greater than 100 microsecond delay after an address/data pair of bytes is written. If your testing confirms that, perhaps you could latch the address and data in hardware, and have 100 microseconds to do something with them.To adapt an old quote: "100 microseconds ought to be enough for anybody".

author: DrG
author_rank: Super Contributor
timestamp: December 26, 2020, 12:33:30 am
content: I don't have any better options in a realistic sense, but do take a look at this threadhttps://www.eevblog.com/forum/beginners/128-x-64-mystery-lcd-identify/50/I think there was some agreement that it was a 1601 controller and not a 1602 - I'm also not sure what actually happened with the OPs project, but you might get some leads on possible substitutes

author: coromonadalix
author_rank: Super Contributor
timestamp: December 26, 2020, 03:44:18 am
content: Maybe putting another lcd with the same chipset could be ok, the characters mapping must be done by the main mcu ??my 2 cents

author: motosega
author_rank: Newbie
timestamp: June 27, 2021, 10:39:31 am
content: resurecting an old post for a just cause:i'm working a replacement tr707 screen at the moment, except with a pcb covered in smd leds, i already have working pcbs for the displayif you'd like to get in touch we can share notes, i'm just starting to work on the decoding. my initial experiments are with an arduino but if it's not fast enough i have stm32 dev boards too. i'm optimistic that if i trigger an interrupt on the !CS line then i will be able to read the data before it's too late.https://synth.ewancolsell.com/home/roland-tr707i've been posting updates on the "music gear display retrofits" group on facebook:https://www.facebook.com/groups/music.gear.display.retrofits/