I'm trying to know the protocol used for that device. LCD is : 248*60 Binary Size is 512Kb.
The CPU that is used : IC10, UPD70236: V53A is an NEC branch of the Intel 8086 (via their famous V20, V30, etc. series), with various extensions including system peripherals (like DMA), expanded memory (for a total 24-bit memory space), and faster clock and instruction rates.
I'm looking for the functions that are responsible for LCD Write Text, and how are the pins are toggled, specifically, the LCD commands that are sent.
ROM can be find here: https://www.mediafire.com/file/bdepkvyz7dsr9pj/MPC2KXL.BIN/file
Also in the website has everything, including schematic:
http://zine.r-massive.com/akai-mpc-2000xl-archive/
Here is the LCD Socket with the signals:
TL;DR:
Re-engineering leads to these insights, reduced to relevant details for a replacement.
The LCD has a width of 256 pixels and a height of 60 pixels.
There are two driver ICs of the same type. They use the addresses 0x60/0x62 and 0x100/0x102, respectively. The driver ICs receive the address reduced to the single bit A1. The chip select lines nCS1 and nCS2 are active mutually exclusive for each driver IC. The prefix "n" denotes the active-low nature of a line.
Reading 0x60 and 0x100, respectively, returns status. Bit 7 of the status signals "busy" when set, other bits seem to signal reasons for being busy. A replacement of sufficing speed can simply return 0x00.
Writing 0x60 and 0x100, respectively, sets a command. Reducing the effort to the minimum, only commands 0x23 to 0x20 are relevant for a replacement specific for the use case:
Writing 0x62 and 0x102, respectively, adds one or more parameter bytes after a command:
Details
A web recherche for the LCD revealed no usable results, so I went the hard way to re-engineer the firmware.
This image of the LCD was posted on the OP's thread on a forum, it shows that the LCD has two most probably equal driver ICs. Unfortunately there is no IC marking.
The following excerpts of the schematic (nicely linked by Clifford to a source without paywall) show relevant details:
The schematic details reveal the IO addresses.
The two chip select lines back up the theory that there are two driver ICs. Such configuration is often used in a main-sub relation, where the main driver synchronizes the sub driver. This way LCDs can be driven that are larger than a single driver can control.
The address line A1 suggests that each driver IC has the common organization of a command address and a data address. Later findings support that idea.
The V53 CPU has its reset vector at 0xFFFF:0x0000. The linked binary has a size of 512 kiB = 0x80000, which needs an offset of 0x80000 to provide its end at that location.
Using Ghidra I set up the loaded binary with said offset and added a RAM of same size at offset 0. Then I searched for words of 0x0060, 0x0062, 0x0100, and 0x0102. The findings look quite promising. Note: the following edited excerpts already show edited function definitions.
The following are clearly the base functions to access the LCD.
One important finding is that reading 0x60 and 0x100, respectively, returns status. Bit 7 of the status apparently signals "busy" when set. A counter avoids an endless loop in case of any error.
After disassembling more of the neighborhood, more interesting functions show up.
The following looks like the initializing of the LCD.
As a simplified C function it looks like this.
This function sets multiple control values of unknown meaning. Some of them can be deduced from their parameters.
For example, command 0x23 has the parameter 0x85 and 0x8d, respectively, for LCD1 and LCD2. We can assume the bit 3 of the parameter selects main/sub. Later the command has the parameter 0x05 and 0x2d, respectively, for LCD1 and LCD2.
There is a function
delayxxxUs()to delay for an interval I did not calculate. It is not relevant for the analysis.There is a function
clearBuffer()that clears a buffer in RAM. This is also not relevant for the LCD, as this function does not access the drivers.After more searching, there is this huge part that apparently copies some buffers in different ways to the LCD. The specific differences are not relevant for the LCD. In the end, its drivers receive and store pixel data.
Reduced to a simplified C function that shows just the transfer of a buffer to the LCD:
The buffer is organized as 60 lines of 32 bytes.
There are two stacked loops: