LCDInfo.com

Got 24x1 VFD dot matrix character display with Nec D65012GC591 written on the controller chip and I'm having *REALLY* hard time finding ANY info about it.

What I can see from it looking at the wirings between the connector and the chip there are +5V, GND, 8 datalines and 6 control lines.

In case someone should end up in the same situation, this is what I managed to get out of the controller through trial and error:

Pin: - Signal:
03 - D0
04 - D1
05 - D2
06 - D3
09 - D4
10 - D5
11 - D6
12 - D7
15 - /WR
16 - /RD?
17 - C/D
18 - E
50 - /RD?
51 - /RST


The sad thing: While I managed to output data to the display trying to figure any of the commands the +5V wire came loose. When I reconnected it the controller chip went up in smoke.

The only good thing is that the display was almost free. Yet it was the first VFD I've ever had.

Hi,

i have a NEC 70GX48AA-100A ( 70 x 48 Pixel ) VFD Matrix Display, with on D65012GF406

The D65012 is NOT a Controller-chip, is a Programmable Gate-Array

http://www.datasheetcatalog.net/de/data ... 5012.shtml

On my board is the Controler a D16304GF ( 40BIT VFD/FID Driver ) x 5

http://www.datasheet4u.com/html/U/P/D/U ... s.pdf.html

all pins from conector goes to the D65012GF406

On the board is a Powersupply ca. 150 - 200V

Have you pics from your VFD ?

This was when I was randomly poking around with the wires until I found the correct one and The Matrix opened up on me...
http://oms.wmhost.com/lcd/vfd_testing.jpg

This is the only shot of it after receiving valid data, before the "accident"...
http://oms.wmhost.com/lcd/vfd_working.jpg

Hi folks,

I've been in a similar situation since I could get hold of a FM24X1BA-100A VFD module with the uPD65012GC591 controller.

I also could not turn up any useful documentation on the display or its controller ASIC. However, I was lucky to have access the device it was embedded into: a Nixdorf cash register POS display module. Being useless in itself for re-use on a PC due to its Nixdorf proprietary interface the module (consisting of a 80C32, EPROM, RAM and other stuff) put me in the nice position to observe the initialization of the VFD with a logic analyzer plus disassemble the initialization code in the EPROM.

So here's the results:

General:

The VFD module is a funny in-between of a character and a graphics display. The controller has no internal character generator, hence, 5*7 bitmap data must be written, not ASCII code. The host system software must contain the character generator and do the ASCII to bitmap lookup - and it can display arbitrary foreign language characters or even graphics. The whole thing can be represented as a 120 column by 7 line graphics matrix. Sadly the VFD glass is a character one, that means that the layout is 24 blocks of 5*7 matrices with 2 pixel wide spaces in between - not very useful for showing graphics due to the inter-character gaps.

Pin-out of the VFD module:

Module Pin_____uPD Pin______Signal
_______1_______multiple_____GND
_______2_______multiple_____VCC (5V@1A)
_______3_______51___________/RESET
_______4_______17___________R/W (low = write)
_______5_______18___________Strobe (high = active)
_______6_______16___________A1
_______7_______15___________A0
_______8_______50___________CS (high = selected)
_______9_______n/a__________n/c
______10_______n/a__________n/c
______11_______3____________D0
______12_______4____________D1
______13_______5____________D2
______14_______6____________D3
______15_______9____________D4
______16_______10___________D5
______17_______11___________D6
______18_______12___________D7
______19_______n/a__________n/c
______20_______multiple_____GND

Please note that the pin counting order is different from the standard IDC header counting scheme. Look at the silkscreen print on the VFD module PCB!

Register Map:

Reading (CS=1, R/W=1, Strobe=1, A[1..0]=XX)

Bit 2 is the only meaningful data to read. Bit 2 = 1 indicates that the VFD is ready for writing data into it. Bit 2 = 0 means that the display is still busy with its power-on initialization. The other data bits seem meaningless (read zeros under all conditions) and the register address is also irrelevant (identical data being read for all combinations of A[1..0]).

