Greenbank Electronics

MZC1

Issue: 0

Date: October 1988


2 Circuit Description

2.1 Introduction

Introduction to XM2C-1 CPU card Design

This document describes a design for an additional CPU card to the Interak range. The card is to be known as "M2C-1", but while it is still in development it will have the prefix "x", ie for now it will be xM2C-1

The present design has been arrived at after much careful thought, and experience with how Interak is sold and used. The strength of the Interak system has always been that the system is modular, reliable, easy to construct, easy to understand. The most popular cards have been the simplest - for example a simple RS-232C interface. Less popular has been for example the QS-1 quad serial interface. This latter card is bristling with features and sophistication, options, jumper links, programmable baud rates, interrupt daisy chain lines, card selects, and so on. As a result it has ended up one of the more complex cards and one of the more expensive (although half the price of competing products from RS components, Farnell etc.). However it is too sophisticated, and thus too expensive for the typical Interak user.

The appropriate phrase is that the product has been "over engineered"; our motto should be "keep it simple":

I shall not burden the reader with the initial design I drew up for the XMZC card. It had 40 or more chips, batteries, interfaces, latches, switches, memories, CMOS RAMs, etc. etc. All very desirable, but completely over the top. Too complicated to build, too complicated to use, and too expensive to sell. The CPU card in a system has to last a long time (10 years or so for example in the case of the venerable kemitron MZB-3 Z80 card) and so has to use chips which will be around for years to come. Imagine if Kemitron had used "state of the art" RAM chips on the MZB-3 - we would today be burdened with a row of 8 off 2102 static RAMs to give a massive 1k of RAM (and incidentally costing more than 50 times the quantity of modern DRAM).

The whole idea of a modular pluggable system is that things can be plugged in and out of it, hardware and software too we hope. If everything is built in to a given card then we are forcing people to buy more than they want sooner than they want, or we are riddling the card with options so nobody knows what makes a standard system. And once in track on a card, no part of the circuit can be redesigned or modified without throwing the whole card away.


Comparison of memory space in various systems

Scale: 1 pixel = 64K

64K Interak 1 e.g. Z80, 6502
128K Sinclair Spectrum
640K IBM XT (+Video, BIOS)
16 MByte Extended Interak Z80280 (proposed)

2.2 Circuit Description

It is easy to think of "bells and whistles" to be added to any new card (eg Real Time clock, Electrically Erasable and Programmable ROM instead of EPROM, interface to IBM type of keyboard, printer and serial interfaces, CMOS battery backed RAM, bus monitor and mapping lights, etc. etc.) , but I now think the bells and whistles should be the subject of a separate bells and whistles card. A change of bell or whistle will then not necessitate scrapping the CPU card.

I have now returned from dreamland, and have produced a design which I believe is manufacturable. I have taken advantage of the space I have released by simplifying the concept of the card, to put on extensive buffering, so that the card will be able to drive a full system without future problems.

There is no plan to kill off the Z80A-CPU, which is still selling in ever increasing quantities. Therefore a good deal of thought is required to make sure that Z80 applications can still be supported, programs developed, debugged etc, ditto hardware, even on the new system.

Naturally we cannot make a Z80280 be a Z80, nor vice versa, unless we cripple the Z80280 or bolt on so many extra chips to the Z80 that it becomes a Z80280. Therefore we cannot allow ourselves to accept that say a 1 Megabyte RAM card cannot be addressed by the Z80.

A few users have suggested the use of memory mapping chips such as the Texas Instruments 74LS612 as used in the IBM AT for the same purpose. When we learn that the current price of the 74LS612 (see RS components catalogue) is more than that of the Z80280 then this takes a bit of the shine off the idea. If we're going to buy a memory mapping chip at all, we may as well buy the one built into the Z80280, and get all the other features for free rather than pay more for the 74LS612. On the other hand it is reasonable to expect the Z80280 to be able to make use of the existing range of cards, the 8255A (SBC-1) card, floppy disk card, DRM-64 RAM card, serial interface card and so on.

A new monitor program / disk boot will be required, but this can be based on the existing DMON, without the need to commission a new program. we already have the "Plus" version of CP/M, which is well organised for handling a memory space of greater than 54k, so we hope the alterations will be relatively painless.

I believe I have now fully justified the philosophy of the new design, and I now proceed to the specification without any further debate:

Specification (Design Goals)

This gives a new space of 16 MByte minus 128 KByte space, i.e. 16646144 Bytes, which should be enough for the time being.

Refresh, when carried out by the Z80280, should activate both the ordinary and extended memory request lines, i.e. both NMREQ and NENREQ. At all other times only one or other of the memory request lines vill be active, to prevent conflicts.

In a similar manner to the allocation of 64K bytes to the purpose of Interak 1 memory access, a portion of the Z80280 I/O space will be allocated to the existing I/O select control line, NIOREQ. If we think of the existing Z80 I/O space as being 256 bytes (the "usual" space, not the full 64K of space which even the Z80 could access by using the address bus AB8-AB15 to select extra I/O port addresses), then 256 bytes of the Z80280 I/O space are to be devoted to the needs of the existing cards. Accesses to the I/O space outside this range will be via the "extended" I/O request control line, NEIOREQ.

At power on (reset), the design will arrange things so that the first instructions will be fetched and executed from the on board ROM. Once the Z80280 has control the memory mapping and manaqement can be arranged (by software instructions, operating the hardware) so that the ROM is mapped high up in memory, allowing RAM to be located in the system from address zero upwards. The mapping of the 64K for the existing Interak system will similarly be arranged high up in memory, clear of the RAM.

The policy for the production of new Interak memory cards will be as follows: Memory cards greater than 64K will (necessarily) use the extended memory request line, NEMREQ, and will not be suitable for use (except in the most limited of fashions) in a 64K Z80 system. This applies too to cards which use the memory space, e.g graphics RAM, RAM disks, Hard disk buffer caches, EPROM programming areas, etc.

The policy for the production of new Interak I/O cards will be as follows: I/O cards will continue to use the existing 256 byte I/O space, and a new table will be drawn up giving guidance on general allocations of space for specific purposes. In this way new I/O card developments will be suitable for use in either a Z80 or a Z80280 system. This is not to say that use of the expanded Z80280 space will be prohibited, but it will only be used if there is a good reason, e.g. the card for some reason will never be used in a Z80 system - using too many ports for example, or ports which control the use of a card which is already a Z80280-only card, e.g large graphics management. (The benefit of this policy is that address decoding for I/O cards may continue to be 8-bit; a larger space would force the expense and inconvenience of 16-bit decoding and the need to buffer the extra address lines used in the decoding.)

The new card should be suitable for 15MHz (preferably 20 MHz) crystal operation in existing systems, and should also be suitable for use with faster Z80280s (e.g. 50 MHz) should they ever be produced by Zilog. This implies management of the bus clock scaling factor at power on, and the provision of wait states (if needed) for accesses to existing Interak cards and the on board ROM. (The wait states which can be programmed into the Z80280 by software are too coarse for this purpose as they cover an 8 Megabyte range - all or nothing!)

