Article: 57887 of rec.games.pinball Path: aim.et.iupui.edu!mozo.cc.purdue.edu!purdue!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!newsfeed.internetmci.com!tank.news.pipex.net!pipex!dispatch.news.demon.net!demon!mail2news.demon.co.uk!squidgy.sni.co.uk From: Clive Jones Newsgroups: rec.games.pinball Subject: TECH: Dot Matrix (Plasmadot) displays Date: Tue, 19 Mar 96 09:55:00 PST Lines: 208 Message-ID: <314EF526@squidgy.sni.co.uk> X-NNTP-Posting-Host: squidgy.sni.co.uk Encoding: 207 TEXT X-Mailer: Microsoft Mail V3.0 X-Mail2News-Path: gate.sni.co.uk!squidgy.sni.co.uk 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.....