MK14E VDU Operation

This page describes the workings of the MK14E VDU, it also mostly applies to the original MK14 VDU though component references may be slightly different.

Screen Format

The MK14E (and MK14) VDU is capable of displaying either text or graphics and can be configured to have either text or graphics over the whole screen or both with a split screen.

A full screen of graphics is displayed as 64-lines of 64-pixels, each row being read from 8-bytes of screen RAM consecutively, MSB first.

Text is displayed as 32 lines of 16 characters, each character occupying an 8x8 pixel grid defined by the EPROM character generator.  The EPROM character generator is capable of holding a 128 character set, the original MK14 VDU character set was for 64 characters:

I have also included a full 128 ASCII character set, the 64 ZX80 and ZX81 fonts and a special modified version of the standard font with games characters - selectable by links (LK7/8).

Because only 7-bits of each character are used it is possible to select an inverted version of the character by setting the MSB (bit 7).  In some other implementations of compatible MK14 VDUs bit-6 was used, LK4 allows either option to be selected.

To generate a line of characters on the screen 16-bytes of RAM are read out eight times in succession and used to select the character EPROM font (see comment later re the byte order), each byte from the EPROM is then output to the screen MSB first.

For both modes a whole screen requires 512 bytes of screen RAM.

Characters sit in an 8x8 pixel grid, its worth noting here how that lines up with graphics.  A 'standard' 5x7 character sits in the 8x8 grid with a one pixel space to the left and two pixel spaces to the right, it then sits on the bottom of the grid i.e. with a one pixel gap above.  I have aligned the original DM8678CAB font in the EPROM to replicate this alignment.

Timing

The VDU requires a 4MHz clock, this can be selected (by LK9) from either a local 4MHz oscillator (X1) or the CPU clock (backplane pin A27) provided its links are set to the 4MHz crystal (X1).

Although the original VDU was synchronised to the CPU clock it doesn't need to be, the interaction between the VDU and CPU are essentially asynchronised so the clocks do not need to be the same.

This clock is divided down by IC4.2 and IC3.1 to generate clocks between 125kHz and 1MHz.  IC6, a 12-stage ripple counter, generates the main video timing signals, this is clocked at 125kHz and resets every 20mS (frame rate) via IC13.1.

Shared RAM

Screen RAM is shared between the CPU and VDU, the CPU needs to be able to read and write whilst the VDU only reads.  The 8060 CPU has a DMA like feature which enables other devices to 'take over' the bus.  This is normally achieved by taking the NENIN line high to request access to the bus and then waiting for the CPU to respond by taking NENOUT low when it relinquishes the bus.  In the case of the VDU it is not possible for the VDU to wait as it must start a line at a fixed time. 

At the start of a video line IC14.1/R15/C11 generates a pulse which via transistor Q4 drives NENIN high requesting that the CPU suspends bus activity.  The NENIN signal is effectively ORed by IC5 with line sync to keep it active for the duration of a line.  (Note that R15/C11 remove a glitch that occurs between the pulse and line sync signal, I have found this to be too short and have increased the value of C11 accordingly).  The whole process is enabled/disabled by the Video On/Off line via IC14.1 and IC11.2.

After activation of NENIN there is a delay of 15uS before the VDU takes over control of the bus (enabling IC9 and 10), this gives plenty of time for the CPU to finish whatever it was doing.

RAM Addressing

A full 16-bit address is generated to select screen RAM, the most significant eight address lines are selectable via DIL switch S1 (in the case of the original VDU only 4-bits are selectable via b9-12).  The remaining eight address lines are derived from the counter chain.

IC8 selects between two sets of addresses depending on whether Graphics or Characters are selected.

Graphics Generation

Graphics are presented as lines of 64 pixels, eight sequential bytes forming the pattern.  Graphics generation is therefore straight forward, the data bytes from screen RAM are fed to shift register IC16, which is then clocked at 2MHz to provide the pixel stream.  The shift register is reloaded every 8-bytes.

Character Generation

Character generation is a little more complicated.  Each row comprises 16 characters i.e. requiring 16 bytes - this is the reason for having to select different sets of address lines from the counter chain as bytes need to be read out of screen RAM at twice the speed for characters.

Each group of 16 bytes from the screen RAM then need to be cycled through eight times to build up the eight lines of pixels required for a line of characters.  Counter IC3.2 counts the pixel lines, this is clocked at the character line rate (15.625kHz) and reset every eight bytes by IC13.2.  The 3-bits from this counter and 8-bits from the video RAM provide an address for the character font EPROM IC15a.  The data output from the EPROM is then treated similarly to graphics being serialised by IC15b.  This is clocked at twice the rate (4MHz) because there are twice as many character pixels per line than graphics pixels.

There is however a flaw in the design, the reset signal for IC3.2 should really occur at the start of each character so that the bytes are read out from the EPROM in the order 1,2,3,4,5,6,7,8 as it builds up the character over eight lines, however the reset pulse occurs late and so the byte order is actually 8,1,2,3,4,5,6,7 !  This is not a problem when used with the original DM8678 character generator as line eight doesn't exist.  It has proved difficult to correct this for the EPROM version as it is not possible to generate an earlier pulse with out radical changes to the circuit, it would then be very different to the original.  As it happens it doesn't really matter as the counter is synchronised to theeight byte cycle and in reality the only time the wrong byte is read out will be on the first character of the first ever frame so you would never notice.  It just seems a bit weird that the bytes in the EPROM have to be ordered 8,1,2,3,4,5,6,7 especially if using the full 8x8 available font.

It is possible to have inverted characters controlled by the state of either bit 6 or 7 of the character.  Latch IC17.1 captures this bit and uses it to invert the character data stream via IC1.4.

Video

Finally the two video streams are combined dependent on the state of the Graphics/Character line by IC14.  The whole video frame can then be inverted by IC1.3 under the control of the Invert signal.  The resulting video stream is then tidied up by gating with a blanking signal generated by IC17.2 at IC11.3 to remove any unwanted inverted video before or after the line.

Finally it is combined with a composite sync signal from IC5.3 at transistor Q1 and buffered by Q2 to provide the resulting video signal.

Back to MK14E

Acorn Home Page