Wait states for the I/O space need not be generated by on board hardware. If wait states are needed for an I/o access the appropriate register(s) can be altered by Z80280software before the access is made. Any individual I/O cards which need wait states can of course (and should) generate these themselves by controlling the wait control line, NWAIT.

Reset will be automatic at power on, and also controllable by a switch. The necessary additions to the reset circuit will be included to ensure that the contents of DRAM are not corrupted by a reset operation by the switch, and a suitable circuit will be devised to allow the "Bus Timing and Initialisation Register" to be set automatically at power on or reset.

Extensive use will be made of the high speed CMOS 74HC and 74AC families of logic, which are expected to take over from 74 LS during the lifetime of this board. Wherever possible chips which are available in all families (including 74LS) will be used, so that users can use up existing stocks of 74 is if they wish. However the design will not be prejudiced by this; if HC logic is the most suitable then this will be used.

The on board UART in the Z80280 is not very sophisticated, having no handshake lines, and combined transmit and receive clocks etc. Its most likely use would be for serial communication via a terminal or another computer in a minimum configuration. No separate baud rate clock will be provided in the design, and the UART clock (if used) will be derived from the Z80280 clock, via an internal counter timer circuit.

It is possible that a deviation from a good round number (eg 16 MHz or 20 MHz) for the crystal clock would make for more accurate baud rates, but if the error is likely to be less than a few percent, then the general untidiness of using an "ugly" frequency clock will not be accepted.

The external parts of the "on-chip" peripherals will not be built into the system, with the obvious exception of the master clock input circuit, and the likely exception of the UART for serial communication. (Indeed the TTL to RS-232 voltage level translator chip type 145406 will be built into the design for this purpose.)

The remaining on-chip peripherals, and my comments, are as follows: CTC circuits - inputs and outputs merely terminated in holes on the pcb for a connector for external use if required by the user (this of course does not prejudice their use for internal software counting and timing). Similarly the DMA circuits, the Local Bus Request and control circuits, the Global Bus Request and control circuits and the handling of the Extension Processor mechanism. Some of the signals may be brought to the edge connector where this seems appropriate, but largely they will not be used in our systems.

The idea of multiple processors sharing Local and Global resources, at first seems quite attractive, but the method of managing this activity, arbitrating between different requesters of resources, and so on demands special logic which is it is unwise to build into the main system board. For example once the Z80280 is switched off for DMA accesses to proceed, or for a second processor to gain access, who is going to look after the refresh of the dynamic RAMs in the system?

I am not against the idea of many microprocessors in a system, but I have my doubts about them all fighting for and sharing the same resources. What use is the introduction of say the M25 motorway if too many people fight to use it. At the best unwanted delays and inefficiencies result, and at the worst the whole system locks up and crashes are caused - a crash in a computer is not perhaps as serious as a crash on the M25, but we still don't want to take the risk without a good reason.

There are (arguably) applications which can take advantage of multi-processors all sharing the same resources, but the management of such system design pushes Interak too far away from its origins ("Keep it simple" - remember?) A very good bus and system design already exists for those who want it: the VME (versa Modular Europe) Bus, however it is an acquired taste cards for wme applications often cost literally 10 (ten) times that of a similar interak card to fulfill the same purpose.

As a final word on this subject: If we want our computers to run faster we should add more memory (and use it wisely, to avoid disk accesses) or add hard disk drives. The effect of this will be far more dramatic than jamming in extra processors on the same bus. (A Porsche (yuk) in a traffic jam goes just as slowly if it has a normal one engine or if it has two.)

(This ends the Introduction to the design and the specification List and discussion of Design Goals)


Proposed Memory Map

000000Dynamic RAM
400000RAM/Video?
800000Video
C00000Various EPROMs
FE0000Interak 1 (64K)
FF0000Boot ROM (64K)

Memory Mapping

The memory space accessed by the Z80280 is 16 Megabytes. In the diagrams which follow hexadecimal notation is used, "low" addresses are at the bottom of the diagram, and "high" addresses are at the top. This is in keeping with the general jargon which refers to the "top" of memory, and "stack overflow". The higher we go the bigger the numbers get.

Starting at the bottom, we have 4 Megabytes (000000-3FFFFF) which will definitely be RAM, almost certainly Dynamic.

The use of the next 4 Megabytes (400000-7FFFFF) is less certain. I am not sure what we will run out of first - RAM for the glorious Memory Mapped Graphics, or general purpose RAM. Leave this space blank for a while.

The next 4 Megabytes (800000-BFFFFF) are reserved for memory-mapped graphics purposes ("video RAM"). The last 4 Megabytes (CD0000-FFFFFF) are largely used for odds and ends; things which have not been invented yet. Examples are a memory mapped EPROM card, and EPROM programmer. (I know we have designed an I/O accessed EPROM programmer, but it proved too complex to fit on one board; I am sure an easier technique would be to have it memory mapped in the same way as the original Kemitron PP-2 Design used by ZYMON; "Keep it simple"?).

