SMPTE IC to OLED Display

Nigel Goodwin It's discontinued, that's why I'm trying to replicate my own.
So my approach would to record the commands from the LCD socket,..etc ?
But don't you see that the LCD is a normal Char LCD ? is there a mystery protocol around it ?
If I want to do it the hard way, can you explain to me the steps ?

Nigel Goodwin
Thanks so much for your support.
After a lot of research, I have found a compatible LCD/Driver. Here is the datasheet, what is your view and opinion on that ?

It's the same display module as various Akai machines.

There are replacement displays for those available.
eg.


From another forum -

I need a new display for my akai mpc2000 part number s-11114b

Click to expand...

I also found some pictures of dismantled machines showing the same S-11114B display module.

rjenkinsgb
The problem is I would like to interface with OLEDs, VGAs,..etc. So I would like to know the approach actually on how to replicate the signals.

Get a cheap logic analyser such as a Saleae Logic 16 & connect to all the signals to the display.

Capture the data sequence and compare it to the LCD commands for various controllers. It's almost certainly a bitmap pattern plus addressing data.

The single address line usually selects either the display memory (the bitmapped pattern data) or the control register(s).

rjenkinsgb
Thanks for your input. And After deciphering the commands. What should I do next ? Build up a frame buffer, copy it to SRAM, DMA it with another LCD ? Like STM32 Does with DMA2D ?

Nigel Goodwin rjenkinsgb
1. What is A1 in the socket responsible for ?
2. The approach is to interrupt on IOWR, read the data and follow the commands in various controller
3. After deciphering the commands, I should collect the data and make a full 2D Frame buffer
4. OR do the same commands, that comes from the CPU to my own LCD, for example the CPU issues a DrawChar, I should also give a command to my own LCD controller to DrawChar ?
5. Write to another LCD that Bitmapped 2D Frame buffer ?

A1 is an address line from the CPU - it selects access to the control or data registers in the LCD.
For the display, it's just a two way address select, A0 (lowest order address bit) as far as the display is concerned.

Most present parallel interface graphic displays call it D/C (data / control) instead of address - but its exactly the same thing.

See page 5 of this for a typical interface such as that. It uses A0 from the CPU rather than A1, it's just whichever address line the designer thought suitable - it's still the same D/C function at the display.

Page 4 of that also gives you an idea of the typical commands that can be used - not many, mostly to select the address or range that the next data will be written to or read from.

The internal "address pointer" increments on each data read or write, so you set that then send as much data as appropriate.


An MCU with a parallel slave port could be ideal as a "converter", as that could directly accept data from the existing LCD connector.

However, the LCD interfaces - especially older ones - tend to be relatively slow and any present fast MCU would likely be able to emulate it in software - an STM32, RP2400 or ESP32 etc.

If you arrange the data (to D address) appropriately, it should give a direct bit-to-pixel mapping of the displayed image.

rjenkinsgb
Thanks so much for your input, really appreciate it.
Can you explain to me more about data arrangement ? The approach actually ?

rjenkinsgb
Some tried to hack it also, he found that issue ?
How do I respond back to the CPU without a latch ?

rjenkinsgb
Can you show me pseudocode or flow code ?

Nigel Goodwin I appreciate your support <3
I'm a member since 2007

ahmedragia21 said:

How do I respond back to the CPU without a latch ?

Click to expand...

An MCU with a parallel slave port has a data latch built in; other than that, add an external latch system to store the data + address bit until the MCU reads them.

rjenkinsgb
Thanks so much really.
can you please give me details on the software approach ? like steps or pseudo code ? this will be the last question
I can't find a fast speed microcontroller with parallel slave port in it.
The ones that I have seen are PICs and they are not fast ?
Also on the PIC parallel slave port, I have seen WR,RD,CS pins, should I connect these to the LCD socket too ?

In newer PICs, the peripheral is called PMP, parallel master port - which can also work as a slave port. I'm not sure if it is 8 bit only.

Someone has done a similar thing with an STM32, here - they are saying it was not initially working, but the answer (move the DMA init line) apparently works:


That's using one of these MCUs:

rjenkinsgb
I don't see in the original socket of the LCD that there is a clock input that should be connected to parallel bus of stm32 ?
I still need help with a software approach to build up the pixels

The "clock" is the data capture trigger; from the LCD interface it would be the OR combination of the two chip select lines and IOWR (so when all three go low that signal goes low), as that's when the LCD would see a valid data write.

Sorry but I do not have time to go in to the software in any depth, I'm way behind on my own projects!

You need to capture data first, then compare that to the displayed image to figure out the mapping.

(If that SED1561 is compatible, the data to pixel mapping is on page 39 of the datasheet. Just rotate that to landscape view).

rjenkinsgb
Thanks so much for your support, I wish you the best for your projects.
Regarding software:
I have a plan like to write a big state machine, once the A0 is a data register, I put the data into a buffer, as they are pixel data, if A0 contains command data, I group the commands, then act on them.
The question is I should wait first for commands, then data right ?

Are not some commands followed by immediate data ? As part of
a multi byte command ......


Regards,m Dana.

danadak Didn't understand ;(
ok then how do I construct the state machine then?