home *** CD-ROM | disk | FTP | other *** search
- GENERAL INFORMATION ON Z280 TO Z80 ADAPTERS:
-
- There are two versions of the adapter board. Both these boards are the
- same size: 4.28" in length, 2.24" in width, and approx. 3/4" deep. The
- basic layout looks like this (as best as can be presented in ASCII:
-
-
-
-
- View from short side:
-
-
- |---- 2.24 " -----|
-
- |
- | Component side
- | ------------------- --->> PCB Board
- | ====== --->> Male socket to plug
- 3/4" into your Z80 socket.
- high
-
- View from long side:
-
-
- |------------ 4.28" -----------|
-
- -------------------------------- --->> PCB Board
- ================== --->> Male Z80 socket
-
-
- The Z80 socket is approximately centered on the PCB, in both directions.
-
- THE "ZIP 280":
-
- This is the direct adapter version of the board. It totally replaces
- the Z80 in your system. The basic diagram of this board is:
-
-
-
- --------- clock ------------ clock ---
- | Z280 |-------------| PHASE |--------|Z|
- | CPU | | LOCK | |8|
- | | | LOOP | |0|
- | | ------------ | |
- | | |S|
- | | address ------------ address|O|
- | |-------------| ADDRESS |--------|C|
- | | | LATCH | |K|
- | | ------------ |E|
- | | |T|
- | | Signals ------------ | |
- | |-------------| ADAPTION |--------| |
- | | | LOGIC | | |
- --------- ------------ ---
- |
- ---------
- | 256kb/|
- | 1mb |
- | DRAM |
- ---------
-
-
- All Z80 signals coming at the socket are "cleaned" versions of the Z280
- signals, operating in the Z80 bus mode. The 64kb address space of the
- Z280 is mapped into the first 64kb of the Z280 16 meg space. The Z280
- comes up on with all modes set to look like a standard Z80 (see the Z280
- technical technical manual). Therefore, after changing out the system
- Z80 for the adapter, the system software should run as before. All the
- Z280 resources, such as onboard DMA, timers, uart, etc. are available
- for use in the system address space on proper programming. Also, the
- new Z280 instructions can be utilized with new system software.
-
- As an additional upgrade aid, a special surface mount 256kb/1mb dram
- package is included on the board. This allows the extension beyond the
- 64kb limit of the Z80 address space, while still keeping the Z80 signal
- format (which has only 16 address bits). The onboard dram is operated
- on anytime the Z280 fetches/writes to the upper 8 meg of its address
- space (address bit 23 set). During this onboard access, the Z80 signals
- at the socket are kept inactive, so that accesses to the onboard memory
- are completely transparent.
-
- There is no way for the Z280 signals/instruction fetch mechanism to be
- made 100% Z80 compatible. However, the onboard adaption logic does help
- with the conversion. Specifically, the onboard PLL matches the Z280
- input clock to the lower Z80 clock provided at the Z80 socket (the Z280,
- using the normal modes, runs at a clock speed, or XTAL speed, 4 times
- the Z80 clock speed). Also, The timing at which the Z80 "wait" line is
- acknowledged is adjusted to match the Z80 (the Z280 accepts waits one
- cycle later than the Z80). The possible incompatibilities with this
- board are:
-
- 1. Timing loops. Any attempt to determine a fixed length of
- time via measurement of time taken to execute an instruction
- will not work. Such loops would be invalidated by a change in
- the Z80 clock speed, by use of "wait" cycles, or by DMA or other
- CPU parallel access. On the Z280, the instruction time cannot
- even be measured reliably; The cache and pipeline make the time
- to execute an instruction dependent on the "history" of activity
- before. Since timing loops are already considered very bad
- coding practice, this can be taken as a signal to get rid of
- them once and for all.
-
- 2. If the code contains very strange self - modifying code.
- Self - modifying code is forbidden absolutely in the Zilog Z280
- technical reference manual, but we have determined that the
- chance of writing such code that can cause Z280 malfunction is
- slight in any case. Example:
-
- ld a,$c3 ! get a "JP" instruction
- ld (loc),a ! place ahead of us
- loc: nop ! instruction that is modified
- dw address ! address to jump to
-
- This would malfunction on the Z280 because by the time the store
- of $c3 to "loc" occurs, the Z280 "pipelining" mechanism would
- have already fetched the "nop" which was supposed to be
- modified.
-
- 3. The Z80 "R" register. This register on the Z80 contains the
- current refresh address, and so will appear to change
- continually to the program running. Some programs have used
- this to generate random numbers (of which it makes a VERY poor
- random number generator).
-
- 4. Utilization of "undocumented" instructions. Some Z80 code
- sequences which evaluate to illegal instructions have a CPU
- result which some programs use. In no way will the Z280 react
- the same way as a Z80 here, and in fact, these can change
- between different "brands" of Z80 CPU's. This is a total misuse
- of the Z80; do not expect these to work.
-
- 5. Use of the "M1" line. The Z280 does not generate a true M1
- signal, and in fact cannot do so. Since the M1 line was not a
- signal commonly required to use the Z80, dependencies on the M1
- line should be small.
-
- 6. Assumption of "dead" lines. When none of the Z80
- (translated) signal lines are active, this DOES NOT mean that
- the address/data lines are floating. In fact, the lower byte of
- the address is being passed to a latch during this time.
- Although the Z80 lines WOULD float during this time, this
- consitiutes an illegal use of the Z80 signals. Example: the
- Cromemco ZPU card has a "auto - jump" option to transfer to a
- specific location on reset. It relies on the ability to force a
- jump instruction into the data lines, regardless of whether or
- not the Z80 is actually executing an instruction fetch. This
- forced data collides with the low address byte coming from the
- Z280.
-
- 7. Assumption of inactive "wait" line between bus cycles. If
- the wait generation circuit assumes that the wait line can be
- set to any value if no Z80 access signals are active, when the
- Z280 accesses the onboard memory, the Z280 may be put into
- perpetual wait. This is because it will acknowledge an active
- wait during this internal cycle. The Zip adapter DOES NOT issue
- any active signals to the Z80 socket during these accesses.
- Only affects people using the onboard extension memory.
-
- The Zip 280 is the board for anyone who is upgrading to the Z280 part in
- an existing design. With perhaps a small amount of modification to
- cover the incompatibilities given above, you can test the Z280 out in
- your existing design, and either ship the system with the adapter in
- place, or go on to design a version of your product incorporating the
- Z280 CPU. For persons attempting to upgrade a system with Zip 280, the
- basic requirements are full hardware and software knowledge of the
- system to be adapted (SCHEMATICS AND SOFTWARE LISTINGS), and a senior
- level engineering knowledge of computer hardware AND software.
-
- This board is considered an AID to Z280 upgrade, and in no way do we
- warrant it as a guaranteed Z80 replacement.
-
- COPROCESSOR VERSION (Accel 280):
-
- Our field tests to determine applicability of the Zip 280 (direct)
- adapter board to existing CP/M upgrade yielded the the following result:
- one or two jumpers and careful check of the system software for timing
- loops, etc. were required on 90% of the systems. I believe this is
- accounted for by two reasons:
-
- 1. Many typical CP/M implementations consist of an "all in one"
- package consisting of the video screen, disk drives and keyboard
- integrated into a single enclosure. There is considerable
- incentive in such a unit to take shortcuts on the design,
- usually to save on chip count. Quirks in the Z80 timing and
- modes are used.
-
- 2. Since the standard Z80 has a very long history, there has
- been considerable incentive to assume that the Z80 would never
- change.
-
- Although the best solution is to directly REPLACE the Z80 by the Z280,
- for people who do not have specific details on their machine (schematics
- and software listings) or the expertise to diagnose problems, a
- virtually 100% compatible solution is provided by the coprocessor
- version of the adapter board. In this version, the Z80 from the system
- is plugged back into the top of the board, then the board inserted into
- the system:
-
-
- -------
- | Z80 | --->> Z80 from present system
- ------------------ --->> PCB
- ======= --->> Z80 socket
-
- ||
- \/
-
- To
- system
- Z80 socket
-
-
- The basic block diagram of the Accel 280 is:
-
-
- --------- data -------------------- data ---
- | Z280 |-------| BIDIRECTIONAL |--------|Z|
- | CPU | | BUS COMMUNICATOR | |8|
- | | | | |0|
- | | -------------------- | | -------
- | | |S| | Z80 |
- | | ------------ |O|<<--| CPU |
- | |-------| 256KB/ | |C| | |
- | | | 1MB | |K| -------
- | | | DRAM | |E|
- | | ------------ |T|
- | | | |
- | | | |
- --------- ---
-
-
- The Z280 is completely isolated from the Z80 CPU here. It executes from
- and makes data accesses to its own DRAM module only. The Z80 CPU
- running the system is the same Z80 as was unplugged before the board was
- inserted. Communication with the Z280 CPU and memory is accomplished via
- an 8 - bit "port". This port is the only interface between the two
- processors. Both processors run CONCURRENTLY. The installation of the
- board is completed by either picking an UNUSED port in the Z80 system,
- or using the default port of $fe. The Z80 CPU, and the system in
- general, operates as a I/O slave CPU. The Z280 CPU runs programs in its
- own DRAM space. When the Z280 requires I/O service, a "request" packet
- is passed to the Z80 CPU, which reads or writes the requested data, and
- returns the results to the Z280 CPU. What is required here is a software
- program run on the Z80 side to operate the coprocessor interface. We
- provide this, in conjunction with the RP/M o/s that provides interface
- via the CP/M BIOS routines. This board is usually used to support CP/M
- based environments, therefore. Support for other interfaces would
- require custom software construction.
-
- Using the RP/M operating system, standard CP/M applications can be run
- on the Z280. The restrictions here are:
-
- 1. The application program may not perform direct I/O to system
- devices. It may however, use I/O based devices in the Z280 CPU
- itself; these include timers, DMA, etc.
-
- 2. Timing loops will be invalidated in an application program.
- Since timing loop are usually associated with I/O, this is less
- of a problem a - priori.
-
- 3. The system I/O (the BIOS program) cannot make use of Z280
- DMA, timer and other devices, or use Z280 advanced instructions.
-
- Note that the BIOS code still runs on the Z80 processor, and has no
- restrictions.
-
- The main penalty for coprocessor operation is the overhead for
- coprocessor interface data passage. This can be offset, however, by the
- effect of having the Z80 CPU process I/O in parallel to the Z280 CPU,
- and also because the Z280 can be operated at full potential speed (since
- it does not have to match clocks with the Z80 side).