An LCD Retrofit and color display for the SI 4031 Communications Test Set

Figure 1:  The front panel and original green monochrome screen of the 4031.  A close look shows the "blistering" on the screen protectors due to delamination, making the display more difficult to read. Click on the image for a larger version.

The Schlumberger SI 4031 is a early-mid 1990s vintage communications test set (a.k.a. "Service Monitor") - a device that is designed to test both receivers and transmitters used in the telecommunications industry.  The 4031's frequency range is 400 kHz to 999.9999 MHz making it useful as a general-purpose piece of test equipment, particularly for the testing of amateur radio gear.

As you would expect from a device from the 1990s, the original display used a CRT (Cathode Ray Tube) based monitor operating at something "close" to PAL horizontal and vertical scan rates.  While the CRT monitor with this unit is still in reasonable shape - aside from requiring a "re-cap"(e.g. replacement of electrolytic capacitors) I decided to take on the challenge of putting a more "modern" LCD-type display in it - perhaps taking advantage of a minor savings in both weight and power consumption.

Note that this requires no electrical modification of the 4031 itself and only minor mechanical changes to mount the LCD panel and its related hardware.  (This may also work for the 4032, a version of this unit that covers up to 2 GHz - see below for comments.)

Is it "PAL"

While the pedants would say that a monochrome-only signal cannot be PAL, the reference is, instead, to the horizontal and vertical scan rates of 15.625 kHz and 50 Hz, respectively which are close to those found in the PAL system as used in Europe.  As is typical for pieces of non-consumer gear and test equipment, the horizontal and vertical synchronization signals are brought out independently of each other, and the video, each being represented as a TTL signal.

Figure 2: The horizontal sync pulse train showing 25% D.C. pulses at 15.625 kHz, TTL level. Click on the image for a larger version.

The video display generator of the 4031 is interesting in that it uses a UPD7220A graphics controller to facilitate interaction with the CPU (e.g. access memory, produce characters, etc.) but two separate display RAMs (8k x 16 bits) with one being used for access by the UPD7220A and the other, copied from the first during the vertical interval, for pixel read-out - the latter function being done with a combination of "glue logic" and programmable logic devices.

The forgiving CRT monitor

One nice feature of a CRT monitor is that it can be quite forgiving of deviations from standard video applied to it.  Many - but not all - all-in-one sync decoder chips used in CRT monitors are happy with taking horizontal and vertical signals that are "close" to some standard - but not exact - and lock onto it satisfactorily.  Such is the case with the 4031:  While there are separate horizontal and vertical synchronization signals, neither is quite standard, but it's "close" enough for the old monitor.

Figure 3:  The vertical sync, showing a 10% duty cycle pulse at about 50 Hz. Click on the image for a larger version.

For example, the horizontal synchronization signal is simply an uninterrupted 25% duty cycle pulse train occurring at the horizontal sweep rate of about 15.625 kHz (e.g. 16uSec long) while the vertical synchronization is a 50.08 Hz 10% duty cycle (e.g. 2 msec long) pulse train.  Unlike sync signals found in other applications, the horizontal signal does not contain any sort of blanking (suppression of pulses) during the vertical interval.

Within the 4031's original CRT monitor, the horizontal and vertical synchronization signals are handled completely separately(by a TDA2593 and TDA1170, respectively) so the fact that they are non-standard is irrelevant.

Unfortunately, any modern LCD display device that is expecting a PAL-like signal (in terms of timing) isn't going to be happy with separate, non-standard synchronization inputs.

Initial attempts:

Initially, I was hoping that an off-the-shelf LCD monitor display like the 7", 4:3 aspect CLAA070MA0ACW with a driver board could be made to work with these signals with no other hardware, but my work was thwarted by the fact that its VGA input - which might handle separate horizontal and vertical sync signals - would not function at PAL video rates - only VGA rates, which have roughly twice the horizontal and vertical frequencies.  While it may have been possible to modify the code on this board and re-flash it with one of the "customized" versions found in corners of the Internet, I chose not to do this.

I then attempted to make a simple analog sync combiner circuit and apply the signal to the composite video input, but found this to be unstable - plus there was the fact that the video display board itself did not have the capability of setting the horizontal and vertical size to fully-fill the screen to the edges - something desirable to make the active screen area fully-fit the window on the front and also align with the buttons along the bottom of the screen.

After a bit more research, I decided to get a GBS-8200 video converter board (Version 4.0), a relatively inexpensive digitizing board designed to convert the myriad of video formats from CRT-based arcade video games and computer inputs to VGA which would then be inputted to a standard monitor and the CLAA070MA0ACW display driver board.  As such, I presumed that it would be far more forgiving to variations from standard video signaling - and I was, fortunately, correct

Sync (re)processor:

While I was originally hopeful that I could simply apply the horizontal and vertical sync inputs to the GBS-8200, the non-standard sync timing (pulse width, lack of a gap of horizontal sync pulses during the vertical interval) did not produce stable results, so a simple circuit had to be devised to modify the sync signal:  This basic circuit is shown below.

