.op
.heDRAFT ONLY...(C)1980 Trevor Marshall, Uni of West Australia, Page #

INTERFACING THE Z8000 TO THE S100 BUS


NOTE:  This  article  is  copyright when transmitted  as  printed 
matter, as it has been submitted to a journal for publication (as 
at  18  Jan 1980).  I feel that they have  had  exclusivity  long 
enough,  as  there is material here that should be of some use to 
somebody???
It may be transmitted and copied in machine readable form (floppy 
disk ONLY)
It has been contributed as background to the CP/M 'HOST'  program 
submitted previously.
Please  pardon  the  verbosity,  as  it was  written  to  keep  a 
professional journal editor happy.

For Further information ( and copies of the schematics) contact:

     Trevor Marshall,
     359 Wynn Ct.,
     Thousand Oaks, CA 91360



    INTRODUCTION

There  are  two development modules currently being marketed  for 
the  Z8000 series microprocessors (1,2).  Both currently use  the 
Z8002  and  interface  to  floppy- disk- based  computer  systems 
proprietry to each manufacturer.  The ZILOG  equipment,  although 
based   on   a  technically  excellent  Disk   Operating   System 
(DOS),'R.I.O.',   possesses  a  unique  command  structure  quite 
different  from microprocessor based DOS in common  use.  Neither 
module is directly compatible with a commonly used bus structure, 
although  the  96/4016  from Advanced Micro  Computers  (AMC)  is 
dimensionally compatible with the industry standard 'MULTIBUS'.

This  research  group's Z8000 development system was designed  to 
alleviate these difficulties.

The I.E.E.E.  draft S100 bus structure (3) offers a wide range of 
low cost peripheral and memory boards whilst not compromising the 
operating  speed of the Z8000.Some of the  processor's  features, 
such  as the 'Multi- micro' instruction set enhancements and  the 
Non- Vectored- Interrupt  capability,  require 'customisation' of 
the  bus protocol for their implementation.  This problem is  not 
unique to the S100 bus.

DOS  interface  has  initially been to a CP/M  (CDOS)  Z80  based 
development  system.  It  is  interesting to note  that  the  AMC 
software appears to be totally CP/M compatible.

1. AVAILABLE SOFTWARE
 
1.1 The Monitor Programs.

The  monitor  programs available for the Z8002 (4,5)  offer  some 
common  features,   such  as  memory   examine/modify,   software 
breakpoint(s),    DOS  upload/  download  commands  and  hardware 
controlled 'TRACE' capability. Both also provide unique features, 
such  as  the  I/O port examine  /modify,  memory  compare,  tape 
punching /reading and a 'transparent mode' offerred by ZILOG,  or 
the  address  actuated hardware breakpoint  and  'monitor  system 
calls'  of  AMC.  There are also differences in the register  and 
flag display/modify capabilities.

No  attempt had been made to unify the monitor  commands,  or  to 
implement   commands  similar  to  those  on  any  common  8  bit 
development  system.  The  keywords of the ZILOG monitor  can  be 
altered  to  ease  this transition,  as command  syntax  is  more 
familial  than that used by the AMC monitor.
It  is important to note that AMC has not implemented an  <X-OFF> 
(Control  S)  protocol,   nor  a  keyboard  'break'  function  to 
terminate incorrect display commands. If their dedicated keyboard 
is  not  used,  however,  enough  PROM can be freed  to  allow  a 
routine, such as that in the next section, to be added.

The  standard of documentation,  particular the  Monitor  Program 
Listing, is vastly different, and should be carefully assessed.

1.2 Public Domain Software

A program to enable the AMC monitor to communicate with a CP/M or 
CDOS  DOS has been written by the authors*.  This program  allows 
LOADing  and  SAVEing from the Z8002 development module  to  disk 
files.  Assembly  of  disk files using the resident assembler  of 
section 2 has also been implemented. Example of an assembly using 
this technique is given in figure 2. This program, written in Z80 
code,  handles OPENing,  CLOSEing,  READing and WRITEing of  disk 
files for the  Z8002 monitor. 

* Copies of the program have been submitted to SIG/M

 Communication  with  the development module is by  RS232  serial 
I/O, using the same request- acknowledge instruction sequences as 
the monitor.

2. RESIDENT ASSEMBLER

AMC  offer a resident assembler (6) in four 2716 PROMs which uses 
their 'monitor system call' facility to assemble programs line by 
line.

 A  parameter  block is set up by the assembler and  a  Z8000  SC 
(System  Call) instruction executed.  The Z8002 transfers control 
,via a trap, to the monitor program which services the console or 
disk I/O request; then returns control to  the assembler. It does 
not  appear  possible  to use the AMC assembler  with  the  ZILOG 
monitor, primarily because of vastly different use of the monitor 
RAM space.

The  assembler  is a single- pass type allowing both forward  and 
backward  references  to  symbolic labels.  The  code  is  placed 
directly into memory and the line by line listing (figure 2) will 
not contain the correct addresses for forward  references.  After 
they have been defined, and the END directive issued, the correct 
values will be placed into the RAM, however.

The  main  limitation to the use of the assembler is that it  can 
only  assemble  code to RAM between H'4280' and  H'6000'  without 
issuing error messages, and the symbol table builds downward from 
H'6000' further reducing available program size.

As  most  systems to be developed will need to  reside  at  other 
addresses  and  the  Z8002  code cannot easily  be  made  totally 
relocatable  due to the limited addressing range of the  relative 
displacement  opcodes,  the assembler must be modified  to  allow 
'ORG'ing  at  other addresses.  It must be remembered  that  this 
assembler  was  not  intended to  replace  the  Macro- Assemblers 
marketed for the Development Systems.

The  lower  limit is determined by the following code (using  the 
notation of (11) )

12A6: 0B05 4280      CMP   R5,#4280
12AA: E504           BN    #12B4    ;Jump to an error exit

and the trap may be bypassed by placing a NOP at 12AA.  This will 
not overcome the RAM assembly problem however,  as code is placed 
in memory and then read from it prior to printout.  Thus if  data 
is not written to RAM the printed opcodes will be meaningless.

The RAM is addressed by the following code

1900: 2F10      LD   @R1,R0 ;Writes the assembled code to memory
1902: A911      INC  R1,#2  ;Points to next memory address
1388: 2040      LDB  RH0,@R4 ;Reads first assembled byte
138A: D0EC      CALL #11B4   ; prior to printing it
1388: 2040      LDB  RH0,@R4 ;Reads second assembled byte
138A: ....                   ; prior to printing it
1388: ....    and so on for each assembled opcode byte.

If this code is replaced with a call to the unused ROM at the top  of 
the assembler then a displacement subroutine may be placed there.

1900: 5F002FE0  CALL #2FE0
1388: 5F002FEC  CALL #2FEC
2FE0: 01015000  ADD  R1,#5000 ;Add a displacement of 5000
2FE4: 2F10      LD   @R1,R0
2FE6: 03014FFE  SUB  R1,#4FFE ;5000-2
2FEA: 9E08      RET           ;So no need to INC R1,#2 on return
2FEC: 01045000  ADD  R4,#5000
2FF0: 2040      LDB  RH0,@R4
2FF2: 03045000  SUB  R4,#5000
2FF6: 5F0011B4  CALL #11B4
2FFA: 9E08      RET

3. HARDWARE DESIGN

Most  of the basic information necessary to design a small  Z8002 
system  can be found in the literature (1,2,4,6,7,8).  Note  that 
(1)  and (9) are updated versions of (7),  and the interface  for 
Z80 peripheral devices given in (7) is not entirely satisfactory.

3.1 Operating With Standard 450 nsec RAM and EPROM

