; Article on CPU280 for TCJ ; 16. September 1991, Tilmann Reh ; 06. October 1998: revised for Thomas Scherrer The History When Zilog first introduced the Z800 MPU in their 1983/84 data book, I was working with a homebrew Z80 system, based on ECB-bus EuroCards (a well-established standard here in europe these days). My system was running with the usual 4 MHz clock, but my CP/M-3 (CP/M-Plus) BIOS already had some very nice advantages. For example, I had developed the AutoFormat system, a technique which supports various different disk formats without manual work. The basic principle is the same as MS-DOS uses: the disk contains a parameter block which holds all information nessessary to process it. Another feature was the automatic installation and adaption of some different hardware equipments. As some people around here had similar machines, none of them had to install hardware parameters (as long as they didn't need very special things). When I had a look at the 'preliminary' specifications of the Z800, I began thinking about some performance improvement on my system. So I waited for this chip to become available. I was still waiting, when in 1985 Hitachi's HD 64180 suddenly appeared. This processor had much of the Z800, but it was really available! So I gave up waiting any longer and developed a 64180-based single board computer. It had the 64180 MPU (with both serial channels used), 32 KB EPROM and 512 KB DRAM, a 765 type floppy controller for up to four drives, and an ECB bus interface on an EuroCard. The clock frequency was 9.216 MHz, which made an effective Z80 speed of about 11 to 12 MHz. Since the ECB bus cannot handle these frequencies, the bus clock was only half the CPU clock (4.6 MHz), with timing signals stretched to meet standard Z80 peripheral conditions. When changing my system to the new 'CPU180', it replaced three of the older boards: the CPU, the memory and the floppy controller board. The new single-board design brought the advantage of direct access to all basic I/O, so the BIOS could rely on these basics and use them. So the CP/M-3 implentation I wrote for that system was more comfortable than the former Z80 multi-board version (for example, it introduced automatic disk exchange recognition). The high processor performance was amazing, comparing assemble/compile times to the 4 MHz Z80. Then came the IBM-PC's. In that time, CP/M was systematically forced to death here in europe. The special german computer syndrom became 'it has to be always the newest, biggest and fastest machine', and the computer magazines followed that slogan. So after a while, I was the only one around here who was still active with CP/M. That was the reason why the CPU180 was built exactly once: I was working with the prototype board, and noone else seemed to be interested. At the end of 1988 Uwe Herczeg, another 'lone CP/M user' in germany, placed an ad in a great computer magazine, searching for other CP/M users. This brought the remaining activists together. But, most of them were still using 4 or 6 MHz Z80 systems, often also based on ECB-bus EuroCards, and some were very interested in my CPU180 system. So we began thinking about a redesign of that board, with actual technology and some enhancements. Then one of those new friends suggested to take the Z280 instead of the Z180. Z280? I ordered the data sheet and had a look at the late incarnation of the old Z800 idea. Unbelievable but true, the Z280 was really available! So we decided to take the Z280, for this CPU has a far more powerful instruction set than the Z180. The Hardware Design Basics and Memory As the hard- and software concept of the CPU180 had proved very well, all basic principles were also taken into the CPU280 design. As it was with the CPU180, the design rule of highest priority was to get the absolutely maximum performance out of the MPU with the absolutely minimum circuit expense and parts cost. Concerning the PCB technique, that means the use of a standard double-sided PCB (no multi-layer) with normal wire thickness (.25 mm), and no SMD parts at all. Just the good old sort of computer boards, reliable and with easy maintaining. In order to get the full power of the Z280, it must be run in the 16-bit Z-bus mode, with cache and burst-mode enabled, and no RAM wait states, with the highest possible clock frequency (12.5 MHz). These are the demandments concerning the memory interface. All memory on board is 16 bit wide. Main memory is built with dynamic RAM. There are eight sockets for 1 M-bit or 4 M-bit chips (with 4 bit data width), of which at least four must be used (to fit the 16-bit data bus). So the possible memory capacities are 512 KB and 1, 2 or 4 MB. This direct accessable memory should be enough for the very most circumstances; the standard configuration is with eight 1 M-bit chips (1 MB total). For space saving purposes and the availability of exactly pin-compatible 1/4 M-bit memory chips, ZIP-cased RAM is used. As I made very good experience with synchronous DRAM timing (the CPU180 memory worked absolutely error-free for many years), I built a fully synchronous timing chain for the DRAM's again. This uses a HCT175 as a four-bit shift register and a GAL containing the CAS decoding and selection logic. The DRAM interface also supports the processor's burst mode, increasing the lowest address bits during the burst with a GAL (we can't use nibble-mode RAM's as these are not available with 4-bit width!). The RAM timing is designed to meet all specifications of the Z280 and the RAM's when using 100 ns RAM types at a CPU clock of 12.5 MHz. However, as the prices for 100 ns and 80 ns types are identical, we normally take the latter for safety. Since the memory interface is far too fast for the ECB bus, external memory is not supported. Additional reasons are the data bus width (16 bit vs. 8) and the different timing and status signals (Z-bus vs. Z80). Support of external memory with burst-mode is absolutely impossible, as the ECB bus doesn't have strobing signals which could do that job. Interfacing the fast 16-bit internal data bus to the slow 8-bit ECB bus would need very much circuitry, and that would be against our main design rule. So if someone really needs more than 4 MB RAM, please connect an external I/O-accessed RAM-disk via ECB (DMA support is no problem). The boot software is placed in two 27C256 or 27C512, so the boot capacity is 64 KB or 128 KB. For easy handling, ordinary 28-pin DIP sockets carry the EPROM's. As this memory usually is only needed during boot-up, burst-mode is not supported, and for slower memory chips up to three wait states may be added. The Z280 is able to use different memory timings when accessing the lower or upper half of it's 16 MB address space. So the EPROM is decoded into the lower half (8 MB, what a waste!) and the RAM into the upper half. This way, using the RAM with zero wait-states and burst mode is possible, while the EPROM needs up to three wait-states and doesn't support burst mode. Mapping any desired memory configuration to the CPU's logical 64k address space is done with the PMMU (Paged Memory Managing Unit) internal to the Z280. I/O Basics and Bus Interface For good availability of Z80 peripherals, the ECB bus clock with the according timing signals should not exceed 6 MHz. As the CPU clock frequency is 12.288 MHz (for easy baud rate generation, it should be a multiple of 2.4576 MHz), the best way is to use half the CPU clock for the bus again. This results in a bus clock of 6.144 MHz, for which Z80B or Z80-6 components are specified. With the internal wait-state generator of the Z280 programmed to insert four wait-states every I/O transaction (the maximum value), the duration of the I/O cycles is exactly matching the divided clock. The clock divider is made of a single flip-flop (HCT74), and is reset at the beginning of each transfer to produce the correct phase relationship between bus clock and timing signals. Since the Z-bus control & timing signals cannot be used for the ECB bus, they are converted into the appropriate Z80-type signals with a GAL. As the external peripherals could use Z80 type vectored interrupts, the bus interface must be able to generate the correct interrupt acknowledge and RETI timings. Interrupt acknowledge is treated as an I/O transaction and stretched by the Z280, but the RETI instruction consists of two memory cycles which are too fast for the peripherals, not regarding that the memory control signals do not appear on the ECB bus. Last but not least, the Z280 has a new interrupt mode (mode 3) which uses another return instruction (RETIL). So a slow RETI timing can be simulated with special accesses to on-board I/O locations, with a GAL generating the correct signals for the ECB bus. This way, vectored external interrupts are supported, although the clock speeds are very different. The Z280 supports 24-bit I/O addresses as opposed to the 8/16-bit addresses of the Z80. The upper eight I/O address bits are accessed via the 'I/O Page Register' within the MPU. For full access to the 256 I/O addresses which are specified for the ECB bus, the bus interface is decoded to have an I/O page of its own. Another page is used for the on-board I/O, and two pages are reserved for the internal I/O registers of the Z280. Decoding of the I/O pages and addresses is done within GAL's. Internal and On-Board I/O The Z280 comes with a serial interface (UART), three 16-bit counter/timer circuits and four DMA channels on-chip. To avoid an external baud rate generator for the UART, one of the timers is used for that purpose. That is the reason for the clock frequency to be a multiple of 2.4576 MHz - these frequencies allow for standard baud rates up to 38400. Even greater, but non-standard baud rates are also possible. The internal UART is completed with two handshake signals which are not supplied by the MPU. A second serial interface is made of a Twenty-Pin-UART (TPUART) COM81C17 by SMC, which already contains a baud rate generator. Both interfaces are buffered and shifted to RS-232C levels with a 5-V-only line driver and receiver, the LT1134. The CPU280 contains a real-time-clock (RTC) with 50 bytes of nonvolatile RAM, the Dallas DS 1287. Since this part already contains the lithium battery, no external circuitry is required. The RTC is able to generate interrupts at given date and/or time (alarm) or periodically. The NVRAM is ideal for storing something like configuration parameters. Floppy disk I/O is possible using the on-board Floppy Disk Controller (FDC), which is realized using an FDC 37C65 by SMC. This neat chip, cased in a 44-pin PLCC, contains the complete controller. Just connect the CPU bus to some pins and the disk drives to some other (and don't forget the quartz), and everything is running. Floppy related data transfer may be done with one of the DMA channels of the Z280. For general bit-I/O, there are one 6-bit input port and one 8-bit output port on board, both made with simple TTL chips (HCT367, HCT259). One bit of each port is used for the handshake signals of the first RS-232C interface. The other outputs drive some FDC control lines, and three LED's for status display. Some of the inputs are connected to jumpers, so they can be used for configuration purposes. There are four 16V8 type GAL's on the CPU280 board. They contain memory address and CPU state decoding, I/O decoding, RAM timing and CAS decoding, and some 'glue' logic. As nearly all signals are processed with only one logic level, the standard 'slow' 25 ns GAL's are fast enough. The complete circuit of the CPU280 is designed using CMOS technology. The internal logic is made of the 74HCT series, which is fast enough for nearly every signal. The bus interface and the timing-critical functions in the DRAM interface use 74ACT chips. All LSI are also CMOS, and the GAL's should be taken from the 'Q' series (quarter-power). As a result, the complete CPU280 board draws only about 350 mA from a single 5V power supply (when fully operating with maximum clock speed). No other voltages are required. The 32 chips nearly exactly fill the board space of the EuroCard, with just enough space left to avoid a multilayer PCB. As with every good single-boarder, you just need to connect a power supply, at least one disk drive of any kind and size, and a terminal to complete the CP/M-3 workstation. However, by connecting the CPU280 to a standard ECB backplane, you are free to use nearly every available ECB I/O boards. The Software The best hardware doesn't produce anything, unless you got the right software. With this in mind, I adapted my CPU180 BIOS to the CPU280. Now using the powerful instruction set of the Z280, of course. As with the circuit design, the basic priciples and structures of the BIOS were taken directly from the CPU180. However, I completely redefined and enhanced the AutoFormat system and added the menu-driven hardware configuration program to the boot loader (this was impossible with the CPU180 as it had no NVRAM). Of course, some further improvements were made using the experiences of four years of CPU180 operation. Normally, the complete system (boot loader, CCP, BDOS & BIOS) is booted directly out of the EPROM. So you can boot up your machine in two seconds without any noise or mechanical action. (For testing new system versions, of course disk boot is also possible by pressing a button during RAM-test.) With all functional enhancements fully compatible to the CP/M-3 definitions, all CP/M-3 and most of the CP/M-2.2 software can be run on the CPU280 without any problems. By the way, while the operating system is running in the Z280's system mode, all user programs run in user mode. This is mainly to achieve easy bank switching (which the MMU does automatically in this case), but it also increases system security. Unfortunately, CP/M-3 must have the BIOS entry vector and some data structures in common memory, so you cannot absolutely prevent user programs from damaging the system software. But since we don't have any better (and still compatible!) operating system, we have to live with that fact. The Power What is the real performance of a Z280 running with every booster switched on? In fact, the answer is not as clear as you would probably like it to be. First, the Z280 is a pipelined CPU. So you really can't say how many clock cycles any instruction will last - it depends on the last few instructions before. In addition, some instructions (Jumps and Calls, for example) flush the pipeline and thus are relatively 'slow'). Second, effective CPU speed depends on the 'hit quota' of the cache controller. So small loops will run much faster than 'spaghetti code'. Third, the 16-bit arithmetic unit of the Z280 (opposed to the 4-bit one of the Z80) processes indexing and math operations with greater speed gain than other instruction types. So the more a program makes use of these instructions, the greater the effective speed. Although it is impossible to exactly determine the power of the Z280, you can say that with normal 8080 or Z80 software it will have the power of a Z80 running at 16-20 MHz (with 12.288 MHz clock). Of course, using the new instructions (there are more than 600!) further increases the performance (while loosing Z80 compatibility, of course). As I hope the Z280 will be used more and more, perhaps soon there will be the first real Z280 programs or the first real Z280 operating system? (Which also could get rid of the stupid 62 KB TPA border of CP/M-3...) The Experiences After the first version of the CPU280 ran stable in March 1990, I made a redesign of the PCB layout with slight changes in parts of the circuit. In June 1990, I ordered the first series of PCB's, and in November 1990 I sent them along with all semiconductors and special parts to about 25 people here in germany. Few other people around the world did also get a PCB, but not the partset. I had to wait until November because that was the time when the 12.5 MHz version of the Z280 became available, and we didn't like to take the slower version first and upgrade a few month later. Since early 1991, many of the machines are running very well, as far as I'm informed by the users. All of them who are working with the CPU280 have proved it to be very fast and very reliable. Our 'PD and ZCPR Man', Helmut Jungkunz, likes the machine for the flexible method of processing different disk formats, that's why he uses it for nearly all disk distribution he has to do. Of course, he likes the raw power, too. But the CPU280 is not the only project amongst us here in germany. I would like to introduce my next board, an IDE controller which connects standard (PC) AT-Bus harddisks to any ECB bus based CP/M system. The board also contains an active termination of all bus signals, a centronics printer interface, a four-LED power monitor and two system control buttons for reset and NMI (which, with the CPU280, forces a warm system reboot). As you probably agree, this board exactly matches the CPU280 to build a real high-power CP/M workstation. Another project of a friend is a LCD terminal, which in combination with a low-power Z180 single-boarder (a development based on my CPU180) makes a powerful CP/M-3 laptop! My newest project is already growing very well and will produce a high-performance CRT terminal for text and graphics at an unbeatable price. Wait and see. Needless to say that all three of these boards are EuroCard size. These informations are just to keep you informed about our activities in europe, esp. germany. Perhaps I or one of my friends are allowed to describe our further projects in TCJ. ; Current state (06.Oct.1998): There are about 50 CPU280's worldwide. Since I lost contact to many of the owners, I don't know how many are still active with it. I still use the CPU280 at home for text processing and spreadsheets, and also do some arithmetic simulations for business sometimes. Though the Z280 has become obsolete, the CPU280 is still available. I put some CPU chips on stock, and I also have some more PCBs. Additionally, some of the owners have expressed that they would give away their CPU280 if someone else is interested. The system software has been further improved, and there are detailed hard- and software manuals meanwhile (though the software manual does not describe the current version...). Tilmann Reh Siegen, Germany email: tilmann.reh@bigfoot.com