Figure 4: Diagram of the sync processor itself. This circuit will produce a sync to which the GBS-8200 board can lock.  The single video output is connected to the RGB input of the GBS-8200 to produce a monchrome (single color) display as seen in Figure 6. Click on the image for a larger version.

This circuit works as follows:  The horizontal and vertical sync pulses are input to and buffered by sections of a 74HC14, Schmidt-trigger inverters which server to "clean up" the input signals as necessary.  An inverted version of the vertical sync pulse holds U3, a 4017 counter in reset until a vertical interval occurs.

Figure 5: The circuit in Figure 4 built on a prototyping board, the results seen in Figure 6. Click for a larger image.

During the vertical pulse U3, the counter, is clocked by the horizontal sync pulse and on the 5th count, the timer is stopped, setting the input of U2b, a 4011 NAND gate wired as a simple inverter, high.  The output of this gate is combined with a "re-inverted" copy of the vertical sync to produce a new version of the vertical sync that is about 225 microseconds long rather than the original 2 milliseconds as depicted in Figure 7 (below).

FWIW, I used the 4011 NAND gate because I found a rail of them, but I couldn't find any 74HC00 which would have worked fine - albeit with a different pin-out.  Similarly, a standard CMOS 4017 counter would have been fine as well.  I would, however, recommend using only the 74HC14 (or 74HCT14) as it's plenty fast for the video data and it has fairly "strong" outputs (e.g. source/sink currents) as compared to the older and slower 4069 hex Schmidt inverter.

Note that while it would theoretically be possible to use a one-shot analog timer to generate a new, shorter pulse, doing so would result in visible jitter of the video signal (I tried - it did!) as that timing would neither be consistent or its length precisely synchronous with the horizontal timing:  The use of the horizontal sync to "re-time" the duration of this new vertical pulse assures that the timing of the new pulse is synchronous with both sets of pulses and completely jitter-free.

This new, re-timed vertical sync pulse is then applied to U2a which gates it with the horizontal sync:  The output is then inverted to produce a composite sync signal (see Figure 7, below) that, while not exactly up to PAL standards, is "close enough" for the GBA-8200 video converter to be happy.

Elsewhere in the diagram may be seen inverter sections U1d-U1f:  These are configured as buffers to condition the TTL video input and provide a drive signal to the video input of the GBA-8200.

Suitable for a monochrome image!

The circuit in Figure 4 is sufficient, by itself, to drive the GBS-8200 and produce a stable VGA version of the 4031's video signal.

Figure 6: The monochrome output from the GBS-8200 board using the sync processor seen in figures 4 and 5 via an external monitor. Click on the image for a larger version.

The "VID_OUT" signal may be connected to the Red, Green and Blue video inputs of the GBS-8200 and the input potentiometers adjusted for a single color:  White will result if the individual channels' gains are set equally, but green, yellow or any other color is possible by adjustment of these controls.

Figure 6 shows the result of that:  The VGA output from the GBS-8200 was connected to an old 4:3 computer monitor that I had kicking around, producing a beautiful, stable, monochrome signal.

Full-color output from the 4031

The SI 4031's video output is a single TTL signal, meaning that there is not even any brightness information, making it capable of monochrome only.  Fortunately, it is possible to simulate context-sensitive color screens with the addition of a bit of extra circuitry and firmware as described below.

The portion of this circuit used for processing the sync pulses is based on that shown in Figure 4:  A few reassignments of pins were done in the sync re-timer, but the circuit/function is the same.  What is different is the addition of U5, a quad 74HC4066 analog switch and U6, a PIC16F88 microcontroller, and a few other components.

How it works:

The video signal is buffered by U1d-U1f and applied to R1, a 200 ohm potentiometer, the wiper of which is applied to Q1, a unity-gain follower to buffer the somewhat high-impedance video from R1 to something with a source impedance of a few ohms and, more important, constant output with varying load.  The "bottom" end of R1 is connected to U5c, on section of the 74HC4066 which, if enabled, will shunt some of the video signal to ground, reducing its intensity, adjustable via R1.  Via diode D1, this line is also connected to a pin of the microcontroller - the "MARK" pin - more on this later.

Figure 7: Top (red) trace: The composite sync from the circuit of Figures 4 & 8.  Bottom (yellow) trace: The original vertical sync pulse  for comparison. Click on the image for a larger version

The output of Q1 is then applied to U5a, U5b and U5d via 100 ohm resistors.  These analog switches will selectively pass the video to the Red, Green or Blue channels of the monitor, depending on microcontroller control.  At the outputs of each of these switches may be found a resistor and diode in series (e.g. D2/R6) and these are connected to output pins of the microcontroller:  If these pins are driven low by the microcontroller, the diode drop and series resistance of the 33 ohm resistor (e.g. R6) and the 100 ohm resistor (e.g. R3) and the output transistor of the microcontroller will reduce the amplitude on that channel to provide a means of brightness control.