Although 'wait state' circuitry has been recommended in (1) it is 
not  strictly necessary.  Plate 1 shows the S100 bus signals PWR* 
(write pulse) and A0 with a 4.0 MHz Z8002 clock frequency. It can 
be seen that at least 600 nsecs elapse between address setup  and 
data  sampling,  and  the address remains stable for another  100 
nsec.  When an I/O operation is performed the Z8002 automatically 
adds  one wait state (250 nsec)(see Plate  #4).  Similar  timings 
have  been  measured  for  READ  operations.   The  authors  have 
consequently disconnected their wait state circuitry.

It  is important to note that 74LS373 Transparent Latches must be 
used  for  the address lines if this timing is to  be  preserved. 
Edge clocked latches will reduce the available setup time by  125 
nsec.

The  timing skew between the Z8002 pins and the S100 bus is  less 
than  25  nsec,  and  does  not significantly  affect  the  above 
conclusions.

3.2 Deriving the Bus Status and Control signals.

The  Z8000  provides  16 status outputs which are  setup  at  the 
beginning of each processor cycle and indicate the type of  cycle 
to be executed. Table 1 gives a summary of these signals, and the 
notation used for them in this paper.


ST3-ST0   Operation        Notation  ST3-ST0   Operation    Notation

 0000    Internal  Operation (INTOP)  1000    Data mem  request (DRQ)
 0001    Memory refresh     (RFSH)    1001    Stack mem request(STCK)
 0010    I/O reference      (I/O OP)  1010    Reserved
 0011    Special I/O reference        1011    Reserved
 0100    Segment Trap Acknowledge     1100    Program ref,word n (Mn)
 0101    Non Maskable Interrupt       1101    Instruction fetch,first
             Acknowledge   (NMI ACK)               word          (M1)
 0110    Non Vectored Interrupt       1110    Reserved
             Acknowledge   (NVI ACK)
 0111    Vectored Interrupt           1111    Reserved
             Acknowledge    (VI ACK)

TABLE 1. The Z8002 Status Line Codes.

3.2.1 pSYNCH and pSTVAL

These  two  bus  control signals define the beginning  of  a  bus 
cycle,  and are not directly provided by the Z8002. pSYNCH can be 
triggerred true on the negative going edge of the address  strobe 
(AS*),  and reset when the data strobe (DS*) is activated.  Valid 
addresses are guaranteed after another 20 nsec and status signals 
after another 30 nsec (ref 7,p22).  If the coincidence of AS* low 
and  CLOCK low is used to trigger pSTVAL the status signals  will 
have  been  valid  for  a  minimum  of  15  nsec.  Circuitry  for 
accomplishing this is shown in figure 1. pSTVAL may also be reset 
by DS*.

There are two CPU operations which do not generate a DS*,  memory 
refresh and CPU internal operation, so the status lines INTOP and 
RFSH  must  also  be  used to reset  the  two  S100  strobes.This 
presents  timing difficulties,  as the status signals appear soon 
after the address strobe,  causing pSYNCH and pSTVAL to be  valid 
for only about 30 nsec. A minimum width of 175 nsec is needed for 
pSYNCH  and 50 nsec for pSTVAL,  so the status reset signals must 
be delayed.  This can be achieved with an edge clocked flip-flop, 
synchronizing  the status reset signals with the  positive  going 
edge of the CLOCK.
pSYNCH  and pSTVAL are shown on axes 1 and 2 respectively of  all 
the S100 bus timing photographs conforming to the convention used 
in (3).

3.2.2 The 8/16 bit bus selection

The  Z8002  Byte/Word  (B/W*)  output line may  be  buffered  and 
directly used to generate sXTRQ*.  If the recently released  8/16 
bit  S100  memory boards are used there is really no need to  use 
the  handshake  sIXTN*  signal  from  the  slaves,   considerably 
simplifying  the circuitry.  When 8 bit I/O peripherals are  used 
they  may be addressed on odd  boundaries  (addr=2n+1),  allowing 
byte transfers between the peripheral and CPU on the lower 8 data 
lines. Although this wastes the even I/O address boundaries there 
is 64K of I/O addressing capability in the instruction set, which 
should be adequate for most systems, even with the wastage.

3.2.3 DMA arbitration and Interrupts

The  priority  resolving example given in (3) may be  implemented 
without modification, if desired. The HOLD* signal may be applied 
directly  to the BUSRQ* input of the Z8000 (remember  to  protect 
the  processor from bus transients).  The processor BUSAK* output 
may be buffered and used for pHLDA.

The  Z8002  provides for 3 types  of  interrupts,  Vectored,  Non 
vectored and Non Maskable.  The corresponding status lines (table 
1)  are  activated during the acknowledge  sequence.  sINTA  must 
therefore  be  derived  from a combination of  the  status  lines 
corresponding  to  the modes in use,  usually  Vectored  and  Non 
Maskable.  Plate  ##  shows  a vectored interrupt  request  cycle 
initiated  by Z80 peripheral circuits interfaced as suggested  in 
(1).  Note  that  the  activation of the  Z80_IORQ*  and  Z80_M1* 
appears  to  the peripherals to be similar to  the  signals  they 
would normally receive from a Z80 CPU.  The Return From Interrupt 
(RETI)  subroutine also simulates the Z80 CPU status signals  for 
these  peripherals  (CTC,  SIO,  and PIOs).  Remember that  these 
peripherals must be placed directly on the processor data  lines, 
or  alternatively  their  data buffers must  be  gated  correctly 
during  BOTH sINTA and RETI modes.  The upper CPU data lines must 
assume a defined state (usually H'FF') during sINTA.

 Use  of  the  S100  Interrupt Vector lines  may  not  always  be 
sensible,  as the addressing capability of the interrupt is  then 
restricted  to  8  bits.  If  it  is desired  to  use  them  (for 
compatibility  with  some 8 bit peripheral boards)  they  may  be 
gated onto the address bus whilst sINTA and pDBIN are both valid. 
Remember  to  also gate the higher order bus lines to  a  defined 
state (either 0 or 1).

3.2.4 The S100 Status and Control Lines

It was initially decided to use combinational logic to decode the 
MREQ*,  DS* and R/W* CPU signals to sMEMR,  sMWRT, pDBIN and pWR. 
This was not satisfactory,  as the MREQ* signal is only valid for 
part of the CPU cycle,  unlike the status signals ST0 - ST3.  A 1 
of  16  decoder had been provided on ST0-3 to ease debugging  and 
provide the signals for the circuitry of figure 1,  but the delay 
through  this  and the combinational logic was  prohibitive  (the 
Z8000 only allows 80 nsec for data transfer delays).  It was thus 
necessary to use bipolar ROMs to effect the decoding. The fastest 
commonly available device, type 93427, were used. These can drive 
the  bus  directly,  but  their outputs are  not  tested  to  the 
I.E.E.E.  standard's requirements.  Their organization is 256 x 4 
with  a  typical access time of 35 nsec.  The skew between the  3 
least  significant lines and the outputs is even less,  as  these 
drive  an internal multiplexer array,  so the DS* to status  skew 
was 20 to 30 nsec in the authors' system. Table 2 shows the truth 
table  implemented.  No  logic glitches occur due  to  addressing 
skew,  but  note the assignment of the address lines between  the 
internal PROM array and multiplexer.

Paragraph 2.2.3.1 of (3) describes sMWRT as a STATUS signal,  yet 
defines it to be valid only during pWR*. Other STATUS signals are 
valid  for the majority of the bus cycle.  Either timing  can  be 
implemented  by the appropriate choice of DS* condition in table 2.

PROM ADDRESS    A0   A1   A2   A3  A4  A5  A6  A7
Z8000 SIGNALS  R/W* DS*  n.c. ST0 ST1 ST2 ST3  n.c.
S100 OUTPUTS
sOUT            0    X    0    0   1   0   0    0
sINP            1    X    0    0   1   0   0    0

                               1   0   0   0     
                               0   0   0   1
MWRT            0    0    0    1   0   0   1    0
                               0   0   1   1
                               1   0   1   1

                               1   0   0   0
                               0   0   0   1
sMEMR           1    X    0    1   0   0   1    0
                               0   0   1   1
                               1   0   1   1
(n.c. denotes that this input is not used and is grounded.)

     Table 2. Truth table of the 93427 Decoding Proms.

The  sM1  signal  can be derived with  combinational  logic  from 
status M1, and the pWR* from DS* and R/W*.

3.2.5. Problems

The  Z8002 does not have a (documented) signal which can be  used 
to  signal  the  execution of a HALT  instruction,  and  activate 
sHLTA.

3.2.6 Comparison of results with the IEEE Standard Specifications

Photographs  of  test  results were taken with  a  HP1615A  Logic 
Analyser using an 8 MHz sampling rate (twice the processor speed) 
to allow direct comparison with ref (3), figures 11a and 11b.

Plate  #2  shows a memory read cycle.  pSYNCH and  pSTVAL  become 
active  in Bus State 1 (BS1),  and become inactive early in  BS2, 
when pDBIN is asserted.  Note that the read control signal, pDBIN 
remains active for 340 nsec,  whilst the write strobe PWR* (plate 
#3)  is only active for 210 nsec.  Thus pSYNCH and pSTVAL  remain 
true well into BS2 of a write cycle.  Note that MWRT (not  sMWRT) 
has been programmed into the PROMs.  The processor inserts a wait 
state  into I/O operations,  such as the I/O write cycle of plate 
#4.

The vectored interrupt cycle is shown in plate #5.  The  sampling 
frequency  was  4 MHz in this case,  to allow fiming of the  full 
cycle.  Both  S100  and the Z80 peripheral  control  signals  are 
shown.

4. CONCLUSIONS

Techniques for interfacing the Z8002 to an I.E.E.E. S100 Bus have 
been  disclosed.  The  Z8001 could also be interfaced with  these 
techniques and the addition of extended addresses A16 to A23.

These  techniques offer a valuable insight into the operation  of 
the Z8002 in addition to this primary role.

The available Z8002 software has been reviewed, and modifications 
suggested to enhance its utility.

5. REFERENCES

1) "Z8000 Development Module,  Hardware Reference Manual",  ZILOG 
Inc., publication number 03-3080-01, June 1979 (as amended)

2) "Am96/4016 AmZ8000 Evaluation Board User's  Manual",  Advanced 
Micro   Computers  publication  number  00680131,   August  1979, 
Distributed by Advanced Micro Devices.

