Subject: TECH: Dot Matrix (Plasmadot) displays
From: Clive Jones <[email-masked]>
Date: Tue, 19 Mar 96 09:55:00 PST
Newsgroups: rec.games.pinball

Hello again Chaps, it's Technical posting time.....

(groans of - "it's Clive - lets hit the delete button")
Following up a recent post on using Dot Matrix displays I thought this   
might be of interest to the tech's out there (if not I appologise)...

The PlasmaDot display was first used by Data East in a year I can't   
remember (1990?) on a game I can't remember either (oh dear!...it does   
get better - honest).
The only Display manufacturer I know of is Cherry although I've heard   
 they're made by another company too.

Cherry make PlasmaDot (tm) displays of various resolutions and sizes   
these are (or were);

PD01-A220, 32 rows x 128 columns, round pixel 1.27mm in diameter

PD02-A100, 64 rows x 128 columns, square pixel 0.51mm sq.

PD03-A220,  9 rows x 106 columns, round pixel 1.27mm in diameter

PD04-A220, 24 rows x 106 columns, round pixel 1.27mm in diameter

PD05-A220, 32 rows x 106 columns, round pixel 2.54mm in diameter

Typically all displays are high voltage requiring;

Supply  - 185 volts DC (+/- 15v)
Firing  - 147 volts DC
Sustain - 132 volts DC

The displays use "DC plasma technology" utilizing neon-argon gas which   
glows orange when ionized.

The displays contain NO memory except latches for column and row data.   
All the pixel drivers are present onboard too so its only a matter of   
clocking the data into the display in serial fashion according to the   
usual timing diagram rules (you need the data sheet for this one).