I'd originally intended to place emitter-follower video drivers (e.g. the circuit of Q1) on each of the R, G, and B outputs, but the very short lead length to the input of the GBS-8200 - and the ability to adjust the RGB input gain via its three potentiometers eliminated this requirement as additional losses could be easily compensated.

Figure 8: Added to the sync processor of Figure 4, above, is a PIC16F88 used to analyze the video from the 4031 and "colorize" the resulting image.  See the text for information as to how this works. Click on the image for a larger version.

With the combination of the three 4066 gates, the "!BRITE" pin, and the three "dim" pins (e.g. "!R_DIM", "!G_DIM" and "!B_DIM") over two dozen distinctly different colors and brightness levels may be generated under processor control.

The magic of the microcontroller

U6, a PIC16F88 microcontroller, is clocked at 20 MHz, its fastest rated speed.  Because its job is to operate the four switches comprising U5 - and the three "dim" pins on the video lines - it must "know" a bit about the video signal from the 4031:

• The "!V_SYNC" pin gets a conditioned sample of vertical sync from the output of U1a:  It is via this signal that the U6 "knows" when the scan restarts at line one.
  
• The "!H_SYNC" signal from the output of U1b is applied to pin RB0, which is configured to trigger an interrupt on the falling edge (the beginning) of the horizontal sync.
• The "!VID" signal is applied to pin RA4, which is the input of Timer 0 within the microcontroller:  This is used to analyze the content of lines of video to determine the specific content as the timer is able to "count" the number of times that the video goes from low to high on these scan lines -  In other words, a sort of "pixel count".
  

In operation, the start of each horizontal sync pulse triggers an interrupt in the microcontroller.  If this coincides with the start of the vertical interval, the line count is restarted.

Video content analysis:

Figure 9: Mounted inside the 4031, the sync processor board is on the far left, the six pins of the ICSP (In Circuit Serial Programming) connector being easily accessed.  The buttons and controls for the other two boards are also accessible. Click on the image for a larger version.

Visual inspection of each of the screens on the 4031 will reveal that they contain consistent - but unique - attributes.  Most obvious is the title of the screen located near the top, but other content may be present midway down the screen - or very near the bottom - which may be used to reliably identify exactly which screen is being displayed, having determined the "pixel count" for certain lines on each of these screens beforehand.

For each subsequent horizontal sync pulse and corresponding interrupt, the count contained within hardware timer 0 is read - and the timer is immediately reset.  For a number of specific scan lines, their unique counts are stored in RAM.

Attention to detail is required!

Determining the pixel count consistently requires a bit of care in the coding.  As mentioned, this count is based on an interrupt-driven routine that reads the content of hardware timer 0 - but this also means that the code must be written in a way that guarantees that the time between the start of the horizontal sync pulse (and subsequent entry into the interrupt service routine) and the read and reset of timer 0 is as consistent as possible, considering the asynchronicity of the timing of this interrupt and the CPU clock.

What this implies is that the reading this timer and its resetting must not only be done in an interrupt, but that it also be the first thing done within the interrupt function prior to any other actions, particularly any conditional instructions that could cause this timing to vary, resulting in inconsistent pixel counts - something that would preclude the use of anything other than a quickly-responding interrupt.  Another implication is that this interrupt may be the only interrupt that is enabled as and preemption by another one would surely disrupt our timing.

Immediately following this action is the setting of the color and brightness attributes by ANDing a copy of the current content port/pin registers to remove the brightness/color bits and then ORing that data with the pre-calculated color/brightness bit mask data into those same registers so that any changes in these attributes occur to the left of the visible pixels in the scan line.

A limitation of this hardware/software is that it is likely not possible to satisfactorily set different colors horizontally, along a scan line - it is possible only to change the color of complete scan lines:  To do this would, at a minimum, require extremely precise timing within the interrupt service routine, adding complexity to the code - and it's not certain that satisfactory results would even be possible.   To do it "properly" would certainly require more complicated hardware - possibly including the regeneration of another clock from the horizontal pixel rate - but doing this would be complicated by the fact that the pixel read-out rate is asynchronous with the sync as noted later.

Using the pixel counts:

At the beginning of the vertical interval, outside any interrupts, the previously-determined counts of low-to-high transitions is analyzed via a series of conditional statements and a variable is set indicating the operating "mode" of the 4031.  This "mode" information is then applied to another look-up table to determine the color to be used for that screen.

One complication is that like other analog video, that coming from the 4031 is interlaced meaning that for certain scan lines - particularly those with diagonal elements - that the pixel count may vary for a given scan line.  Unlike "true" video, the sync pulses from the 4031 contain no obvious timing offset (e.g. "serrations" in the sync) to offset by half a line or identify the specific video field, but with an analog monitor, this wasn't really much of an issue as it would simply paint a line on the screen in about the right place, anyway.