3) K.A.  Elmquist,  H.  Fullmer,  D.B.  Gustavson and G.  Morrow, 
"Standard   Specification  for  S-100  Bus  Interface   Devices", 
COMPUTER, July 1979,  pp 28 to 52.

4)  "Z8000 Development Module,  Monitor Program  Listing",  ZILOG 
Inc., publication number 03-3094-01, June 1979, as amended.

5) "Am96/4016 AmZ8000 Evaluation Board Monitor  Listing",Advanced 
Micro Computers.

6)  "Am  96/4016-ASM Evaluation Board Assembler  User's  Manual", 
Advanced Micro Computers publication number 00680138, Nov. 1979.

7) "A Small Z8000 System,  Application Note",  Peter Altke, ZILOG 
Inc., August 1979

8)  "Z8001 CPU,  Z8002 CPU,  Preliminary Product  Specification", 
ZILOG Inc., publication number 03-8002-01, 1979.

9) R. Korody and P. Alfke, "Learn to apply the power of the Z8002 
by studying a small 16 bit computer",  ELECTRONIC DESIGN 22, Oct. 
25, 1979,  pp 90 to 96.

10)  J.  Banning,  "Z-Bus  and  peripheral support  packages  tie 
distributed  computer systems together",  ELECTRONIC  DESIGN  24, 
Nov. 22, 1979, pp 144 to 150.

11)   W.P.   Fischer,"Microprocessor   Assembly  Language   Draft 
Standard", COMPUTER, Dec. 1979, pp 96 to 109.
