Emulating the MN83803AK


updated Saturday, August 24, 2002

Site designed by Philip G. Stewart, Delectra Jouet

pstewart@gwi.net

August 24, 2002 update: Reworked section on mislabeled timing charts in the MN83803AK data sheets, hopefully pulling out most of the tangles from the writing.

We've discussed the possibility of emulating the MN83803AK as something to do if the chip ceases to be available, and if its putative replacement parts (viz. the MN83803AL) don't do the trick as they are supposed to. Here we consider what it will take to reverse-engineer the MN83803AK chip, as a design exercise. We follow the specifications given in the MN83803AK data sheets, showing in diagrammatic form and text what is clear and what isn't in the information the data sheets give.

You will probably want to print out a copy of our Adobe Acrobat PDF version of the MN83803AK data sheet from our Data Sheets page, to look at alongside this discussion.

Contents:

IA. General Design Plan
IB. Systems Used As Models For Our Design
IIA. Horizontal Sync Subsystem: Timings Required
IIB. Horizontal Sync Subsystem: Designing the Logic Circuitry To Provide These Timings
IIIA. Vertical Sync Subsystem: Timings Required
IIIB. Vertical Sync Subsystem: Designing the Logic Circuitry To Provide These Timings
IV. Remaining Questions


IA. General Design Plan (tentative, presented for review and critique)

There are two synchronization subsystems managing, respectively, the horizontal and the vertical timings. Our idea is:

(1) To phase-lock the main system clock to a signal derived from the incoming NTSC horizontal and vertical sync signals (this is done with a simple digital clock multiplier, using a phase-locked loop; see Horowitz and Hill's section on phase-locked loops in The Art of Electronics for an excellent introduction to this subject);

(2) To use the separated horizontal and vertical NTSC sync pulses to start the counts which the horizontal and vertical systems use to time their outputs-- resetting horizontal pixel count and vertical line count values at the onset of their respective synchronizing pulses; and

(3) To send outputs to the LCD at the appropriate voltage. If we use a TTL system to get our timings, we must use an open-collector driver chip such as the 7406 to raise our output voltages from those of 5-volt logic to the 18-volt logic the LCD requires. We must take care that our 18-volt logic is within the tight specified tolerances for the LCD, tolerances much tighter than those of TTL.

The general plan for the system can be seen in the following diagram:


IB. Systems Used As Models For Our Designs

By comparison, consider the design of National Semiconductor's programmable sync generator, the LM1882 (also known as the 74ACT715 and 54ACT715), shown below. As a digital video timing system, it shares with our system the same design constraints, and fulfills some of our design's functionality goals (though too few of them, apparently, to be useful-- in particular, it doesn't provide the walking-ring counter output needed to drive the MCL0712A03 LCD; and it is not designed to "genlock" to a master video sync. This lattermost function can be implemented digitally, as described in the chip's data sheets, but the simplicity of the kind of analog phase-locked loop that the MN83803AK employs is not designed for in the LM1882).

The LM1882's block diagram introduces the design principle that we will use in our horizontal and vertical subsystems, shown only as boxes in the block diagram above. Take note of the way the LM1882 times its outputs: It runs a counter and matches the outputs of this counter against the values programmed into its registers. Each register is matched to a binary magnitude comparator which waits for the counter to get to the value programmed into the register, and then when it does, gives an output signal to trigger whatever is supposed to happen at that moment (e.g., the onsets and offsets of the horizontal sync pulse). In our reverse-engineered system, the horizontal and vertical subsystems employ much the same counter-and-comparator design.

It is worth considering this block diagram to see how the clock and counter values are distributed. We see that the diagram is quite incomplete. In the diagram above, the pink highlight follows the clock's signal distribution within the chip. But how does the horizontal counter system communicate with the vertical, and vice versa? Where does the vertical system's clocking come from? These are nontrivial details that are of considerable importance to our own design.

Now let us consider the architecture of the MN83803AK, as depicted in one of the camcorder repair manual schematic diagrams (my apologies for the blurry diagram; storage space issues have limited the resolution of images I can work with).

Camcorder Schematic Detailing MN83803AK Setup

It takes some close inspection to make sense of this (the above) diagram; it also takes some careful reading of the MN83803AK data sheets. For example, Pin 9 (PCOUT) sends out a signal at twice the horizontal frequency, a square wave (50% duty cycle). This mixes with an output from the vertical system's Pin 8 (SSW), wends through an RC network, and feeds an input to the on-chip Voltage-Controlled Oscillator (VCO) at Pin 10.

Not shown in this diagram (to save space) is the source of the "Filtered V In" signal, shown as a yellow arrow at lower left. This signal comes off a bandpass filter fed by the line directly above it, "Video Input," highlighted in pinkish purple. So here, the Video Input feeds both the sync separator circuit on the chip (via Pin 6) and, via that bandpass filter, the VIN section of the vertical system (Pin 5).

The architecture of the MN83803AK is shown a bit more clearly in the diagram below, taken from the MN83803AK data sheets. In particular, in this diagram you can see the internal connections of Pin 7 (SYNCOUT).

The internal block diagram has been superimposed on the diagram showing the pin names, for convenience.

Remember that in some of the camcorder schematic diagrams we have found, the HCP and /HCP lines are reverse-labeled, as are the VCP and /VCP lines. Furthermore, in some diagrams we have found, the HCP1 through HCP4 pairs are numbered in reverse, corresponding to HCP4 through HCP1, respectively. We presume that all the labelings here, taken as they are from the MN83803AK data sheets, correspond to the labels of the same name in the charts found in these data sheets. Care should be taken, however, to establish that these markings are in fact consistent. See our schematics page for discussion of these inconsistencies between the camcorder repair manual schematics and the MN83803AK data sheets.

We do not closely follow the MN83803AK's design, as it is presented in these block diagrams from the camcorder repair manuals. It is simply not clear enough what is going on in some of the connections within the chip for us to use these diagrams as a model. However, you can see how the digital counting systems interact with the clock VCO, to get an idea of how the Matsushita chip yokes its output to the incoming NTSC video-- something our design must also do.


IIA. Horizontal Sync Subsystem: Timings Required.

Part 1: Interpreting the Data Sheets

What a mess these data sheets are! The MN83803AK data sheets contain ambiguities that would do Emily Dickinson proud. These ambiguities force us to make educated guesses we would rather not have to make. Fortunately the logic is pretty simple and it takes very little effort to comprehend the freedom this introduces into the design.

If you want to cut to the chase, click here to jump to the timing specification.

If you want to see the data sheets' eccentricities explained, read on.

We are told in the data sheets that "/HCP1 to /HCP4 are the inverted outputs of HCP1 to HCP4." (p. 15 of 22 in jep.pdf) This would be fine, except that we are only shown the timings of HCP1 through HCP4, and not those of their inverses.

No problem? We can't see the onsets of the inverted signals; since they are held "low" while their counterparts run "high," /HCP1 won't appear to start (they won't have a transition to "high") until after HCP4 has started. But /HCP4 should start out "high" just as HCP1 goes "high," though a quarter-cycle of FY behind it-- if, as the timing chart annotation states, /HCP1-4 are just HCP1-4 inverted.

This is the scenario we would get, by the way, with an eight-phase walking-ring counter (modulo 8 walking-ring counter); in fact, Nate Caine points out that it is merely a notational convenience for the data sheets to refer to a four-phase counter and its four inverse signals. When the data sheets notify us that /HCP1-4 are merely HCP1-4 inverted, this is a strong cue to interpret the HCP system design as that of a walking-ring counter.

A walking ring counter (aka "Johnson Counter," aka "switchtail ring") makes for a very convenient and compact design. We can make a modulo-8 walking ring counter with four D flip-flops. (Click to see the diagram of it, below; use "back" button to return here) For a positive edge-triggered design using TTL logic, we can use two 7474 dual D edge-triggered flip-flop chips. We feed back the /Q output from the last of the four flip-flops to the D input of the first flip-flop, so that with each clocking, the first stage turns to whatever the last stage was not on the previous clock.

What we don't see in the MN83803AK diagrams is when the /HCP signals really start. We need to make sure we are putting the right phase of the walking-ring counter first in the series, so that when HDATA triggers the start of this counter, we aren't putting out /HCP where HCP would go, and vice versa: a trivial detail? It is not fully specified in the data sheets. Careful analysis of further information, particularly Nate Caine's diagram of the LCD's clocking logic, is needed to see what effect this will have on the LCD's operation. Let us assume, for now, that as stated, /HCP1-4 are really HCP1-4 inverted, and in particular assume that the onset of counting is the onset of HDATA, so that those /HCP signals that should be "high" at the outset in fact are (/HCP2-4), just as we expect in the setup of a typical walking-ring counter.


Mislabeled timing charts in the MN83803AK data sheets

Now we confront another strange feature of the MN83803AK data sheets: a page labeled "output timings" (page 12) which contradicts the timings shown on page 15.

On page 12, "output timing," we see HCPn, /HCPn, and HCPn+1 staggered, each lagging behind the previous by 1/2 cycle of FY1. Well guess what? If "/HCP1 to /HCP4 are the inverted outputs of HCP1 to HCP4," then there should be no such lag! Not only that: This would have HCPn & /HCPn separated by the same amount of time that HCPn and HCPn+1 are separated by in the diagram on page 15! (It should be offset from it by half that amount)

Here is the diagram that evokes the confusion:

The vertical system (VCP) timing chart on page 12 also has this problem. It specifies a delay from the onset of VCP to that of /VCP, and which also contradicts the statement (on p.18) that "/VCP is the inverted output of VCP." Either it is (and the timing chart on p.12 is wrong), or it isn't, and we need to design logic to impose a delay of length designated "td3" on the chart-- and specified on p.11.

Resolving these apparent timing ambiguities
Page 11 turns out to be our Rosetta Stone for clearing up all this nastiness. The chart on p.11 gives these phase asynchronies in the HCP and VCP system as "rise error/fall error" and "clock phase error." Both values (td2 for the HCP & HDATA system and td3 for the VCP system) are +/- 50 nanoseconds. This is equal in magnitude to the rise and fall time for these pulses (50 nanoseconds). At last we see that these timing diagrams on p.12 show us the largest clock phase error we can expect.

Clear marking of the diagrams would have saved us this inferential process. (Interestingly, the 50 nanosecond error corresponds to a period of an approximately 20MHz signal-- four times the frequency of our on-chip VCO (5.19 MHz) when PMODE=1. The MN83803AK system clock phase-shifts its signal by 90 degrees, allowing it to simulate a clock four times as fast as this, apparently-- a design feature that motivates us to use a new frequency value "FZ" equal to 4f(FY) as our basic system clock. The maximum error in the MN83803AK clocking is in fact just inside the bounds of the system clock's ninety-degree phase shift (which is a shift of about 50 nanoseconds, itself). Does this imprecision arise from an idiosyncracy in the design of a quadrature (ninety degree) phase-shifter in the chip's clock?

We conclude that we really do have a modulo 8 walking-ring counter for the HCP subsystem, and prepare our design accordingly.

Here is our modified version of part of the MN83803AK horizontal timing specification, to illustrate our conclusions:


Part 2: The Timings Laid Out In Chronological Order

We introduce a value FZ, not shown in the data sheets, which we use to represent the period of one oscillation of our master system clock. The MN83803AK data sheets show timings that vary down to a scale of 1/4 of a cycle of their system clock, denoted FY; FZ = 4FY gives us a convenient clock rate from which to derive the timings, for this reason.

All counts start at the onset of the horizontal sync pulse of the incoming NTSC video.

1. Count to (HD) 208 FZ [HDATA onset, rising]
1.1 At this point (208 FZ), pull all HCP lines low

2. Count to end of (HD) 209 FZ [HD offset, falling]

3. Count to HDATA onset [odd: 220 FZ, rising]
[even:217 FZ, rising]

4. Start HCP Modulo-8 Walking Ring Counter (make sure walking ring counter doesn't need to be disabled and then sequentially enabled for start of its 'walk'). This gives us our staggered HCP timings. A walking ring counter is a common logic device covered in many textooks on the subject. We take the example found in the TTL Cookbook as our guide when we design our actual circuit.

HCP first cycle start times (all pulse onsets are transitions to logic '1', that is, 'rising'):

HCP1: [odd: 220 FZ]
[even: 217 FZ]

HCP2: [odd: 222 FZ]
[even: 219 FZ]

HCP3: [odd: 224 FZ]
[even: 221 FZ]

HCP4: [odd: 226 FZ]
[even: 223 FZ]

/HCP1: [odd: 228 FZ]
[even: 225 FZ]

/HCP2: [odd: 230 FZ]
[even: 227 FZ]

/HCP3: [odd:232 FZ]
[even: 229 FZ]

/HCP4: [odd:234 FZ]
[even: 231 FZ]

Each HCP pulse has a width of 2FY = 8 FZ and period of 4FY = 16FZ

5. Count to HDATA offset [odd: 236 FZ]
[even: 233 FZ]

HDATA offset (5) begins tHv (as specified in the data sheet), the beginning of the horizontal 'video display valid pixel (on the panel)' period. As you can see, the LCD displays a smaller picture than the full NTSC display screen, beginning its scan later in the line and ending it earlier. The left and right edges of the video are cut off. The ratio of the LCD's screen size to that of a full NTSC display is given by the ratio of the LCD's tHv to tHy (the NTSC 'video valid period' as described in the data sheets, p. 13 of 22). This is referred to, somewhat confusingly, as the 'horizontal display rate'-- though the problem is just in the parlance, and referring to it as a ratio clears up the confusion.

In the following diagram we relate the MN83803AK horizontal timings just described above to those of the incoming NTSC waveform the LCD displays (you will recognize the sync/blank/video cycle outlined in red and pink). You will probably want to print out a copy of our Adobe Acrobat PDF version of the MN83803AK data sheet from our Data Sheets page, to look at alongside this diagram in order to understand it.

Note: We assume PMODE=1 for all these diagrams. We have not established with certainty that this is the appropriate setting for our LCD.


IIB. Horizontal Sync Subsystem: Designing the Logic Circuitry To Provide These Timings

We offer first a block diagram of the horizontal system that gives one possible implementation of the timings presented verbally in the section above:

HCP System

As we discussed above, the HCP system that controls the horizontal LCD timings implements a modulo-8 walking ring counter. Here we consider a TTL version of this, using the 7474 D edge-triggered flip-flop multivibrator:

C = "clock"
D = D input

Logic table for the 7474 Logic diagram of the 7474.


IIIA. Vertical Sync Subsystem: Timings Required.

H = the period of one horizontal line, from sync onset preceding line to sync onset following.
H = 63.5 microseconds

Video line cycle: 262.5H = 16,668.75 microseconds --> 59.9 cycles per second
Video valid period: 242.5H = 15398.75 microseconds
Difference: 20H (one blanking period, standard NTSC)

Start of timing counts:
odd field: Vertical Sync Pulse onset + 1H period (= VSYNC onset + 2 vertical serrations)
even field: Vertical Sync Pulse onset + 1/2 H period (=VSYNC onset + 1 vertical serrations)

(1)
VCP brought low (to ground potential, logic level zero):
odd field: happens at tf - 1.25H + 1H = 15H - 1.25H + 1H = 14.75H
even field: happens at tf - 1.25H + 1/2H = 15H - 1.25H + 1/2H = 14.25H

See (2) below for explanation of tf (15H no matter what field we are on, but measured from different starting points depending on whether we are in an odd or an even field)

(2)
VDATA rising position (tf) = 15H
odd field: measured from VSYNC onset (which appears to be two equalizing (serration?) pulses (1H) from onset of SYNCOUT's vertical sync (rising))
even field: measured from VSYNC onset minus 1/2 H (which appears to be one equalizing (serration?) pulse (1/2 H) from onset of SYNCOUT's vertical sync (rising))
VDATA pulse width (duration): 2H = 127 microseconds

(3) At VDATA (tf): begin VCP cycle with rising pulse onset
VCP clock cycle (period) = 2H = 127 microseconds
VCP pulse width = 1H = 63.5 microseconds (duty cycle = 50%)

VCP continues cycling all the way to the onset of an internal signal (SV) inside the MN83803AK, when it is brought "low" (to logic zero) (see event (1) in Vertical System timings, immediately above).

(4) At VDATA + 1H, Begin display
odd field: 16H + 1H = 17H
even field 16.5H + 1H = 17.5H
(these odd/even values measured from vertical sync output onset? see chart)


IIIB. Vertical Sync Subsystem: Designing the Logic Circuitry To Provide These Timings

As we did with our horizontal system design, we offer a block diagram that implements the timings described verbally in the section immediately above:

This block diagram shows just one among potentially many implementations that will supply the desired timings.


IV. Remaining Questions

1. What is relation of SYNCOUT VSYNC onset to incoming NTSC VSYNC onset? (from which all timings are counted)

2. What happens to HCP at the end of the video valid period (front porch onset)? (from chart it appears to stop cycling and be held "high" (logic 1) at some point, remaining like this until the onset of the internal signal (HD) (see (1) in the discussion of Horizontal System timings, above))

When exactly is HCP held high, and what relation does this bear to the video signal seen on the screen, and to the video valid period standard for NTSC video? Are all the HCP lines simultaneously brought high, or each in sequence? If so, does this make a functional difference in the LCD system's workings?

3. When does display end? (just count from its onset, no?)

4. How long is the front porch (from end of display field to onset of vertical sync i.e. to beginning of next field)? 2.5 / 3H ?

Click here to go back to my home page