For most screens, simply looking at pixel counts of between four and six lines - most of them on lines from 4 to 15 - was enough to uniquely identify a screen, but others - particularly the "Zoom" screens - sometimes require even a greater number of pixel counts to reliably and uniquely identify the screen.

In particular, differentiating between the "SINAD" and "RMS-FLT" Zoom screens was problematic as both resulted in the same pixel counts for all of the lines usable for unique identification:  The only way to detect the difference was due to the fact that for some lines, the pixel count for the "SINAD" screen would vary due to the aforementioned video field difference - or possibly due to interaction between the asynchronicity of the pixel clock, the CPU clock, and the way counts are registered on a counter input without hardware prescaling.  It was the fact that it varied that allowed it to be reliably differentiated from the "RMS-FLT" screen, which had a very consistent pixel count.

Coloration of the screen:

Many screens on the 4031 have different sections.  For many screens, the upper section contains the configured parameters (e.g. frequency, RF signal level, etc.) while the lower portion of the screen shows the measured values or an oscilloscope display:  Simply by knowing which screen type is being displayed and the current line number, those sections can be colored differently from other portions.

Deciding what color to make what is a purely aesthetic choice, so I did what I thought looked good.  Because about two-dozen different colors are possible, I chose the brightest colors for the most commonly-used screen segments, setting these colors by the function to which they were related.

Finally, all screens have, along the bottom, a set of labels for the buttons below the bottom of the screen:  These may be colored separately as well - and I chose gray (a.k.a. "dim white").

Analyzing the video to determine "pixel counts":

When writing the firmware, a few simple tools were included, notably some variables, hard coded at compile time, that would display the pixel counts.  If, for example, one needed to determine the pixel count for line #14, the pixel count display variable would then be loaded with the pixel count for line 14.  For example, the oscilloscope screen capture shows a pixel count capture:  The left-most pulse is 4 units long followed by a single-unit pulse (meaning "10") followed by a 2 unit long pulse with three more pulses - for a pixel count of 13.

Figure 10: An example of the "pixel" count:  The 4-unit wide pulse followed by one pulse represents 10 and the 2-unit wide pulse followed by 3 pulses represent a pixel count of 13 on the selected line. Click on the image for a larger version.

Another variable may be set to visually identify which scan line is being counted.  When the scan line being counted occurred, the "MARK" pin would be set high causing an on-screen indication of which line was being inspected, offering a "sanity check" and a visual reference to know which line, exactly, was being checked.

During the vertical interval, pin "RB3" would then be strobed with a series of pulses to indicate the pixel count - a "long" pulse lasting four CPU cycles followed by pulses of 1 CPU cycle, each to indicate the "tens" digit (if any) and a shorter pulse of two CPU cycles followed by the requisite number of 1 CPU-cycle pulses to indicate the "ones" digits. 

Using an oscilloscope triggered on the signal on RB3 (pin 9) these pulses could be read visually on the oscilloscope and by switching between the different screens on the 4031, the "pixel count" of this line for the various screens could be determined:  Repeating this for several different scan lines allow unique identification of all screens.  In the event that there is false detection of a mode, this "pixel count" output could also be configured to show the number of the current modes (in a "#define" statement) when they are detected to aid in debugging.

Comment:

In producing this firmware, I have only one version of the 4031 (with Duplex option) available to me.  Different versions of the 4031 - and the 4032 - may have "other" screensnot included in the analysis, or slightly different layout/labeling that will foil the analysis of the scan line.

The way the firmware doing the screen analysis is written, if the scan line analysis doesn't find a match to what it already "knows" about it will cause that screen's text to be displayed in the default color of white.

At present this "scan line analysis" can only be done by setting certain variables in the source code and recompiling - but this was made easier by the inclusion of the "ICSP" connector (visible in Figure 9) to allow in-circuit programming, while the unit is operating.  In theory, it may be possible to come up with some sort of user-interactive means of setting individual screens' colors which could be used to set the colors on screens of different firmware versions or with features that I don't have in my 4031, but this would require significantly more work on the firmware.

Figure 11: The 4031 with the retrofit LCD operational. This isn't a perfect photo because it's very difficult to take a picture of an operational electronic display! Click on the image for a larger version.

Color mode selection:

With the lack of the CRT monitor, there is no need for an "intensity" control, but rather than leave a hole in the front panel a momentary switch was fitted at this position.  Connected between ground and pin RB7, using the processor's internal pull-up resistor, this switch is monitored for both "short" and "long" button presses.

A "short" press (less than 1/2 second) toggles between "bright" and "dim" using the same color scheme, but a "long" press (1.5-2 seconds) changes to the next the color mode.  At the time of this writing, the color modes are:

• Full-color screens.  The screens are colored according to mode and context as described above.
• Green.  All components of the screen are green.
• Yellow.  Like above, but yellow.
  
