HIGH SPEED INTERFACE 2
Revised August 13, 2005 - wilf rigter
INTRODUCTION
The HS-2 system described here is a high speed
interface between
two TS1000 units, one of which is dedicated to
executing a user
program in the FAST mode while the other generates a
continuous
video display of the user program DFILE.
The HS-2 system is based on the concept of HS-1.
Little is known about the HS-1 system except for some
advertisements of
which this one was taken from a March 84 SYNC
magazine. I am curious to
find out if anyone had any hands on experience with
the HS-1 system.
It is clear that two stock TS1000s were used,
connected together through
an interface card and 9” cable. According to the
description, one TS1000
runs in the FAST mode to execute the user program at
near maximum speed
while the other unexpanded TS1000 runs in the SLOW
mode to display the
DFILE of the user program that is running on the FAST
TS1000. It uses
FLIGHT SIMULATOR as an example program, which suggests
that it is
compatible with stock TS1000 programs. There are no
other details that I
am aware of but this information is enough to design a
similar though
perhaps somewhat slower system.
TS1000 FAST
and SLOW mode
A TS1000 in the FAST mode can run user programs full
speed while the
video circuit is turned off so no video is displayed
until the user
program pauses.
A TS1000 in the SLOW mode can generate a continuous
video display but user
programs run at 1/6 (60Hz) of the FAST mode speed
because the Z80 CPU spends
most of its time on generating the video display.
HIGH SPEED
INTERFACE II
After evaluating several different design approaches
for transferring
data between two TS1000 units, I settled on a
Master-Slave architecture.
The Slave memory is transferred to Master memory
through an I/O interface
This is not quite as fast as a true memory to memory
interface but much
simpler to design.
The Master TS1000 provides a SLOW mode video display
of the application
program running in the FASYT mode on the Slave TS1000.
The HS-2 interface provides the Master TS1000 with
Direct Memory Access
to the Slave DFILE using three I/O ports and a control
program.
The Master takes control of the Slave by using BUSRQ,
which gives
access to the entire 64K of Slave memory space.
The Slave memory contents are addressed with a 16 bit
address set up in
two 8 bit output ports and data is transferred
directly from the Slave
memory, through an input ports to the Master memory
(eg DFILE to DFILE).
Slave memory data is transferred to Master memory
using arbitrary
source and destination addresses.
For example, after asserting BUSRQ and the BUSAK
handshake, the Slave
memory System Variables DFILE and VARS are read. Next
the Slave DFILE
addresses and length are calculated. The most
significant eight
address bits of the Slave DFILE are loaded into the
MSB address latch.
The least significant address bits are set up in B
register.
The starting address of the Master DFILE is loaded
into HL and the
Slave DFILE of up to 793 bytes is transferred in 4
blocks using the
INDR instruction which automatically decrements the B
register and the
HL register pair. Note that using INDR, the B register
is decremented
so DFILE must be transferred in reverse order! More on
this later.
HS-2
HARDWARE
The HS-2 design approach is based on simplicity and
transparency by using
five simple TTL chips.
A 74HC32 and 74HC02 are used for I/0 port address
decoding and for a
Master Machine State decoder.
The Machine State Decoder is basically the same
circuit used in my
Turbo clock-doubler and is required to decode whether
the MASTER CPU is
running the video routines or the control
program.
A 74LS574 octal FF is used to store the MSB Slave
memory address.
A 74HC541 (or an inverting 74HC540) is used as the LSB
address buffer.
The data I/O port uses a 74HC245 bi-directional buffer
hardwired for input.
The control hardware and software runs on the Master
TS1000. The Master
Runs in the SLOW mode and spends most CPU time
executing video routines.
When the CPU is free to run the control program, the
machine state decoder
asserts the BUSRQ signal on the Slave TS1000 bus. The
Slave CPU responds
with BUSACK, which enables the IC3-IC4, registers to
place a specific Slave
memory address on the Slave bus. The Master then reads
the data byte at
that Slave memory address through U5, the input port
and transfers the
byte to the Master memory. Each Slave DFILE byte is
consecutively address
and transferred from the Slave DFILE to the Master
DFILE.
The time to transfer a byte using INDR is about 6.5
us, so a complete
DFILE can take up to 793 x 6.5us = 6ms of CPU time.
Since the transfer
will be interrupted during the SLOW video display
time, the total time to
transfer DFILE is 1.5 to 3 frames depending on the
vertical frame rate.
This time is not wasted as the Master Machine State
decoder automatically
drops the BUSRQ line during the video display, which
allows the SLAVE user
program to resume execution.
In fact, the Slave user program only runs when the
Master TS1000 is
generating the video display which means that the
Slave user program uses
more than 80% of available Slave CPU time at 60 Hz
vertical frame rate.
This means that the FAST TS1000 user program runs 5
times faster than the
normal 60HZ SLOW mode.
The INDR instruction decrements B register which would
require that both
The source and destination addresses decrement and
DFILE be transferred in
Reverse order. This can be problematic if DFILE is not
properly formatted
(eg after SCROLL) Two solutions are available to deal
with this problem.
1) Use a 74HC540 inverting buffer for IC3 which
effectively increments LSB
address as B register decrements. That allows the INIR
instruction to be
used to transfer DFILE from start in the normal order.
2) Use a
74HC541 for IC3. Since the Master TS1000 has 2K of RAM, there is
enough
memory for two complete DFILEs. That way one Master DFILE is
updated
in reverse order while the other is displayed and the Master
DFILE
variable can be toggled between the two alternate DFILEs for a
properly
formatted and ghost free display.
I am sure there will be some discussion, suggestions and comments before
actually
building the prototype but this HS-2 circuit looks like a winner.
CIRCUIT DETAILS
The HS-2
circuit is sandwiched between the Master and Slave TS1000. The
HS-2
circuit is assembled on a PCB, which unlike the HS-1, is mounted on
and
powered from the MASTER TS1000. This is done so that the input side
of the
circuit is properly terminated. In fact, the Master TS1000 can be
powered
up with the HS-2 installed but with no SLAVE TS1000 connected.
The
control program checks to see if the first DFILE byte is valid N/L
character
(76h) before transferring DFILE. Similarly, the SLAVE CDFLAG
system
variable is checked for FAST mode so that the MASTER control
program
aborts if it cannot find a FAST SLAVE or proper DFILE.
The
SLAVE TS1000 is connected to the interface with a 32 conductor flat
cable.
The 0V or Gnd bus is common to both TS1000 and the interface
circuit.
The HS-2 interface is powered by the Master regulated +5V bus.
Not
shown is the common switched 9V supply that supplies power to both
TS1000
units.
IC1 is a
quad OR gate used to decode I/O RD and I/O WR signals.
IC1c/d
decode /IORQ and /RD with /A7 to enable IC5 the data input Port at
Address
7Fh.
In
addition, this input post enable signal also pulls the SLAVE tri-stated
MREQ and
RD signals active low so that the SLAVE memory address and control
signals
are decoded by the SLAVE memory addressing circuit including the ULA
(RAMCS/ROMCS)
or any expansion RAMPACK. The 10K pull
up resistors on MREQ,
IORQ, RD
and WR avoid spurious decoding of those signals when tri-stated.
IC1a/b
decode /IORQ and /WR with /A7 to enable IC4 and load the MSB of the
SLAVE
memory address into the octal latch.
IC1a
together with IC2a/b and A0 or A1 form a RS flip-flop which decodes
whether
VIDEO is displayed or the USER program is executing.
This
Machine State Latch is RESET with OUT FE when the NMI generator is
turned
off (VIDEO) and SET with OUT FD when NMI is turned ON (USER).
The MS
Latch is also RESET when HALT is low during the VIDEO display
and
switch S1 manually RESET the MS Latch when closed.
During
each vertical frame, when the MASTER TS1000 executes the USER program
during
so called BLANK lines, the MS Latch is automatically SET and the
SLAVE
BUSRQ line is pulled low. The SLAVE CPU responds with BUSACK which
enables
the SLAVE address output ports IC3 and IC4. The SLAVE memory data is
then
ready to be read through IC5 by the MASTER TS1000 control program.
The
normal sequence of activating the HS-2 interface is as follows:
1) With
power disconnected plug the HS-2 unit into the MASTER TS1000
2)
Connect the flat cable between the HS-2 unit and the SLAVE TS1000
3) Close
S1.
4) Turn
on 9V power.
5) Load
the control program on MASTER TS1000 (HS-2 EPROM to be added)
6) Load
application program on SLAVE.
7) Run
SLAVE program in FAST mode.
8) Open
S1 to start the HS-2 Interface and display the MASTER TS1000 video.
9) Run
MASTER control program to display the SLAVE TS1000 video.
Note
that the SLAVE TS1000 must always be in FAST mode when the HS-2
Interface
is active or the active BUSRQ can freeze the SLAVE TS1000.
One way
to guarantee that the SLAVE is always in the FAST mode is to disable
NMI by
bending pin 15 of the SLAVE ULA out of the IC socket and using a 1K
pull up
resistor to the Z80 NMI line which can be added on the HS-2
interface
board.
The ZX81
ROM is backward compatible with the ZX80 and on power up or RESET
tests
for the presence of pulses on the NMI line to either run in the SLOW
ZX81
video mode or in the FAST ZX80 video mode.
CONTROL PROGRAM
I only
have a bare outline for the control program as described above but
it
should be straight forward. More error
checking can be added but the
key is
to make the transfer program as fast as possible.
The data
port can be made bi-directional for read/write access to SLAVE
memory.
Other
software can use this hardware for new applications like adding input
devices
such as a keyboard or mouse or other output devices such as a LCD.
COMMENTS
More to
come.
REVISION NOTES
Aug
13,2005 – spelling corrections and notes on simulating a SLAVE ZX80.