HIGH SPEED INTERFACE 2
Revised August 13, 2005 - wilf rigter
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
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.
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
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.
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
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
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
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.
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
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.
More to come.
Aug 13,2005 – spelling corrections and notes on simulating a SLAVE ZX80.