Other ideas would be in debugging other systems, CCD000-FFFFF could include areas which are an image of the system being debugged, and which can be examined at our leisure in our system. an intelligent hard disk interface, or a whole track floppy disk buffer, could be devised, each with their own private (Z80?) CPUs, with common RAM in this area. (See, I'm not totally opposed to multi-processors; I just like them simple.)

At the very top of memory are two dedicated areas, each of 64K. First we have FEC000-FEFFFF for Interak 64K, which translates to our existing 0000-FFFF. When the Z80280 accesses FE0000 then the normal (for the Z80280) extended memory request control, NEMREQ, is not generated; instead the original 64K Interak memory request, NMREQ, is produced, thus enabling all of the cards in the 64K Interak we already know and love.

Outside this 64K range no NMREQ is produced, and so the old 64K Interak cards are not accessed. (It would be disaster if they were because they would put their data on the bus in contention with that from the various 4 MByte areas already discussed.

Finally we come to the last 64K, FF0000-FFFFFF. This is all reserved for the on board ROM firmware. A 28-pin socket will be provided, which defines the maximum EPROM size readily available as being 64K. (There are bigger than 64K EPROMs which will fit in a 28-pin socket, but they themselves use a paging mode, and are trickier to access, particularly at power-on time when there's already more than enough paging going on.

EPROMs larger than 64K which have conventional addressing require larger sockets, e.g. 32-pin or 40 pin. Let us say that 64K will be enough to get the system booted up.) Read operations from to FF0000-FFFFFF generate an external memory request, NEMREQ, like the other addresses in the Z80280's range but the data on the bus is not allowed on the card; instead the data comes from the on board firmware ROM, not the external system. Writes to that address do in fact get out on to the system bus (because there is little point in writing to an ROM, it takes more than that to make its data change). This may be useful some time in the future as it lends itself to easy modification if somebody ever invents a ROM you can write to (in fact I think they already have), or perhaps the use of those "paged" EPROMs I mentioned.

There is something else to be mentioned regarding the onboard firmware: At power on, or reset, a special arrangement of hardware ensures that not only does the ROM occupy the address already mentioned (FF0000-FFFFF), it occupies every address in the system. This is necessary to ensure that at power on, when the microprocessor fetches its first instruction from location 000000, there is a program at that address.

After the ROM gains control, it can establish the required memory map, wait states, etc., by means of the special registers in the Z80280, and finally turn off the mechanism which first established it at location DD0000 onwards (and everywhere else). The "turning off" of this power on mechanism is carried out under software control as being the result of performing any I/O Read tie "IN") instruction.

I/O Writes ("OUT" instructions) are permitted: it is only an I/O Read which establishes the ROM in its final position. The ROM program can retain control, or control can be passed to a program loaded from disk or tape or via a serial port, or from ROM elsewhere in memory.


Proposed I/O Map

00xxxxInterak I/O spaces
010000
...
FDFFFF
Unused
FExxxxZ80280 "on-chip" peripherals
FFxxxx

I/O Space Mapping (Please see diagram "Proposed I/O Map")

The total I/O space addressable by the Z80280 is, similarly to the memory space, 16 Megabytes. However this is not often used, certainly not in our systems anyway. 16 Megabytes of I/O is just too much. Typical I/O peripherals, such as PIO (peripheral input output) chips, and UARTs (universal Asynchronous Receiver Transmitters) only require a handful of port addresses. If we generously allowed for an average of say 10 I/O port addresses per card then even an Interak rack full of I/O cards would only require 120 addresses. 15 Megabytes of I/O would provide for more than 100,000 such racks full of cards without ever repeating an address. Being aware of this, Zilog in the design of the original Z80, and now the Z80280), decided to make better use of the address bus lines. During an 1/0 access the eight address bus lines AB8 to AB15 are treated in a special manner. on these lines the contents of a register, either A or B, are output during an I/O access.

Conceivably these lines could be used as an address (thus boosting the normal Z80 I/O port addressing range from 256 bytes to 64K, and the Z80280 range from 64K to 16M), but most systems designers (me for example) either ignore the feature or use it instead to allow 16-bit data writes in a single output instruction. In this last application 8 bits are output on the data bus, as usual, and the other 8 bits are output on the "unused" address lines ABB to AB15.

This feature is often disregarded because of a (perhaps misguided) wish to keep programs compatible with ones which run on close relatives of the Z80, for example the Intel products 8080 (the Daddy of them all) and the Intel 8085 (a half brother to the Z80). Intel are proud of boasting about the 8080, but they hardly mention the 8085 now - probably sour grapes because the introduction of the 8085 was eclipsed by the runaway success of the Z80.

But back to the plot. Depending on how you look at it, the Z80 then has either a 256 byte I/O space addressed on lines AB0 to AB7, (with an optional additional 8 bits of data output on lines AB8 to AB15), or if you like, it has a 64K I/O space addressed on the address lines AB0 to AB15. We generally quote 16 bit addresses in the form of a 4 digit hexadecimal number, eg if the sixteen address lines in a memory access were 1011000010110001, we can express this address in hexadecimal notation as "B0B1". Because of the two ways of looking at the addressing of the I/O space (256 bytes or 64K) a hexadecimal address in the I/O space is often written for example "xxB1". Here the "xx" means "don't care" in that it is the same I/O port address on AB0 to AB7 regardless of the contents of the address bus lines AB8 to AB15. Of course there are times when we "do care", but I like this notation myself because its slightly ambiguous nature reminds me of the two ways of looking at the AB8 to AB15 bus lines during an I/O transaction.

All this is so I can refer to the I/O port space in the Z80280. As the Z80280 has an additional 8 address lines (AB16 to AB23) the range of I/O addresses is increased by the same factor as was the range of memory addresses. 16 Megabytes of I/O if you like, but more practically 64K, with those middle 8 address lines as "don't cares". I demonstrated earlier that 256 bytes of I/O is quite sufficient, so 64K of I/O must be more than sufficient. Therefore my view of the I/O space available in the Z80280 is that is 64K running from address 00xx00 right up to FFxxFF. Zilog have swiped the top few addresses (FExxFF to FFxxFF) for their own use in accessing what they term the "on chip peripherals" (thus explaining how they have added to the Z80 facilities but retained the Z80 operation codes).

In the discussion on the proposed memory map, I showed how the space for the Boot ROM and the 64K Interak was pushed high up into the attic, like an unwanted relative, out of sight of the brave new world of Megabytes of RAM and the like. Such unkind treatment is not to be the lot of the 256 byte Interak I/O space.

The I/O cards are still fully franchised members of the family; such items as disk interface, serial RS-232, parallel printers, etc. are all still required in a large system, and so I have decided that the 256 ports of the existing Interak system can be in common with the first 255 ports of a Z80280 system. As in the case of the two control lines for the Memory space ("memory request" and "extended memory request") we have two lines for control of the I/O space: the conventional "I/O Request", NIORQ, and "Extended I/O Request", NEIOREQ.

An access to one of the first 256 bytes of I/O (i.e. hexadecimal 00xx00 to 00xxFF) will generate the existing I/O request; outside this range (i.e. from 01xx00 to around FDxxFF) the extended I/O request will be generated instead. I am a little vague as to the precise upper limit, the Zilog Technical Manual for the Z80280 should be consulted to see exactly what behaviour results on the control lines during accesses to the on chip peripherals, and to see just how many port addresses they occupy.

Policy on Production of New Interak cards

This document describes the design of one new Interak card: the XM2C-1 CPU card. Also planned is a new Z80 card, with substantially the same performance as the existing M2B-3. The future in Interak will see the parallel development of two types of system: Z80 based, for those applications where 64K of RAM is enough, and Z80280 based, where 64K isn't enough.

We will become a little like a two car family - a mighty Mercedes for the husband to take the whole family on a tour to the south of France, and a modest little Mini for the wife to pop down to Sainsbury's in. (or, to show I am not a male chauvinist, the wife can go to the south of France whilst I enjoy myself at Sainsbury's.) Sometimes the Z80280 will be the more appropriate, and sometimes the Z80.

We shall also keep a weather eye on the Zilog/Hitachi 64180, or Z180 as Zilog call it. This lies somewhere between the Z80 and the Z80280, having an address range of 1 Megabyte, i.e. 16 times greater than the Z80 but in turn only one sixteenth of the address range of the Z80280.

Its on board peripherals are as good if not better than the Z80280's, but its compatibility with the Z80 is not so complete as the Z80280's. (For example the Z80280 can be arranged to power on looking exactly like a Z80, the 64180 has power on port mapping for the on chip periperals which means that an existing 780 program will not run without some minor changes to the I/O addressing.)