Writing Register 0 (CS=1, R/W=0, Strobe=1, A[1..0]=00)

Write pointer for next data write access (confer register 2): 0x00 is the leftmost column, 0x77 is the rightmost column. Since characters are 5 pixel wide 0x05 is the left row of the second character, and so on.

Writing Register 1 (CS=1, R/W=0, Strobe=1, A[1..0]=01)

Probably the line length. 0x78 is written during initialization but no changes occur when other values are written or even nothing written to this register at all. It seems to influence neither the scan width nor the write pointer wrap-around which occurs at column 0x77 regardless of the value written to this register.

Writing Register 2 (CS=1, R/W=0, Strobe=1, A[1..0]=10)

Display data to write at the location (column) specified by the write pointer in register 0. Bit 7 has no function, bit 6 is the bottom row and bit 0 is the topmost row. When the last column (0x77) is written the write pointer rolls over and the next access goes to address 0x00.

Writing Register 3 (CS=1, R/W=0, Strobe=1, A[1..0]=11)

Display enable register. Bit 7 = 1 means display is on, clearing bit 7 blanks the display. The other bits make no visible change, even though the init code writes 0x82 setting bit 1. However, things look the same when 0x80 is written instead.

That's it. No magic, but the display is quite dumb anyways. Lucky the software doesn's have to do the scan cycles by itself

I've hooked the VFD module to the printer port and hacked together a simple piece of QBASIC to drive it. Thus I can write various graphical patterns to validate my measurements and assumptions but still no driver for real and useful ASCII text displayed. Maybe I'll do it when I hit some hours of extreme boredom...

Have fun
Matthias

Nice finding, too bad they came a bit too late...

I've still got the module but without the uPD it's not much usable.

Well, at least in theory the uPD16306 could be driven from a different part of hardware when the uPD65012 controller is blown. This chip is just a 64 bit shift register, latch and high voltage driver. Google turns up quite comprehensive documentation on the chip.

The problem with this approach is that the required serial data stream fed to the uPD needs to be quite fast in order to yield a sufficient refresh rate for the display. Let's do a quick back-of-the-envelope calculation:

Say we need a 50 Hz update rate for the entire 24 character display to get a decent flicker-free display. To create the image we need to do two things simultaneously: First, create a marching one for the gates (chars) and update the data for the anodes (35 pixels per position) accordingly. The shift register in the driver cannot do partial updates, so we need to do a full shift and load each time. Thererfore, we need to do 50 * 24 = 1200 register loads per second. Each of them requires 64 shift clocks therefore, we need a shift clock of 76.8 kHz. This is well within the limits of the uPD16303 which can cope with shift clocks of up to 20MHz. However, it will pose a significant load to a software-based system considering the need for a continuos, non-interruptible update to achieve a flicker-free display.

Just took a few quick measurements on the board: The uPD 65012 drives the uPD16306 with a shift clock of 220kHz. The strobe and blank inputs are driven with 3.729kHz. Looks like it is just shifting in 59 bits - exactly what is needed to drive 24 gates plus 35 pixel. This results in a total update rate of 155 Hz for the entire display, pretty neat! The interesting thing is that the shift timing remains rock-solid even while heavily writing data into the display module from the host side. The uPD65012 must use quite a clever interleaving / cycle stealing scheme to intermesh host updates and display refresh, considering that there is no dual port memory on the board! Fucking clever Japanese

Next thing to keep in mind is the fact that the display module incorporates kind of a watchdog that quickly shuts of the high voltage generation in case the clock somehow gets lost. Tested it by stalling the resonator with a wet finger: Display stops scanning with one random character position VERY BRIGHTLY lit for a split-second then going blank. Probably to avoid burn-in if the clock fails. This circuitry would have to be defeated somehow if the uPD16303 is to be driven directly.

Determining which of the 64 outputs of the uPD16303 drive which of the 24 gates (chars) and which drive those 35 anodes (pixels) is left as an exercise to the reader And well, there a still 5 outputs left over - what are those doing??? Nevermind, no data shifted into them anyways in the original circuit.

Regards
Matthias