• Cyan.  Like above, but cyan.
• Pink.  Like above, but pink
• White.  Like above, but white

In some instances (e.g. high ambient light) selecting a specific color (green or yellow) may improve readability of the screen.  These settings selected by the switch are saved in EEPROM (10 seconds after the mode was last changed) so that they are retained following a power-cycle.

* * * * * * *

The hardware

Several bits of hardware are required to do this conversion and if you are of the ilk to build your own circuits, nothing is particularly difficult.  Personally, I spent at least as much time making brackets and pieces and mounting the hardware in 4031 as I did writing the firmware.

Sync processor:

At a minimum, the "simple" sync processor mentioned above (Figure 4) is required to provide a synchronization pulse that is recognizable by the converter board.  If one doesn't wish to have different color modes available, this is certainly an option.

Having said that, the "colorized" 4031 afforded by the circuit described in Figure 8 is quite nice - perhaps a bit of an extravagance.  If the 4031 were originally equipped with a color monitor, I can imagine it looking something like the the images in the "Gallery" section of this article, below.

GBS-8200:

Figure 12: The GBS-8200 video converter board.  This is "V4.0" of the GBS-8200 which includes an on-board voltage regulator allowing it to run from 5-12 volts. Click on the image for a larger version.

There appear to be several versions of the GBS-8200 around - possibly from different manufacturers and some of these are designed to be operated from a 5 volt supply ONLY, but many have on-board voltage converters, allowing them to be operated from 5 to 12 volts:  The version that I have is the "V4.0" board with a "5-12 volt" input which eliminates the need for yet another voltage conversion step.  If you look carefully at the photo of the GBS-8200, the inductor for the buck converter is visible near the upper right-hand corner of the board, between the power connector the white video-out connector marked "P12" - but the silkscreened "DC 5V-12V" is also a big give-away!

This board, readily available via EvilBay and Amazon for well under US$40, is specifically designed to take a wide variety of RGB video formats - typically from 70s-90s video games and computers - and convert them to VGA format.  There are several connectors for video input seen along the bottom edge of the photo:  The three phono plugs for component video, an input on a VGA connector, and next to the VGA connector, two white headers for cable:  The unit that I purchased included a cable that plugs into the header between the VGA input and the three potentiometers.

At the top of the board, the VGA connector outputs the converted video - but there is also a white header next to it with these same signals.  As mentioned elsewhere, I simply soldered the six wires (R, G, B, H, V, and Ground) to the board, at this white header as I didn't happen to have another male HD-15 cable in my collection of parts.

This device can accept YUV and RGB inputs - and the latter can have either separate or composite sync inputs.  As the sync signals from the 4031 are non-standard, it's required that the sync processor described above produce a composite sync and the GBA-8200 be switched to the "RGBS" mode (using the "mode select" button) where the composite sync is fed into the "H-Sync" input and the "V-Sync" input is grounded.

The RGB inputs to the GBS-8200 come from the 4031, either as a single video source that is connected to all three inputs in the case of the "simple"(monochrome) version of the sync processor or from the RGB lines of the color version.  On board the GBA-8200 are three potentiometers visible in the photo above (near the lower-left corner) that are used to scale the input levels of the RGB signals to provide color tint/balance as desired.  In the lower-right corner can be seen the buttons used to configure the GBS-8200.

External monitor:

The use of the GBS-8200 has an interesting implication:  It would be perfectly reasonable to use an externaldisplay with a VGA input (or VGA to HDMI converter) with the 4031.  This has the obvious advantage of being larger and the possibility of being placed conveniently when making adjustments where the 4031's itself may be too distant or awkwardly placed.  Additionally, it offers the possibility of being able to display to a larger group of people (e.g. teaching) and being digitized and recorded, as was done with the images at the bottom of this article.