Okay, thats all good and well anyone can blind people with science (I do   
it to my Mother all the time - "Mum your video's not working because one   
of the op-amps is reversed biased and the case is the wrong colour" (I   
change the fuse without her looking because thats all thats really wrong   
and she's *well* impressed ) - "Clive, I'll never understand why you   
didn't go and work for NASA" she states proudly.

Seriously though.......

Without getting dangerously deep in signal specs and timing diagrams   
we'll jump straight into the juicy bit - "how do you use one"?.

Well lets say we use the 32 rows x 128 columns display. If we just need   
to turn a pixel on and off, we would only have to reserve 1 bit of memory   
for each pixel - equate this to bytes and it's 32 bits x 128 bits divided   
by 8 - or 512 bytes in total. Thats hardly going to tax most 8 bit   
'processors! Given that it also only gives us two colours - black   
(background) and orange (foreground), thats pretty boring.

Why not go for 8 colours - black and 7 shades of orange?, you could get   
quite "arty" with this much flexibilty.

This is a different story - we need to use 8 times the memory per pixel,   
which equates to - 32 bytes x 128 bytes or 4096 bytes (4Kb).

Now throw into the formula the "refresh" timing. This is the speed that   
the display is updated - it must be quick enough to fool the human eye,   
Cherry state the minimum time to be 60Hz or 60 times per second, if we   
use eight levels of luminance we need to times this frequency by eight -   
480Hz.

So to drive a 32 x 128 pixel display that has 8 colours we need - 4096   
bytes of memory minimum (used to hold the display data) and a refresh   
rate of 480Hz.
Consider too the display data has to be continually pumped into the   
plasmadot display because of the lack of onboard memory. Also, you always   
need to write 128 bits of data per row and you can only latch *one* row   
at a time.

It's not difficult to see why so much processor overhead (work/time) is   
needed.

Okay - so to display different levels of orange (luminance) we need to   
pulse-width modulate each pixel (don't worry it's not that scary)

For every "frame" to be displayed we need to show the same data *8 times*   
to achieve different levels of orange. For the brightest pixels - they   
will remain on for seven of the eight scans, for the least brightest -   
only one of the eight scans. The first scan is *always* blank or "off"   
(we need to do this to ensure we get the black background - 1 or more   
pixels remain off for the full 8 scans).

So each pixel/byte, this would be;

  d7    d6    d5    d4    d3    d2    d1    d0
[bit7][bit6][bit5][bit4][bit3][bit2][bit1][bit0]
 128    64    32    16     8     4     2     1

byte value - 00 (dec), black (background)
byte value - 02      , dimmest pixel
byte value - 06      , dimmer pixel
byte value - 14      , dimmer pixel
byte value - 30      , dimmer pixel
byte value - 62    , dimmer pixel
byte value - 126     , dimmer pixel
byte value - 254     , brightest pixel

If you were to show this as a timing diagram;

Clocks     __    __    __    __    __    __    __    __    __
Periods __:00:__:01:__:02:__:03:__:04:__:05:__:06:__:07:__:08:__......

off_____________________________________________________off (black)

           __
off_______:on:__________________________________________off (dimmest   
pixel)

           ______________
off_______:on            :______________________________off (mid bright)

           ______________________________________
off_______:on                                    :______off (brightest)

Here the "on" period (pulse) changes length according to how long and   
therefore brighter the pixels are, the pulse is stretched or shortend   
according to our needs - pulse-width modulated.

Okay, so if we work this into our memory map we have eight 512 byte   
frames worth of data giving us 4096 bytes as previously discussed.

For arguments sake we'll make the first frame of data start at RAM   
address 1000h and continue for 512 bytes. In memory mapping this would   
look like;

1000h - 11FF, frame 0
1200h - 13FF, frame 1
1400h - 15FF, frame 2
1600h - 17FF, frame 3
1800h - 19FF, frame 4
1A00h - 1BFF, frame 5
1C00h - 1DFF, frame 6
1E00h - 1FFF, frame 7

Breaking the frames down still further;

frame 0 - row 1, 128 bits (pixels) or 16 bytes. Each bit of the 16 bytes   
represents an "on" pixel when 1 or "off" when 0. You always need to pump   
128 bits of row data into the display to ensure that previous data in the   
display latches is overwritten.

For the tech's - row is source and column is sink. Row drivers are known   
as "anode drivers" and run between +60 and +70 volts DC and the column   
sinks are "cathode drivers" running about -125 volts DC (for a sum total   
voltage of approx 185 volts DC).

Thats the mapping done, now to display the data written into these   
address's we start by pointing at 1000h and displaying the first 512   
bytes of graphics data for a set time period, then 1200h, then 1400h and   
so on until all the frames have been displayed. If your just showing this   
one frame sequence (for example the "Williams" logo), you would wrap   
around from 1FFFh (end) to 1000h (start) again until interrupted (a coin   
drop or the next timed attract mode sequence etcetera).

The brightest pixels in the frame would be written into 7 of the 8 frame   
memory locations (frames 1-7) and the dimmest in the frame 1 memory   
location only.

You are effectively "scrolling" through a 4096 byte window here, - you   
could write graphics data into further consecutive RAM locations and do   
verticle scrolling or animations or whatever.

Typically 1000h would be known as the "display base address". This would   
be workspace RAM of a fixed size (fixed by boundaries in software) and   
would be loaded using graphics data held in ROM.

You could alternatively just read the data straight out of ROM, but, the   
problem with this method involves continually moving the display base   
address pointer to point at the correct graphics data (instead on loading   
the data into a predefined RAM location and always pointing at a fixed   
address).

The software routine that handles the display/graphics data is commonly   
known as the "display handler".

The hardware interface? - hell the Rockwell 6522 VIA was made for this   
job, serial shift register, presettable output clocks, easy to interface,   
interrupt generating, more flexibility than you could shake a stick   
at.......

So thats it.There is more - internal serial shift registers, blanking   
timing etcetera but it's a bit too deep to go into - grab a data sheet or   
call Cherry for more info. I wondered why Cherry (who quoted to me on th   
phone "did you know one of our largest customers are the Pinball   
manufacturers?") never installed at least a ROM with various cow images   
onboard.

Clive - England, the home of "Mad Cows" disease. Moo.....
<[email-masked]>