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
|
