The displayI took the display apart to see if it could be fixed but that wasn't the case. One of the driver chips obviously was broken. I quickly found a Chinese Ebay seller which claimed to have the display for $140 + $40 shipping. Including customs duties and taxes the display would add up to 180 euros. Because of the age of the equipment the display could be from a salvaged unit with lots of hours and a dim CFL backlight.
I choose to apply my TFT conversion skills. I tracked down an 8" 800x480 screen (TX20D16VM2BAA) from Ebay which has almost the same size as the orginal screen. That left me with a bit of a problem; the original display has a resolution of 640x320. I need some scaling. Horizontal: 800/640=1.25 so I need 5 output pixels for 4 input pixels in the horizontal direction. Also the active area of the TFT screen is heigher than the original screen so I may need some stretching there as well.
The new display mounted: Some 3M double sided tape and stick-on feet keep it firmly in place. To prevent shorts between the backplate and the controller board I stuck some polyimide tape on the backplate.
The primary problem is to convert the data for the DSTN screen into information a TFT can work with. A DSTN screen is black/white and usually has 4 to 8 parallel data lines, a clock and vsynch+hsync signals. To complicate things more the pixels of a DSTN screen are typically 'modulated' to get grey scales. The more consecutive frames where a pixel is 'on' the whiter the pixel and vice versa. This means that a picture is spread in time over several frames. In the case of the E4421B the display has 8 bits and one picture is made up from 4 consecutive frames.
What I need for the TFT screen is to count the number of ones for each pixel over a period of 4 input frames. That is not going to happen on the fly. The refreshrates are also too different for that. Time for a CPLD and SRAM. The TFT screen uses a pixel clock of 32MHz but I'm not going to store RGB data in the SRAM. All I need is the count of the number of ones; 4 bits is more than enough for that. If I use a 16 bit SRAM I can supply 4 pixels of TFT data with one read cycle. The TFT data can be converted to RGB by using a fixed pallette. All in all that leaves three 32MHz clock cycles to do something else or use slower memory. I choose to use slower (45ns) memory so I can use 2 clock cycles for reading TFT data and 2 clock cycles for dealing with the DSTN data. But... remember I need to stretch the TFT data so I'm using 5 clock cycles in total (which means one TFT pixel gets repeated). In total 2 clocks to read TFT data, 2 for DSTN data and 1 for nothing. This means that I have 32M/5= 6.4 million memory time slots for dealing with the DSTN data.
The DSTN data is clocked at a rate of 2.1MHz -ish. I'm using the 32MHz clock to sample the edges of the dot clock, vsync and hsync. When a vsync arrives I reset the line counter and increment a frame counter. The hsync resets the dot counter and increments the line counter. The dot clock increments the dot counter. These counters can be combined into a memory address nicely. There is more than enough memory so no need to make things more complicated the necessary. The most complicated part is counting the number of ones over 4 frames. For each dot clock cycle it means reading the old value from RAM (or force the value to zero when dealing with the first frame), increment the value and store the value to RAM. So processing every DSTN pixel takes one read and one write cycle. That adds up to 4.2 million memory accesses per second. Since there are 6.4 million available memory bandwidth is not going to be a problem. Unfortunately there is a problem... The DSTN data is 8 bits wide. The first 4 bits are for the upper 160 pixels of the display, the second 4 bits are for the lower part. I can't process these in one go. I solved that by using 8 frames to produce one TFT screen display image. From the first 4 frames (1 to 4) the data from the upper 160 lines is used, the next 4 frames (5 to 8 ) are used to create the lower 160 lines. The last step is to use double-buffering to prevent the TFT screen showing how the pixels are counted. After 8 frames have been processed the display areas are swapped so the TFT screen shows steady data.
I designed a small board and had it made by Seeedstudio. The CPLD is a Xilinx XC95144XL; the RAM is a 512kx16 45ns SRAM from Cypress. The CPLD is in a TQFP144 package. I ordered the wrong package for a different project so I opted to design the PCB so I could use that one. By optimising the connections between the RAM and the CPLD the PCB has most traces on the top layer which kept it very compact. The XC9500XL series is 5V tolerant and has internal flash. It is a much nicer solution than an FPGA for a project like this. The only external components are a 3.3V regulator and an oscilllator module.
I also managed to source a connector which is the same as the connector on the original display. This means I can keep the existing display cable and don't need extra wires to the motherboard of the E4421B.
After several hours of VHDL coding and getting the timing right things start to look good but I forgot the active area of the new display is higher than the original display so stretching 320 lines into 480 lines isn't going to cut it:
After some fiddling the height is just right:
The fixed pallette conversion allows any color scheme. Who's afraid of red, yellow and blue?
Home
Help
Search
Login
Register