The policy on new Interak cards will be as follows: Memory cards (and cards which use the memory space) of 64K or less, will be designed so that they can be used in either a 64K Z80 system or a 16M Z80280 system, controlled by the conventional Memory Request line.

Memory cards or cards which use the memory space, occupying more than 64K will be designed to suit only the Z80280, controlled by the Extended Memory Request line.

Most new I/O cards will be designed to use the first 256 I/o ports, controlled by the conventional I/O Request line, and thus can be used in either Z80 or Z80280 systems. If for some good reason (it would have to be good) cards needing to use an I/O port space of 64K were introduced then they will be accessed via the Extended I/O Request line, and thus be predominantly suitable for only the Z80280 systems. (It would be quite simple to include jumpering on small I/O cards so that they were controlled either by the conventional or the extended I/O control lines. In this case the system would allow an I/O space of 256+256 to be developed - this might be useful in development work when there might be a conflict of development system port usage and "target" system port usage)

2.3 DIL Switch settings, links, options etc.

It is a little early to be describing these as there is no card in production. However we hope there will be very little to be set up and altered; probably no more than the following: There are two 3-pin 0.1" pitch pin assemblies shown on sheet 4 of the diagram. one is marked FE(L) and the other is marked FF(L). These introduce wait states (independently of those introduced by the contents of the control registers in the Z80280, and independently of any that may be produced by other cards in the system via the normal method of operating the wait line in the system).

The easiest positions to describe are those where the links are in positions 2-3; in this case there are no wait states set and this part of the circuit has no effect.

If a link is fitted to join 1-2 on the FE(L) pin assembly then wait state (s) are introduced for any access to the 64K space which uses the normal (i.e. not the expanded) memory request line for control. In an Interak system this will access cards which only need a 64K space, and which generally will be designed to work with a Z80A-CPU.

Adding wait states in the memory area reserved for these "old 64K" cards will allow them to be accessed correctly without the need to slow down the rest of the Z80280 system. With the link fitted the wait state (s) will be introduced for accesses to (24-bit) addresses FE0000-FEFFFF. If a link is fitted to join 1-2 on the FF(L) pin assembly then wait state(s) are introduced for any access to the on board ROM, since this is located at (24-bit) address FF0000-FFFFFF. At power on every access to memory is forced to the on board Rom (as part of the "boot" procedure) and so wait states set here apply over the whole memory map until the booting procedure is finished.

In the initial stages we propose to test the Z80280 with a 16 MHz crystal, and to run the bus at the same speed as before, i.e. nominally the same as the speed of a Z80A-CPU running at 4 MHz crystal frequency.

Thus we are going no faster than before, and the link on the FE(L) assembly can be set for now on positions 2-3. 8K and upward EPROMs are all nowadays supplied with access times shorter than 250 ns, so by the same token the link on the FF(L) assembly likewise should be 2-3.

Also on sheet 4 are shown the 8 jumper links which establish the initial settings of the Z80280 "Bus Timing and Initialisation Register". (See Zilog Technical Manual Chapter 3, page 3-1, section 3.2.1)

Reading from ZD7 to ZD0 the links perform the following function (in what follows, "loading a bit with a 1" means link 1-2 on the appropriate pin assembly "0" means link 2-3):

ZD7.

Reserved by Zilog; always load a 0.

ZD6.

BS Mode Enable bit; we do not use this mode so you should load a 0.

ZD5.

Multiprocessor Configuration Enable bit; we do not use this mode, so you should load a 0.

ZD4.

Reserved by Zilog; always load a 0.

ZD3, ZD2

These two act together and set the number of wait states initially applied to the lower 8 Megabytes of memory. Whatever the setting is here, it can be overruled by software during the initialisation procedure in the "boot" RROM, so it does not really matter. To suit those hoarders who still have stocks of slow old 450 ns EPROMs, we can set these bits up to give one wait state, i.e. load a 0 to ZD3 and load a 1 to ZD2.

ZD1, ZD0

These two act together to establish the speed at which the Z80280 will access the system bus. The Isbus back board in Interak, and all of the cards designed for Interak at present require a bus operating at what would be equivalent to a Z80A-CPU operating with a 4 MHz clock. On the Z80280 with a 16 MHz crystal this is means that the required bus scaling factor is one half. To achieve this load a 0 to both ZD1 and ZD0.

Summarising, the initial settings of the Register in the order given above should be:

	ZD7, ZD6, ZD5, ZD4, ZD3, ZD2, ZD1, ZD0
	 0    0    0    0    0    1    0    0