Simply connecting a monitor to the VGA output of the GBS-8200 in parallel with the built-in LCD monitor would work - perhaps even as a short, permanent cord mounted to the rear (somewhere?) or hanging out of the 4031 should this be frequently required.  With a short (8", 20cm)"extension" cable permanently connected, any degradation caused by having an unterminated cable (when the external monitor was not connected) could likely be ignored and the rather low resolution of this display - as could be the slight diminution in brightness - when two monitors were connected at the same time (e.g. "double terminating").  Practically speaking, a buffer amplifier could be built to isolate the R, G, B and sync signals (using the simple emitter-follower circuit of Q1 see in Figure 8) to feed the external monitor.

Because there's no obvious place on the back panel to mount such a connector - and since I don't envision the frequent need for it - I did not so-equip my '4031.

Navigating the GBS-8200's menus

The four buttons used to configure the board are seen on the corner of the board at the top of the photo above.  Initially, the GBS-8200's menu system may be in Chinese, but the 4th menu allows the selection of either English or Chinese and it is changed to English with the following button-presses:

• Menu - > UP -> Menu -> Menu 

At this point the text is now in English.

Other screens include:

• "Display" - Which sets the output resolution:  A setting other than 640x480 is suggested.
  

• "Geometry" - Which sets the position and sizes, along with how the blanking interval is to be treated.  Suggested initial settings are:
• H position: 94
• V position: 26
• H size 56
• V size: 66
• Clamp st:  83
  
• Clamp sp: 94
  

• "Picture" - Which sets other display properties.  A setting of 50 is suggested for Brightness, Contrast and Saturation and a value of 05 is suggested for Sharpness.

The CLAA070MA0ACW display:

This is a 7" diagonal VGA screen of 4:3 aspect ratio and is available with a driver circuit board on EvilBay for around US$50.  Be sure that you get the version with the display controller board and not just the bare display panel, by itself. 

This unit is rated to operate from about 6 to 12 volts, and it comes with both an infrared remote and a small daughter board and interconnect cable that replicates the functions of the remote:  The remote is not required for this project as the daughter board and its pushbuttons will suffice.

Figure 13: The driver board supplied with the CLAA070MA0A0ACW LCD panel.  At the top is the VGA input while the TTL to the panel is at the bottom, the back-light power connector being in visible in the lower-right corner of the board. Click on the image for a larger version.

The LCD panels themselves appear to be "pulls" from some consumer product (perhaps a portable DVD player?) as they have evidence of having been previously mounted, but the price is reasonable and their size is precisely that which may be used in lieu of the 4031's CRT, being a few millimeters larger than the window on the front of the 4031 in both axes making them a perfect fit by virtue of their being 4:3 aspect ratio:  It's possible that one could find a newer 16:9 that would fit horizontally in the available space, but it would likely leave a gap above and below the screen.

This unit will accept composite analog, HDMI and VGA, but it is VGA that we require, fed from the GBA-8200 via a short cable:  I constructed a very short (3", 7.5cm) cable, soldering one end directly to the GBA-8200 board itself (I could find only one 15 pin HD connector) just long enough to reach the VGA input connector of the display.  If desired, one could install a switch/distribution amplifier and provide a VGA connector to feed an external display - or likely get away with "double terminating" it as noted elsewhere.

This LCD came with a small board taped to the back of the display that is used to convert to a the flat ribbon cable supplied with the unit, used to connect to the display controller board via the "TTL OUT" connector:  This PC board should be glued to the back of the LCD panel with RTV or other rubberized glue (but not cyanoacrylate!) to mechanically secure it or else it is likely to work its way loose and tear the cable from the LCD panel.  When connecting to the "TTL OUT" connector on the main driver board, one must carefully lift up the locking lever (the black plastic piece that runs its width) from the back on the connector, slide in the cable, and push the lever back down.  The cable itself isn't marked as to which way is "up", but putting it in upside-down won't damage anything - but you'll see nothing on the screen:  Mark this cable when you determine its proper orientation.

There is also a short cable provided for powering the LCD panel's back light:  You won't likely see anything on the panel if this is not connected!

Figure 14:  The original screen protector with EMI shield, held in place with 10 screws and two brass angle pieces around its perimeter.  This holds the front bezel in place. Click on the image for a larger version.

Mounting the LCD panel:

The display is mounted "upside-down"(the wider portion of the metal border around the LCD panel being on top) to clear mechanical obstructions around the front panel of the 4031.  Fortunately, configuring for this display orientation can be accommodated via a menu on the display driver board as follows:

• Select the "Function" menu
• Go to "Mode"
• Use the up/down buttons to select "SYS2"

The ONLY modification required of the 4031 to use the LCD display is mechanical.  Unlike the original CRT module - which was mounted in a large cavity behind the front panel - the LCD itself is mounted to the front panel of the 4031 while the other circuit boards (sync processor, GBA-8200,  CLAA070MA0ACW controller board) are mounted in the cavity formerly occupied by the CRT.

Figure 15: The original screen protector (center) and copies, sitting atop the laser cutter.  These were cut from 0.060" thick poly- carbonate plastic. Click on the image for a larger version.

Front screen protector: 

On the 4031s that I have, the CRT is protected by a plastic sheet containing embedded metal mesh for RFI/EMI shielding - which didn't actually seem to be grounded, anyway.

Unfortunately, over the years, this sheet tends to de-laminate and "bubble",  making viewing the screen rather difficult, so I duplicated a replacement using 0.060" polycarbonate using a laser cutter.  The use of polycarbonate over other types of clear plastic (like acrylic) is recommended due to its resiliency:  It can be bent nearly in half without breaking and is likely to stand the occasional impact from the cable of a connector or bolt without cracking.  Acrylic, on the other hand - unless it is quite thick - would crack with such abuse.  For convenience, the dimensions of this screen protector are shown below.

While the original screens had EMI/RFI mesh embedded within them, these replacements will not.  The "need" for such shielding may be debated, but its worth noting that many similar pieces of equipment have no such shielding.  I did a bit of searching around for plastic windows with embedded mesh, but other than a few random surplus pieces here and there, a reliable source could not be found.

Figure 16: The dimensions of the screen protector - just in case you might want to make your own! Click on the image for a larger version.

One possible saving grace is the nature of the CRT versus the LCD:  A CRT has the potential (pun intended) to cause EMI owing to the fact that its surface is bombarded by an rapidly-changing electron beam that varies at MHz frequencies - and this can radiate a significant E-field.

The LCD, on the other hand, is a flat panel with low voltage and backed by a grounded metal plate, so the opportunity for it to radiate extraneous RF is arguably reduced.

Removing the front panel:

The front face of the 4031 comes off as a unit by removing the "Intensity" control knob, the two screws on either side that hold it into the unit's frame (the "second" screws from the top/bottom) and carefully unplugging three ribbon cables.  Inspection reveals that the screen protector is, itself, mounted to a bezel held in by several screws.

In my 4031, the original  the (de-laminated) front screen protector is extricated by removing the ten small screws around its perimeter - and noting the way the pieces of brass angle that may be included are mounted - which allows it and front bezel to come out:  It looks to me like this screen protector may have been replaced in the past and it could be of slightly different construction than what was provided from the factory - but this is only a guess.

Figure 17: After fully-tapping the 2.3mm screws, these aluminum angle pieces with slots were attached to the aluminum bars seen in Figure 14.  It is into these bars that the LCD panel, with attached brackets, mount. Click on the image for a larger version.

Removing front screen protector will reveal two aluminum bars on either side - each with metal "finger stock" on the "inside" of the screen area - mounted to the front panel by countersunk screws hidden by the bezel that holds the screen cover.  Inspection will reveal that there are three holes along these bars that are not tapped all of the way through.  I removed these bars and purchased a 2.3mm tap and completed the threads so that I could insert 2.3mm x 6mm screws from the "other"(back) side.  It would have been about as easy to have drilled entirely new holes and tapped them for 4-40 screws (or your favorite Metric equivalent) and, in retrospect, I should have probably done so.

Using scrap pieces of aluminum, a pair of angle brackets were fashioned, held to the aluminum bars by the newly-tapped screws in those bars as seen in Figure 17.

To accommodate the momentary switch, I had to file away a portion of the bracket and bar on the left side ("behind" that in Figure 17 and this not visible) as well as countersink the back side of the plastic lens bezel so that it would accommodate the mounting hardware of the momentary switch and sit flush.

Into the brackets, slots were cut with a saw - also visible in Figure 17 - and it is into those that the angle pieces - now attached to the LCD - slide to allow adjustment of depth and very slight adjustment of axial rotation.  The LCD was located about 3/8"(10mm) behind the polycarbonate lens for clearance to protect the LCD panel itself should something be dropped on it - like a cable, RF connector or tool.

Figure 18: The two brackets and new screen protector mounted in the front panel assembly of the 4031. Click on the image for a larger version.

As seen in the pictures, there is no obvious way to mount the display itself so a section of right-angle aluminum was cut and these were glued using "Shoe Goo"(a resilient rubber adhesive) to the back of the display itself, using the mounts fabricated to hold the display itself in position (described below) as a positioning guide:  It's likely that RTV (silicone) would have worked as well but I would not use an ineflexible adhesive like epoxy or cyanoacrylate ("Super Glue").

As this is done, it's very important to make sure that these brackets are installed correctly so that the display is both centered and square with the 4031's window:  I recommend actually mounting the display in place while the adhesive sets so that it perfectly fits the mechanical environment and there is no stress on the display itself as screws are tightened when it is mounted. When I did this, I put some "painters tape" on the front of the display and lightly marked it so that I could precisely set the horizontal and vertical position of the display with reference to the front bezel before the glue set.

Electrically connecting to the 4031:

Figure 19: Two aluminum angle pieces with holes were glued to the back of the LCD panel, now mounted in the front panel. Click on the image for a larger version.

The connection of the original monitor to the 4031 is via an industry-standard 14 connection IDC ribbon cable/connector connected to the monitor and an exact duplicate was ordered from Digi-Key (P/N:  H1CXH-1436G-ND).  On this cable are the ground, power, sync and video connections as follows:

• 1, 2:  +15 volts
• 3-6:  Not connected
• 7:  Vertical sync (positive-going pulse, TTL level, 50 Hz)
  
• 8:  Ground
• 9:  Horizontal sync (positive-going pulse, TTL level, 15.625 kHz)
  
• 10:  Ground
• 11:  Video  (positive-going, TTL level)
  
• 12:  Ground
• 13, 14:  Not connected
  

It's perhaps easiest to empirically determine these pins by stripping a small amount of insulation from the end of the wires and using a combination of volt/ohmmeter and oscilloscope to positively identify them, the ground pins being identifiable plugging in the other end of the cable and using continuity to the chassis with the unit powered down and then (carefully!) verifying them with the unit powered up, beingvery careful to avoid connecting the +15 volt wires to anything else.  Once identified, the wires that are marked as "not connected" were trimmed back slightly, the two +15 volt and three ground wires were (separately!) connected in parallel and the wires themselves colored using markers to aid in later identification.

Mounting the boards:

Figure 20: The "stack-up" of the boards on the mounting sled.  Hidden by the ribbon cable is the sync processor, above that is the the GBS-8300 with its output VGA connector and above that is the LCD controller with 4-button daughter board. At the bottom, on the sled, may be seen the 7812 regulator used to drop the 15 volt supply to 12 volts. Click on the image for a larger version.

A "sled" about 6"(155mm) wide and about 4.75"(120mm) tall - designed to be mounted to the left-hand wall (as viewed from the front panel) inside the enclosure.  This was constructed from a sheet of scrap aluminum and on it, the sync processor board, the GBS-8200 and the LCD controller were mounted using an assortment of stand-offs.  The different shapes and sizes of these boards complicated matters, so I had to be creative, resorting to mounting the LCD controller - and its daughter board (with pushbuttons and infrared receiver) to a piece of glass-epoxy PCB material that was, itself, held in place with stand-offs, seen in Figure 20 as the board on the vary top.

While I happen to have a bunch of stand-offs in my parts bins, I could have just as easily mounted the boards using long screws or "allthread" along with an assortment of nuts and washers.  These days, a more elegant custom mount could also be 3D-printed to hold these boards in place, although the metal "sled" and stand-offs offer a solid electrical connection to the chassis that may aid in RFI shielding and mitigation.

The only critical things in mounting are to provide access to the ICSP connector and R1 ("gray" adjust) on the sync processor board, the buttons on the GBS-8200, and the buttons on the daughter board on the LCD controller:  All of these should be accessible with just the top cover of the 4031 removed, without needing to disassemble anything else as depicted in Figure 21.

Figure 21: Installed and powered- up, the stack-up of boards and connected LCD panel.  All controls - and the ICSP connector - are accessible simply by removing the top cover of the 4031. Click on the image for a larger version.

Into this "sled" were pressed self-retaining "PEM" nuts and it is mounted at four points in the same slots (using 8-32 screws) on the left side of the frame that were used to mount the original CRT monitor.

Powering the boards:

As noted above, the GBS-8200 is available in a version that may operate from 5-12 volts.  Similarly, the LCD panel's board can also accommodate up to 12 volts - but the 4031 supplies 15 volts.  During development, I ran both boards on 15 volts directly with no issues, but I noted that 16 volt electrolytic capacitors were used on the inputs, so 15 volts would be pushing their maximum ratings.

Despite having no issues, I decided not to take a chance, so I added a 7812 voltage regulator, bolting it to the aluminum "sled" for heat-sinking (see Figure 20) and powering both the GBS-8200 and LCD panel from it.  As seen from the diagram above, the sync processor includes its own regulator (a 7805) and it may be powered from either 12 or 15 volts.

Overall results

Figure 22: Under the shield of the "Monitor Control" board is R16, the "width" adjustment that may be use to optimize video quality. Click on the image for a larger version.

The results of all of this work look quite good as can be seen in the picture gallery below, but there are slight visual artifacts owing to the fact that the VGA conversion is from a device (the '4031) that does not have its pixel clock synchronized with the sampling clock of the GBS-8200 - or even the horizontal sync pulse.  The inevitable result is - if you look closely - that you may see some slight "glitching" on the leading or falling edge of vertical lines.

This effect can be reduce somewhat by adjusting the read-out pixel clock from the 4031's Monitor Control board.  Located on this board, under the shield, is potentiometer R16.  Nominally set to 11.0 MHz (as monitored at test point "Mp10") the frequency of this clock output may be reduced by turning this potentiometer slightly clockwise, reducing the effects of this aliasing somewhat by increasing the "width" of the display by making it output the line of video "slower".

If this adjustment is done, it should be done iteratively:  If it is set too low, the beginning of the line will start before the current line has finished drawing causing you to be able to see the left edge of the screen along the far right edge.  By adjusting the "Horizontal Width" on the GBS-8200, some of this overlap can be moved off the right edge of the screen so a balance between this and a low clock frequency must be found.  The approximate frequency set by R16 after this adjustment is between 7.75 and 8.0 MHz.

As mentioned earlier, trying to set a color horizontally across a scan line is not really practical:  The fact that, as we have seen, the pixel read-out rate is a free-running oscillator that is not synchronous with any of the the video sync pulses, so there is no "easy" way to synchronize a clock signal to set color attributes along the scan line from the video information alone.  To do so would require a sample of the pixel clock itself from the Monitor Control board!

In theory, it may be possible to tie the internal pixel clock to an already-existing clock signal on the Monitor Control board (e.g. the 8 MHz clock) to allow this and to reduce the "glitching" that is sometimes visible:  This modification is open to investigation.

---