Home / Computers / Z80 Computer / Z80 Computer Circuit Diagrams
Home / Computers / Z80 Computer / Z80 Computer Circuit Diagrams |
|
Page 1 of 5: Clocks and Sync generator
Page 2 of 5: Timing Generator
Page 3 of 5: Video RAM, Character ROM, Timing Generator, multiplexing
Page 4 of 5: CPU, Main memory, output ports
Page 5 of 5: Chip placement
The video timing generator circuit is almost identical to the one I designed for the Great Z80 Project. Therefore I have
shamelessly copied much of the following description from the original.
This part of the circuit, shown on page 1,
(Medium size, 984 x 772, 23K or Large size, 1968 x 1544, 62K)
is responsible for generating appropriate horizontal and vertical synchronisation
pulses for the monitor, and synchronising the rest of the display circuit so that all the right pixels come out in the
right places. Standard UK television resolution is 625 lines, with a refresh rate of 50 frames per second. In reality this
is slightly confusing, since each frame actually only contains 312 lines. Any one frame only draws every other line, then
the next frame comes and draws the other half of the lines, which is called interlacing.
Originally I used a Phillips 9-inch black & white monitor, but managed to procure a very nice
microvitec colour monitor. It is capable of many different resolutions and refresh rates, but for simplicity I (and so I could
use the same timing circuit as my original) I used the same timing as the Phillips monitor. i.e. a horizontal scan frequency of
15,625 Hz and vertical refresh rate of 50 Hz. Each line takes 64 uS (microseconds) to draw, of which a total of 16 uS is spent
on the border to the left and right of the display area, and retracing to the start of the next line. Therefore the
actual drawing area is 48 uS wide. I only draw 256 lines, the remaining 56 are the border at the top and bottom of
the screen, and the vertical retrace. Into this 48 uS line, I squeeze 512 pixels, meaning each pixel lasts for 93.75 nS
(nanoseconds).
At the top left is the 16MHz crystal oscillator circuit, from which all timing signals for the whole computer are derived.
Dividing by four gives 4MHz which is the clock signal for the Z80. Dividing some more using dual 4-bit counter chip IC2 (74LS393)
gives other frequencies for use in the timing of the monitor video signal. IC4 and the gates around it derive the Horizontal
synchronisation pulse, which comes once per line in the 16 uS horizontal blanking period. IC7b and IC3 count 256 lines which represent
the viewable display area. When the 257'th line arrives, it resets the counters (IC3) and IC5 starts counting. IC5 and IC6
count 56 rows, which are the blank lines at the top and bottom of the picture. The gates at the bottom left generate
the vertical synchonisation pulse for the monitor, somewhere in the middle of the vertical blanking period.
There's a funny story about the row counter IC3. At first things didn't work as intended. However, since this was the second time
I built this circuit, I had none of these difficulties. For a laugh, click here to
read all about the debugging of the first project.
After the clock generation and synchronisation pulses generated on page 1 of the circuit,
comes some more timing logic (Half-size diagram, 1063 x 755, 27K or
Full-size diagram, 2128 x 1512, 74K).
Unfortunately the pixel rate requires a division of the primary 16 MHz
clock by 3. Dividing by 3 is very easy but dividing by 3 and obtaining an
equal mark/space ratio turned out to be a lot harder. Of course, my previous
Z80 project also required 16 MHz / 3 for the pixel clock. I don't know
if that worked properly or not. In this case when testing the
video circuit with the monitor, it was readily apparent at first
that alternate pixels on each horizontal line were brighter.
The display was very ugly - when displaying text, instead of each
whole character appearing a uniform brightness, vertical lines
in the bright pixel column stood out clearly, etc. This is a
direct result of alternate pixels being displayed for unequal times
due to an unequal mark/space ratio in the divide-by-3.
To resolve this problem I created the elaborate divide-by-3
circuit shown, partly by trial and error. I used a 74LS163
presetable synchronous binary counter. Synchronous counters
guarantee that all the binary outputs will change state at
exactly the same time. The more usual asynchronous counters
operate by chaining a number of D-type flip flops. The first is
clocked, its output clocks the next and so on. In this way the
count propagates down the chain such that the more-significant
bits of the binary count change state a little later than the
less significant. Because of this you often see the asynchonous
type referred to as "ripple counters". I chose to use a
synchonous counter as I was having enough trouble getting the
timing exact anyway without having to worry about the
inprecisions of a ripple counter.
The strategy is to load the counter with the number 13. 2 pulses
later the count reaches 15. It cannot go any further than this
because it's only a 4-bit counter. So it asserts a logic high on its TC output
(TC = Terminal Count), which I use to drive the PE input (PE =
Preset Enable). The following clock pulse loads the counter
with 13 again. In this way the count will be
13, 14, 15, 13, 14, 15 etc. The time spent in each of the 3 states
is exactly equal since the counter is synchronous. The OR-gate
IC32a has 2 inputs. One is driven by the TC pin, causing a high
pulse on the count of 15. The other is driven by NOR-gate
IC9b. The output of this gate is a logic 1 only during the second
half of state 13 (when the counter's Q1 output is 0 and the
16 MHz clock is 0). In this way the output of the OR-gate is
1 twice during each count of 3, i.e. during state 15 and the
2nd half of state 13. The leading edge of this pulse arrives
exactly regularly. Applying this to the clock of D-type flip flop
IC38b results in an output at pin 9 of IC38b which is has a
frequency of exactly 16 MHz divided by 3 and an equal mark/space
ratio. This is signal C0, i.e. pixel column 0. All of this is
also illustrated in the timing diagram at the bottom right of
the circuit diagram.
A small word about the CLR input of the flip flop IC38b. Why did
I connect it to the Q0 output of the 13, 14, 15 counter? This
forces the phase of the CO signal to be in the first of two stable
states. The situation I want is for the C0 signal to go low on the
second half of the 16 MHz clock in state 13. This connection
forces this to occur. Without it, I found that more-or-less
at random the circuit could fall into the other stable state,
i.e. C0 shifted 3 halves of the 16 MHz clock. Why do I care
which configuration is used? Because I also have to create
signals later to load the shift register and enable the video
output at the start and end of each horizontal line. Without
forcing the phase of C0 I got some peculiar effects - half the
time the first pixel would dissappear off the left of the
display.
A divide by 3 signal is also required to clock the pixel shift
register at the character ROM output, for displaying the
characters in the text mode. I thought I would be able to use
the input to the clock of IC38b, since the leading edges are
regular at the divide by 3 clock frequency. As it happened this
was not the case. Using that signal directly resulted in the
shift register being clocked at half the required rate, such that
only the first half of each character appeared, stretched out
over the entire character width. I don't know why this didn't work
but rather than worry too much about it I inserted the quad XOR-gate
IC40, arranged in the classic edge-detector configuration. This
generates a pulse every time C0 changes state. The frequency of
this signal is 16 MHz divided by 1.5.
Also shown on this page are the column address counters (IC13a and b),
and some confusing circuit around the D-type flip flops IC41a and b.
These generate the video enable output, which is '1' while the
video beam is in the displayed part of the screen, and '0' at the
edges and during horizontal and vertical flyback. This signal is
generated from the LINE and FRAME signals from page 1, but it's not
quite so simple - additional gating is required to delay the
VIDEO EN signal by an appropriate amount such that the right edge
of the display is not cut off. Originally I found that the leftmost
character displayed what I thought should appear at the far right of the
screen. Eventually I realised that the RAM lookup followed by
character ROM lookup and latch actually delays the output of a character
by one full character width, so I have to delay the VIDEO EN
signal by a similar amount. The circuit also has to work
properly when displaying graphics. Once I had it working with text,
it then didn't work with the graphics mode. Only after much trial
and error did I come up with the current circuit, which
perfectly synchronises the VIDEO EN signal, divide-by-3 counter, column
counter and ROM-shift-register-load.
So, the heart of the video generation circuit
(Half-size diagram, 1095 x 821, 53K or
Full-size diagram, 2193 x 1644, 144K).
Here we see the 62256 video RAM (32K), and 28C64 8K EEPROM character ROM. Also
note a multitude of 74LS157 quad 2-1 multiplexer chips, which I use
to direct data and address busses according to the required mode. What
mode? The video circuit has 4 modes of operation:
o Boot: Only the top 1K of the ROM is used for the character patterns. At
switch on, the lower 7K is used to boot the computer
o CPU Read/Write: In this mode the CPU can read and write the RAM which holds
the displayed character codes or graphics bitmap
o Text Mode: RAM holds 16 pages of 64 x 32 characters, character patterns
generated by the ROM
o Graphics Mode: RAM holds 32K bitmap, 512 x 256 x 4 or 256 x 256 x 16
(hor, vert pixels, colours)
To illustrate the data flow in each of the four modes I drew some
block diagrams, then I coloured them blue to show addresses and
red to indicate the data path. The active IC's in each case are
coloured yellow. The 74LS245 octal bus tranceiver operates as
a bidirectional switch. Trapesoidal symbols represent the 2-1 multiplexers
which are made up of several 74LS157 IC's (each 74LS157 contains
4 2-1 switches). By switching the multiplexers and opening the 74LS245's
in the correct combination the circuit has the required configuration
for each mode. More explanation follows!
The computer enters this mode after a system reset (e.g. when
first switched on). So that I didn't have to use a separate ROM
chip for the boot program, and given that I had 7K spare in the
character ROM, I decided to use it as the boot ROM. In boot mode
the CPU address bus is routed to the 28C64 ROM and the ROM's
data bus is routed back to the CPU via the two 74LS256 octal
bus tranceivers (IC19, IC22). During this time the screen is
black.
To write anything at all to the screen the CPU needs to take control of
the display RAM from the video circuit. This is done by setting
bit 7 of output register 0 to 0. Then the CPU can read and write to
the RAM at will, but of course during this time the screen is
black. It is actually better if the CPU only activates mode 2
when the monitor is in flyback so that interference or flickering
doesn't show on the screen. At some point I ought to make
an interupt circuit to signal the processor when the vertical
sweep is finished, so that it can use the dead-time to do its
display RAM access.
Text mode is selected by setting bit 6 of register OUT0 to '0'.
Only 2K of the display RAM is enough to hold a screen full of
characters (64 columns by 32 rows). Therefore I divide the 32K
RAM up into 16 pages, which I select using bits 0-3 of the
OUT0 register (control signals SCR0-3). These page selection
bits drive the upper 4 bits of the RAM address bus. The rest of
the RAM address is built from the column and row address counter
outputs, with the exception of row 0, 1, 2. These three signals
must select the row of the character pattern in the ROM, given
that each character is mapped on a 8 x 8 pixel grid.
When the 7-bit ASCII character code is read from the display RAM, it
is routed to the address inputs of the character ROM. The 3 least
significant bits of the ROM address are formed from row 0, 1 and 2.
Therefore the correct pixel row of the 8 rows which constitute the
pattern for each character are displayed in the correct place.
During text display, the upper 3 bits of the ROM address are
forced to '1', selecting the top 1K of the 8K ROM, which is where
the character patterns are held.
When one 8-pixel row defining the pattern of one eighth of a single
character is ready at the data output of the character ROM, it
is loaded into the 74LS165 parallel-load shift register (IC13). In
the following 8 pixel clocks the state of each pixel is shifted
out of this shift register. IC29 the quad 2-1 multiplexer (74LS157)
selects between 4 text bits or 4 graphics bits. But the shift
register only outputs 1 bit for the character pattern (Bit 0, e.g. corresponding
to black or white). What about the remaining 3 bits? These 4 bits
are fed to the colour pallette chip which gives me some flexibility
of how I may want to use them. I decided to set them as follows.
Bit 1 comes straight from bit 7 of the display RAM. Recall that
the ASCII code specifies only 128 characters, taking only 7 bits. I
therefore have a spare bit which I can use with each character as
an display attribute of that character. Depending on the
pallette settings this could specify that the character is a
different colour for example. However for even more flexibility
I connected Bit 2 to the "FLASH" signal, which is the 50 Hz
vertical synchronisation pulse divided by 16, i.e. something a
little over 3 Hz (flashes per second). Then I connected Bit 3 to
the output of a 4-input NAND gate such that it will be '0'
during the last row of the 8-row character pattern, '1' otherwise.
Depending on the colour settings in the pallette I can then
use bit 7 to cause a character to flash, be underlined, or a
different colour (including being displayed in "inverse" colours,
e.g. black on a white background instead of white on black). Neat.
Graphics mode is selected by setting bit 6 of register OUT0 to '1'.
Here the character ROM is not used, instead the entire 32K
display RAM specifies the picture to be displayed. By design
each byte of display RAM contains 2 pixels, i.e. there are
4 bits per pixel giving 16 colours. In this case the screen
resolution is 256 x 256 pixels. The RAM data is latched in
74LS273 octal latch IC27. The output of this latch is fed to
74LS157 quad 2-1 multiplexer IC28, which selects between the upper
4 bits and the lower 4 bits (first or second pixel of the byte).
Via the text/graphics selecting multiplexer IC29 these
4 bits arrive at the colour pallette chip.
The pallette chip can take 8 input bits (256 colours).
To be a bit clever I decided to create a high resolution mode
by simply connecting bit 5 of the pallette input to
the column 0 (C0) counter output. This will be '0' in the
first half of one of my ordinary 256 x 256 pixels and '1' in
the second half. Merely by carefully programming the colours in the
colour pallete I can then choose either a 256 x 256 x 16-colour
graphics mode or a 512 x 256 x 4-colour mode! The remaining
3 bits of the colour pallette input I just drive from bits 0-3
of the OUT3 register. Therefore I can program 8 seperate pallettes
and switch between them easily.
Note that I don't make any special arrangements for to ensure
that the pixel mapping in the display RAM is convenient i.e.
adjacent pixels occupy consecutive memory addresses. Due to the
R0, R1 and R2 signals going direct to the character ROM during
text mode, the addressing requirements would be somewhat different
for graphics mode. To line up the pixels consecutively I'd have
had to use yet another set of 74LS157 2-1 multiplexers to
route the row and column count correctly. I decided against this,
given that it will be simple to write an alogorithm in software
to convert a normal X, Y pixel address to the corresponding
display RAM address.
Here I finally show the actual Z80 CPU
(Half-size diagram, 1100 x 816, 43K or
Full-size diagram, 2201 x 1633, 128K).
It always surprises me that the circuit surrounding the CPU is
actually the easiest and simplest part of the whole circuit.
The real complication is in the video driver circuit.
IC42 the Z80B itself needs no explanation. The 431000 static
RAM used as the main memory is in fact a 128K device. This creates
a problem because the Z80 address bus is only 16 bits wide,
implying a maximum address space of only 64K. I therefore divide
the 128K memory into 4 pages, which I select using the two bits
4 and 5 of the OUT0 register (labelled STTS A15 and STTS A16).
The pallette register is programmed on output port OUT1. This
page of the circuit diagram shows the OUT0-7 output decoder
IC34, a 3-8 decoder. This decodes bits 4, 5 and 6 of the
CPU's output port address space. The keyboard interface uses
the same circuit I used in my old Z80 project. 4 address lines
A0 to A3 are sent to the keyboard and decoded into 16 lines
by a 74LS154 (4-16 decoder) inside the keyboard case. 8 data
lines return from the keyboard matrix and are read back from
the keyboard using the OUT2 signal. 4 8-bit 74LS256 bus tranceivers
buffer signals from the computer to the outside world, via the
expansion connector (IC's 35, 36, 37 and 50). The reset circuit
also comes directly from the original Z80 project. It generates
a reset pulse on switch on and when the CPU BUSRQ signal goes
high. I use this to program the main memory via the switchboard,
until such time as the computer can be programmed in a more
convenient way by the keyboard!
The following is the IO map of this Z80 Computer. Addresses not
in this list aren't currently used...
0-15: Status register (video), write only. Any IO in the range 0-15 writes the register.
Bit 0: SCR0 )
Bit 1: SCR1 >-- Selection of display RAM page in text mode
Bit 2: SCR2 )
Bit 3: SCR3 )
Bit 4: A16 (main memory page 1)
Bit 5: A15 (main memory page 0)
Bit 6: '0' = TEXT mode, '1' = Graphics mode
Bit 7: '0' = CPU read/write mode, '1' = video circuit TEXT and GRAPHICS modes
16-19: Pallette registers 0-3, read/write
32-47: Keyboard scan lines 0-15, read only
48-63: Control register, write only
Bit 0: PALLETTE 5 )
Bit 1: PALLETTE 6 >-- Bits 5-7 of the pallette input. Specify 1 of 8 32-colour pallette pages
Bit 2: PALLETTE 7 )
Bit 3: CAPS LOCK: Signal to drive the keyboard Caps Lock key's built in LED
Bit 4: SOUND: Signal fed to expansion connector, could drive a piezo sounder
Bit 5: OUT 0 )
Bit 6: OUT 1 >-- Output signals fed to the expansion connector
Bit 7: OUT 2 )
The last page shows the chip placement on the board, and the pinout
of the expansion connector
(Half-size diagram, 996 x 736, 24K or
Full-size diagram, 1992 x 1472, 64K).