(Note that for my purposes all 0's are perfectly acceptable, and this is the condition which the Z80280 starts off in if the method of holding the wait line low during power up is used. Thus in the event of trouble during your first experiments it is probably OK not to bother with this feature and to let the Z80280 initialisation look after itself).

The remaining links requiring comment would be on diagram sheet 5 if I had drawn any. They would be related to the handshaking on the RS-232 serial in/out link, and anything that turns up when we start to experiment with the CTC and DMA channels.

Finally, in the finished manual I shall have to say something about the connections to components mounted on the front panel, for example the proposed pinouts and connector for the RS-232 in/out channel (a 25-way D type of course), the LEDs (if fitted on the panel), and the reset push button.

The circuit diagrams towards the end of this Manual will be taken as the basis for the detailed circuit description. The purpose of this Manual sadly (for the reader, not the writer) does not extend to being a course on digital circuit design, and so it will have to be assumed that a certain amount of background knowledge is possessed by the reader.

Mostly, the components on the diagrams and in the parts list use the designation letters specified in ANSI standard Y22.21970. In a way these letters are fairly irrational (e.g. "J" is a connector, "Q" is a transistor, "U" an integrated circuit, and so on), however as it is a standard it has been adopted here. The component overlay diagram uses the same designations as for the circuit diagrams.

(FUTURE) A block diagram is provided, which also serves as a "map" showing the user where he may find the particular section of the circuit in which he has an interest. Each of the sections represents a logical unit of the whole circuit. Particular care has been taken when preparing the diagrams to ensure, as far as is reasonably possible, that the logic flow begins at the top-left hand corner of the drawing, and continues downwards from left to right.

Another convention which has been followed as rigorously as possible is to have the inputs to the left of each circuit block and the outputs to the right. Although this is a very logical and sensible approach to drawing circuit diagrams, it is surprising how often these ideas are disregarded, although perhaps not so surprising to those who have ever performed the mental contortions required to make a circuit diagram lie down on a page and stop wriggling.

(FUTURE). In order to include the information which it is desired to present on the circuit diagrams (pin numbers, function names, power supply pins etc.), it has been necessary to use several sheets of paper. However great care has been taken in partitioning the diagram to turn this apparent disadvantage into a positive advantage, by breaking the circuit up into individual sub-functions which are more easy to understand a step at a time. Even the order of the various sheets has been given close attention, so that as far as possible the source of a signal is shown on an earlier diagram before it used on a later one.

All signals which connect to a part of the circuit on a different page are given names, and their source or destination is shown in the form (e.g.) Sigl. 3/10,12(4): 6/9(5). This (fictitious) example means the signal called SIG1 is connected to us pins 10, 12 on the circuit diagram sheet (4), and also U6 pin 9 on sheet (5) of the diagram.

So as not to interfere with the understanding of the logic flow, not all power supplies are shown on the integrated circuit drawings. Instead, each sheet of the diagram contains a table of the integrated circuits on that sheet, their type number, and their power supply connection pins. This does not apply to power supply connections which represent a logic level input, for example 0V for a logic "0", or +5 V for a logic "1": these are shown connected to the integrated circuit pins. An effort has been made to show all pins of each integrated circuit, even the ones which are not connected to anything else. Such pins are marked "NC", which means "not connected".

(FUTURE). The Parts List is to be found at the very back of the Manual, for easy reference. It is organised in two ways; firstly by component reference number, which gives the component value if the reference number is known, and secondly by component value, which gives the reference numbers of all the components which have that value. The latter method is more convenient when checking a kit of parts and assembling the card; for example it is often useful to know where all of the components of a given value should be located if you finish construction and find one or two items left over.

Later, you will want to know the value of a component of a given reference number, and the first method of forming the parts list will be more appropriate. To minimise the well known chore of searching all over a circuit board seeing if you can find say C11, or R17, which have become temporarily invisible, the components on the component overlay have been numbered in ascending numerical order, starting at the top left-hand corner and working across and down to the bottom right. (So if you are looking for an elusive R17, you will know you are getting warm if you see R16 or R18: R17 won't be far away.)

(FUTURE). To help users carrying out tests on the card, or wishing to modify it, both ends of such components as resistors and non polarised capacitors are identified on the circuit diagram; for example if it is wished to check the output pin __ of __ (on sheet __ of the circuit diagram) it can be seen that it is connected to end __ of __, end of being connected to .

On the component overlay diagram and the card itself, viewed on side B in "landscape" position with the edge connector to the right, horizontally positioned components should be taken as having end 1 to the left and end 2 to the right, and vertically positioned components should be taken as having end one to the top of the diagram, and end 2 to the bottom. In an effort to help users all components have been placed on the card in a similar direction, so that for example all the ICs are the same way round, similarly the electrolytic capacitors and diodes.

(FUTURE) Section 6 of this Manual also includes various timing diagrams, which may be an aid to understanding certain parts of the circuit.

As the circuit diagram has been drawn split up into logical blocks, these represent convenient sections into which the circuit description may be divided.

(FUTURE) sheet 0. The Block Diagram.

Detailed circuit description

	* * * * * * * * * * * * * * * * * * * * * * * * *
	* WARNING!  THE CIRCUIT DIAGRAMS ARE		*
	* PRESENTED  ONLY  FOR THE PURPOSE OF		*
	* DEMONSTRATING THE PHILOSOPHY BEHIND THE	* 
	* PRESENT DESIGN. THEY CONTAIN A NUMBER OF	*
	* ERRORS AND INACCURACIES AND SHOULD BE		*
	* CHECKED THOROUGHLY AND REVISED BEFORE		*
	* BUILDING COMMENCES. (CONTACT DM PARKINS 	*
	* ON 051-545 3391 IF YOU SEE ANY ERRORS, OR 	*
	* IF YOU WANT THE LATEST ISSUE OF THE		*
	* DIAGRAMS)					*
	* * * * * * * * * * * * * * * * * * * * * * * * *

The Circuit Diagram comprises 5 sheets. This is easier for me to draw and edit, and I have divided the circuit into different logical units, which I find easier to deal with during discussion and construction. If you prefer one big diagram then I am afraid you will have to stick all the pieces together yourself. If it then looks like one big ugly mess which is impossible to understand then all I can say is "I told you so."

Sheet 1. Address and Data Buffers

There are 24 address lines and 8 data lines on the XM2C-1 card. All are buffered on and off the card by HC541s. These have been chosen because they have 2 output enable lines which are gated together internally, which saves on an external gate whenever two control lines are used, they are also available in other family ranges such as advanced high speed logic "AC", which may become relevant in the future, but most importantly they have "flow through" pinouts which make it possible to lay the circuit out on one of our cards without suffering the expense and complexity of a multilayer construction. separate input and output buffers are used on the data bus, instead of a device such as HC245. This enables us to use different family chips for input and output (useful at the moment whilst the Interak buses are all TTL levels), and allows the insertion of series input protection resistor networks in the input circuits without them appearing in the output circuits.

Other items of note on this sheet of the diagram are the use of a HC573 transparent latch to demultiplex the 8 lowest address lines (these are output by the Z80280 on its data bus to keep the number of package pins used to as "few" as 68.), and the general use of BUSACK (H) (derived from the bus acknowledge response from the Z80280) to disable all of the buffers. Finally notice that the input and output buffers on the data lines are controlled by separate signals. The Z80280 generates two controls: OE(L) output enable, and IE(L) input enable. This saves quite a bit of logic producing a set of control signals which cater for everything, eg both interrupt acknowledge inputs and normal read inputs, whilst avoiding bus contentions. The Z80280 or (L) signal is used directly as ZOE(L) on the diagram, and the Z80280 IE(L) is used to derive the signal shown here as RDBUFF(L).

Sheet 2. Control Signals

This diagram deals with all of the CPU control signals, read and write strobes, refresh, halt etc., and the input signals such as Interrupts, wait, etc. Inputs are on the left, outputs on the right. The inputs are all taken from open collector lines on the Interak bus and a plug in resistor pack provides the necessary pull up. As the pull ups are being used for a logic function rather than simply protecting a coos input they have a lower value, about 1 kilohm instead of hundreds of kilohms. The series resistors are protection for the inputs of the HC541 buffers.

The outputs on this sheet fall into 4 classes: (1) unused, (2) those used on the board only which are are unbuffered so as to cause no delay; (3) open collector drivers and (4) those driving tristate bus lines.

The unused control outputs ("Pause" and "Reserved") are simply unterminated. We have received a suggestion that the unused control outputs should be brought out to a connector for some future purpose but alone they will be of little use: "Pause" is used with an extended processor (which Zilog have no plans to produce) - if they did it would surely need more than this one signal to work it, total changes to the entire design, buses, buffering etc., would be required. "Reserved" equally is difficult to foresee being of fundamental importance now or in the future.

The unbuffered outputs are ones which do not leave the card but are used by other circuits on the card. The Z80280 is a CMOS (Complementary Metal Oxide Semiconductor) device and its outputs are therefore able to swing from rail to rail (0V to +5V) and correctly drive the CMOS 74-series logic chips correctly. Inverting chips are used where the active low signal from the Z80280 is more convenient for subsequent operations if it is converted to an active high signal. Examples of the signals used directly without buffering are the inputs to the HALT LED drivers, and the signals ZIOREQ(L) ZMREQ(L) etc., at the bottom of the diagram, signals unbuffered and inverted before use are ZBUSACK(L) and ZADS(L).

The third group are the group of outputs which drive so called "open collector" bus lines. In the CMOS transistors used in these modern integrated circuits there are no such things as collectors, bases, emitters, but the term hangs on as a reminder of the past. It still hangs on in the term used for the positive supply in the integrated circuits: VCC (voltage of collectors). Those of us who call memory in a computer "core store" are showing our great age - few modern computers now have memories made from a core of magnetic rings. Another odd idea from the old days is the distinction between ROM and RAM memories; ROM means Read only Memory, fair enough, and RAM means Random Access Memory, again fair enough. But does that mean that a random access may not be made to a ROM? In fact modern Rows can be accessed completely at random, it was only the ancient ROMs in computers (magnetic drum stores, and the like) which could not be accessed randomly.

If anything, the open collector lines should be called "open drains" unsavoury as that sounds because the transistors in the integrated circuits used now have sources, gates, and drains as their terminals. But I digress: in this design the effect of an open collector driver is simulated by the appropriate use of an HC125 tri-state buffer. To do this the input of the HC125 is connected to 0V, and the signal which is to drive the open collector line is connected to the control input of the HC125; when the control signal is low the output is low, and when the control signal is high the output is tristate or "open".

The "open collector" output bus lines shown here are NBAO (Bus Available output), NRST (system Reset), and NWAIT (wait state Control). The outputs which drive tristate bus lines employ either a HC541 or HC125 bus driving integrated circuit. 74HC bus drivers can sink or source 6 mA, at logic 0 and logic l outputs respectively. This may not sound a lot compared with the 74LS types, but "HC" logic has the benefit that the amount of current drive available during a transition from one logic level is quite substantial, in the order of 70 mA or so; ideally suited to driving the long lines on a bus. Up our sleeve for the future if extreme levels of drive, or higher speed is required is the availability of the same function in the "AC" (advanced CMOS) range - these have about 4 times the sink or source capability. (Incidentally these very high speed chips should not be substituted casually in all positions; the higher is the speed and pulse currents often is the higher the noise and interference generated, particularly in hand-wired prototypes.)

Perhaps unwisely, I have allowed for an input to the Bus Request of the Z80280, which can render most of its outputs high impedance. In order to terminate the inputs of the output buffer chips etc. under these circumstances, high value (100k or so) resistors have been provided for the lines which otherwise would "float".

When the Bus Request input is activated not only does the Z80280 relinquish its own buses but the whole XM2C-1 card should as well; this is the reason for the signal called BUSACK (H) being connected into the output tristate buffer control (on this sheet of the diagram and sheet 1). The uninverted Bus Acknowledge signal itself of course does not go tristate, so this is connected to the bus via a permanently enabled buffer, the bus signal name being NBAC, Bus Available output.

Despite all this there is little use for the Bus Request mechanism in any system I can foresee. If this card relinquishes the bus then we had better be pretty certain that there is something else ready to take over - this implies quite complex bus controller logic, arbitration mechanisms and so on. The matter is complicated further in that the Z80280 also has a "Global Bus Request" and "Global Bus Grant" set of control lines (these are alternative uses for the counter Timer In/out 0, and counter Timer Input 0, if you are searching for them). Remember when turning over the bus to some other bus master, that bus master becomes responsible for refreshing the dynamic RAM, managing the normal and expanded Memory Request and I/O request mechanism, and so on. All matters which are in conflict with our motto "Keep it simple".

The Halt output, by way of a gimmick, drives a pair of LEDs, "Red" means Halt, "Green" means Run. If a dual red and green LED is used it will change colour in the same way, and would even show as yellow if there were regular transitions between red and green. In present Interak systems "Halt" is never used, but once interrupts are brought into play, the Halt (or waiting for interrupt or reset) indicator will have more application. The Z80280 has a sophisticated method for trapping and detecting various other violations of correct operation. If nothing else the Halt indicator is useful for indicating the existence of the ominous sounding "Fatal condition" (see Zilog Provisional Technical Manual Section 6 page 6-11.) This produces a Halt state which can only be exited by a reset.

Pin 34 "opt" is connected to 0V. This establishes the operation of the Z80280 as being suitable for the Z80 environment. If this pin were connected to +5 V then the chip would behave as a "ZBUS" type of processor, i.e. 16-bit data bus and timing and control similar to that of Zilog's 28000 and Z80000 offerings. The idea of using the Z80280 in this last mode in the Interak system has been ruled out entirely. ZBus lacks signals like the Z80 clock, Ml and so on, (not that in itself is a bad thing) so it certainly cannot be used with existing cards in the Interak range which require those signals. Such items as the ZBus equivalent of say the Z80 dual serial chips are often twice the price, so use of the ZBUS cuts us off from existing supplies of chips we know about. Without the Z80 clock the edges of strobe signals become important, and the noise, crosstalk, etc performance of the bus becomes more critical (if there are bad edges on strobes in a Z80 system it does not matter because transactions are timed by the 280 clock, which operates within the control pulses, after data has settled.

I do not mean to say there is not room in the world for us to design a bus other than the Interak Z80 Bus, but if Zilog succeed in killing off the Z80, it would not do them any good as far as I am concerned. If they let me (and the rest of the Interak community) down on the Z80 I am hardly likely to come back for another pasting on the ZBus!

Similarly if the design of this new card were to force all existing users to buy a new set of cards, then I would not be surprised if they chose not to buy them from me !

Sheet 3. Boot Row, I/O and Memory Expansion control signals

Much has already be said of these matters and how the memory I/O and Boot ROM spaces are mapped. On this sheet we see the circuit to achieve all this. At the top left hand side of the diagram is an HC30 8-input NAND gate whose output is labelled FE.FF(L) This goes low when the top seven address lines ZA17-ZA23 are 1, i.e. at the very top of the memory map, addresses FE0000 to FFFFFF, for the two 64K areas having addresses FExxxx and FFXxxx. (FExxxx is used to map in the 64K Interak system, and F0xxxx provides 64K for the on board Rom.) which of the two it is to be depends of course on address 2A16, since that is the one which distinguishes FFxxxx from FExxxx. 2A16 is taken to an HC04 inverter so the output of the following HCO2, (output labelled FF (H), goes low only for addresses FFXxxx.

The signal path to the chip enable of the Boot Row (for that is our destination in this part of the discussion) continues as follows: in a further HC02 the FF (H) signal is combined with one called PWRON (H); this comes from a circuit on sheet 4 which will be discussed shortly, and is a signal which is high when the board is first powered on. If either (or both) of the PWRon (H) or FF (H) lines are high, the output of this HC02 goes low. In this case ZMREQ(L) which is effectively connected into the HC32 or-gate we come to next, will activate the Boot ROM chip Enable line (active low). In short, at first power on and/or when addresses FFXxxxx are accessed, the on board RoM is enabled. In fact only reads of that address cause the Ross to output data because you can see that the ZRD(L) line is connected to the active low output Enable control of the RCM.

There is a little bit further to go now before we can leave the ROM. Its active low chip Enable pin is inverted and combined with the 21E (L) (Z80280 Input Buffer Enable control signal) in a further HC32 or-gate, whose output is RDBUFF(L). If you refer to diagram sheet 2 you will see that RDBUFF(L) is the control for the data bus read buffer. Thus this follows the ZIE (L) signal, allowing data reads from the system bus except when the Boot Row is enabled, ie at first power on, or a E any time when address FFXxxx is selected, the read operation receives data from the Boot ROM, not the system bus.

So much for the Boot ROM. We now turn our attention to the circuit which deals with the addresses FExxxx (which you will remember represent the 64K which is chosen to activate the 64K Interak memory cards via the conventional Memory Request line on the bus, all other addresses (16 MByte or so) being accessed via the Extended Memory Request line on the bus).

Most of the work is done in an HC153 dual 4-line to 1 line multiplexer. I am sorry for the obscure use of this chip instead of conventional gating. Its benefit here is that it contains a lot of gates of just the right kind to suit my needs, thus saving space on the finished board, but its outstanding benefit here is that passage of signals through the innards of the HC153 takes much less time than the journey through discrete gates which would perform the same function. (And there isn't much time to spare; the decision on which bus Memory Request line to activate - conventional or extended - has to be taken before the ZMREQ (L) signal which qualifies it. The addresses are issued only marginally before the ZMREQ (L) lines. To ease things a bit I delay the ZMREQ (L) signal by one gate, but it is a close run race.)

The outputs of the HC153 depend on the inputs and the state of the selection inputs 50 and 51. The required truth table, which is implemented here is as follows:

Address Bus S1 S0 output 2Y output 1Y i.e. MREQ(L) i.e. EMREQ(L) FE0000-FEFFFF 0 0 0 1 FF0000-FFFFFF 0 1 1 0 (neither) 1 0 1 0 (neither) 1 1 1 0

When the outputs have settled, whichever one is active (the conventional or extended memory request) is gated through by ZMREQ(L) in the HC32 gates and buffered on to the system bus.

So much this far in fact could of course easily have been accomplished by discrete gates. However there is a further complication, and that is the refreshing of Dynamic RAM in both the conventional and the extended memory areas. During refresh this both of the two memory request lines need to be activated simultaneously (there is no commotion on the bus as a result of this because of course the Z80280 is wise enough to withhold the read and write strobe signals during refresh.

The ZRFSH (L) signal from the Z80280 is inverted and enters the two (active low) enable inputs of the HC153. At refresh time the HC153 outputs are both disabled (they were enabled before in our discussion so far). The output state when the HC153 is disabled is that both outputs are "0" QED.

The remaining circuit on this sheet is the similar one which deals with the extension of the conventional I/O Request Line, by developing an "Extended I/O Request" control line. The conventional I/O Request is activated for 1/0 accesses to addresses in the range 00xx00 to 00:xxFF, and the Extended I/O Request line is activated for the rest, i.e. 01XX00 to FFXXFF (although at the very top of the I/O space, FEXX00 to FFXX00, the Z80280 hides its on-board peripheral addresses, and I/O transactions here are not conducted outside the Z80280.)

The technique is basically similar, but this time as it is eight 0's we are decoding we can take advantage of a gate which does not exist in the old 74LS world. The gate to be used here is an HC 4078, a combined 8 input OR and NOR function. When the top address lines ZA16 to ZA23 are all 0 the INV output of the HC4078 is 0, ultimately activating the conventional I/O Request line on the bus; for all other I/O addresses it is the NONINV output which is 0, ultimately activating the Extended I/O Request line on the bus. The ZIOREQ(L) signal from the Z80280 qualifies the output in the HC32 gates after the output of the HC4078 has settled.

As for the Memory Request lines there is a time when both the normal I/O Request and the Extended I/O Request lines must be activated simultaneously. This is during an interrupt acknowledge - the Z80280 does not issue an address at this time, so the system has no way of knowing which of the two I/O request lines should be activated: was the interrupt from the conventional I/O space, or the Extended I/O space? The solution is, by means of the operation of the 2-input AND gates, HC08, to introduce a signal to force both I/O lines low together, but only during an interrupt acknowledge cycle. This is uniquely identified by the simultaneous activation (by the Z80280) of ZM1 (L) and ZIOREQ (L), therefore it is sufficient to include ZM1 (L) in the HC08 gates on the way to the output.

When ZM1 (L) is high, i.e during normal I/O accesses, the operation of the circuit is as described, but when ZM1 (L) is low both of the bus I/O Request outputs are active (low) if ZIOREQ(L) is also low. Again, the Z80280 is wise enough to avoid the contention on the bus which would result when both I/O Request lines are simultaneously active by withholding the 2RDs(L) read data strobe during an interrupt acknowledge cycle.

******
WARNING.
There is a discrepancy between the timing diagrams for I/O transactions in the two Zilog Publications Preliminary Product specification February 1987, and The Preliminary Technical Manual March 1987. On page 78 of the former, figure 51 "Z80 Bus Read Type Transactions" shows IOREQ(L) active around the time A8-A23 are changing, giving me no safety margin whatever to allow for the delays in my gating. Much more palatable is the diagram on page 12-11 of the Technical Manual: Fig 12-10 "I/O Read Timing". This shows IOREQ(L) becoming active a whole clock cycle later, which gives me plenty of time for my gates to process the which I/O Request bus output decision. Until I can find out from Zilog, or until I can get a Z80280 up and running I shall cross my fingers and assume the true timing is that in the Preliminary Technical Manual.
END of warning
*********

The outputs MREQ(L) EMREQ(L) IOREQ(L) EIOREQ (L) are buffered onto the system bus but buffers shown on sheet 2 of the diagram.

Finally, there is an output IORD(L) produced by the HC32 at the foot of the diagram, having at its input ZIOREQ(L) and ZRD (L). This output goes low for any I/O read (ie INPUT instruction). It is used on the power-on circuit on sheet 4.

Sheet 4. Power on Reset and wait state circuits

Compared with those for the 280, the requirements of the reset input in a Z80280 are quite simple. The Z80 reset was not internally synchronised with its instruction execution cycle, and external hardware had to be added to synchronise a hardware reset with an Ml cycle if the penalty of possible corruption of a row of dynamic RAM data could not be accepted. (once a Dynamic RAM access operation has started it must be allowed to finish completely, otherwise data in a whole row of RAM locations could be spoiled.

Some systems expect to reload everything in entirety from Raw at power on, or after a manual reset. This is perhaps acceptable in an office or home "personal computer", but in a development system like Interak it is not. Many home computers (e.g. the IBM range) get over their reset difficulties by not providing a reset switch at all, but this is rather running away from the problem. If we are to preserve the previous contents of dynamic RAM after a manual reset then the duration of a reset must be kept as short as possible - if reset is sustained for more than a few milliseconds the data in dynamic RAM is put at risk owing to the lack of refresh activity in the Z80280 during reset. In this design the reset is limited to about 50 us by the use of a section of an Hol.23 monostable. A pulse is produced whenever the "B" input rises from logic 0 to logic 1. The "B" input is suitable for a slowly rising waveform such as a capacitor charging through a resistor. The diode ensures rapid discharge of the capacitor even if the power to the computer is interrupted only for a moment. The manual reset button is connected via a 330R resistor to limit the rush of current which would otherwise pass through the switch contacts, possibly reducing the life or quality of the switch connection. (short circuiting a charged capacitor is bad for the capacitor too. We use aluminium types which can stand a bit of abuse, but if you use tantalum, which are inferior in this one respect you definitely shouldn't do it: )

The negative going reset pulse from the HC123 "not-q" output appears on the line labelled RESET(L); refer to sheet 2 of the diagrams to see how this is buffered onto the reset line on the bus, (NRST), via an HCl25 connected as an "open collector" driver.

Output Q of the reset monostable is a positive going pulse, which is delayed slightly (the required figure is at least 2 processor clock cycles) by the resistor and capacitor, and inverted by the HC1 [???]. It then passes through an HC08 2-input AND gate (we shall deal with the other input in a moment) and so on to an HC125 connected as an open collector driver to the wait line on the bus, NWAIT. Thus as the system comes out of the "reset" condition, the wait line NWAIT (and ultimately the wait line to the Z80280 MPM) is held low. This is a special initialisation condition, (see Preliminary Technical Manual chapter 11, 3rd paragraph page 11-1), and allows the Z80280 to begin with data selected by the user loaded into its internal Bus Timing and Initialization Register. The logic states of the 8 data lines ZD0 to ZD7 at this particular moment are copied into the internal register. on this sheet of the diagram we see how this is achieved. A high value resistor is connected to each of the data bus lines and the other end of each resistor can be connected to either +5V or 0V at the user's option, to set up the required initial conditions. Some of these conditions can be altered later by program instructions, but some are fixed at power on, so this is our only chance to alter them if we want something different.

Whilst we are in the area of the wait state circuit I shall just finish describing this, before returning to the power on reset arrangements.

The other half of the monostable type HC123 is shown on the lower part of the diagram. Connected to the "A" input (which is the negative edge trigger input) is an HC08, 2 input AND gate. Two signals are available for input to the HC08, and may be selected by links on the associated 3 pin assemblies: the signals are produced by the circuit on sheet 3 of the circuit diagram; FE (L) corresponds to an access to the original Memory Request area tie 64K Interak mapped at FExxxx) and FF(L) corresponds to an access to the on board ROM.

Of course enthusiasts of the Z80280 will be aware that it is capable of applying wait states under program control, but they are quite coarsely applied over large areas of 8 Megabytes. 64K is (relatively) small and the provision of this hardware circuit will ensure that the occasional need to access the 64K Interak space and the on board Roos will not hold up accesses elsewhere. Once the wait state monostable fires the negative going pulse at the not-Q output passes through the HC08 gate and so on to the line labelled WAIT (L). see sheet 2 of the diagrams to see how this is connected via an HCl25 connected as an open collector driver for the NWAIT system bus line. All we have to describe now is the power-on circuit. At the top right of the diagram is an output PWRON(H) which is taken from the upper one of a pair of 2 input NAND gates (HC00) connected as a cross-coupled bistable. In essence at power on, or reset, PWRON (H) is jammed high, which forces (see sheet 3 of the diagram where we see this signal used) every memory access, regardless of its actual address to be routed to the on board ROM (Boot ROM). Once the Row has taken control and established the desired conditions, memory map, timing etc., the program which is running issues an I/O Read instruction, eg IN A, (0 FFH); this turns off the power on mechanism (ie establishes PWRONIH) to "0") and thenceforth the on board Row appears in the memory map only at its designated address (FFxxxx ).

The cross coupled bistable is set to give a "1" output if its lower input is taken to "0" (provided the other input is "1"). The upper input is taken from the Z80280 master reset input labelled here as ZRST (L). This therefore sets the bistable every time the monostable is triggered, ie at power on, and by the reset switch. The lower input to the bistable is provided by the signal called "IORD(L)" which is derived from an or gate on sheet 3 of the diagrams. This is an HC32 or gate whose output goes low when any I/O read (INPUT) instruction is executed by the processor. Thus as soon as this happens, PWRon (H) becomes logic "0" which marks the conclusion of the power on sequence. All future I/O reads have no further effect, until the system is reset again, either by power on or by manual operation of the reset switch.

Sheet 5: Z80280 "on Chip" Peripherals.

Included inside the Z80280 chip are a number of peripherals, which in Z80 days would have been the subject of other separate integrated circuit designs. Some of these we are likely to use, some less likely.

At the bottom left is the clock circuit. A fundamental mode crystal is used of the required frequency although in the finished design an alternative crystal oscillator module will be permitted. This is in case the frequency does approach the rumoured 50 MHz; the on-chip design of a 50 MHz oscillator may prove difficult (unless Zilog are cleverer than I think they are).

To the top left are the three counter timer channels. Channel 0 has an alternative use as a Global Bus request and Global Bus acknowledge system. We shall disregard this latter use because the use of these would necessitate a total redesign of the Interak system, making it a completely different product; not likely to be greeted with enthusiasm by the owners of the tens of thousands of cards already in circulation. For the time being they will simply be terminated electrically and physically. One suggestion we have received and which is under consideration is to bring these lines to an edge connector on the front side of the card.

The counter timer channels can of course be used by the Z80280 without the need for external connection. There may be some benefit in allowing a track pattern which would allow the three channels to be chained together to make a very long counter.

Below the CTC channels are the DMA (direct memory access) channels. These again would cause quite a bit of alteration to the Interak system if they were to be implemented into the structure. Using these to any marked degree would force the system to be too incompatible with the existing Z80 set up, and much of the charm of the system would be lost. I have not investigated thoroughly, but I would imagine the DMA channels are capable of doing work inside a Z80280 system, without the need for further hardware - a super fast Megabyte Block move facility perhaps?

Finally to the right is the serial in/out channel. This is very simple in that it operates merely with data in and out lines, ie no handshaking or modem control lines are built in. one of the internal counter timer circuits can be used for generating the baud rate (we may have to fiddle the crystal frequency to get the baud rate 100% correct, or we could accept its being a few percent out). A 145406 TTL to and from RS-232 level interface chip will be included. Software handshaking (e.g. Xon/xoff) will be possible, but if hardware handshaking is required we will have to look into the possibility of borrowing some of the lines from the CTC or DMA channels if we can find any which can be set and tested independently.