GZ/80-A02 - Zilog Z80 turbo card for Apple II computers

Project Status: 

A new version of this project is available here

gz80The Microsoft Softcard was the first card to allow CP/M software to run on the Apple II. It was originally developed to simplify the porting of Microsoft Basic to the Apple II. It turned out to be a great success and at some point in time it was the most popular CP/M platform in use.
This success prompted the development of many compatible cards. Some exact copies, some enhanced or cost reduced. The GZ/80 is a modern implementation of a Softcard compatible card with an additional turbo mode with approximately double the speed of the original card.

MS SoftCard
During the development of the card we studied the original Microsoft schematics, the Applied engineering AZ-80 plus and the ALS Z-Engine. The GZ/80 implements the same subset of functionality implemented in the AE AZ-80 and the ALS Z-Engine.
This is equivalent to the original Microsoft Softcard with all the dip switches in the default configuration (Address translation enabled, no Z-80 interrupts, no DMA). There is virtually no loss AE Z 80 plusin actual functionality as none of these features were ever implemented in any of the Apple II CP/M versions.
The Microsoft Softcard is designed completely using standard TTL logic chips. This made it very easy to reverse engineer and fully understand the circuit. Schematics were also provided in the SoftCard manual. The AE Z-80 plus removes most of the unused features (ability to disable address translation and DMA support). Z-80 interrupts are supported by adding a solder bridge. This simplification and the implementation of address translation using a 256 bytes PROM instead of discrete logic reduced the total chip count from 17 to 11.
ALS Z EngineThe Z-Engine further refines the design by using 2 PALs to bring down the total chip count to 9.

In all SoftCard compatible cards the Z-80 uses the Apple II main memory for all processing. The Z-80 clock runs only during PH1 so no Z-80 wait states are required. The GZ/80 follows the same in "normal" mode. In turbo mode the Z-80 clock runs constantly and the Z-80 WAIT# signal is used to synchronize the Z-80 memory accesses to the Apple II bus.
The GZ/80-A02 schematics is heavily based on the GZ/80-A01. The most obvious changes are the Z-80 clock generation (U5A, U5B, U4A, U4C and U4D) and the transparent data latch U7. The clock in the A01 board is exactly the same shape as A00 but it is 142ns earlier (one 7MHz beat). The earlier clock and the transparent latch are required to ensure sufficient timing in turbo mode.
The clock distribution was modified to reduce the numbers of buffers required without affecting the functionality.
The rest of the schematics is practically unchanged from the earlier version.
The Z-80 is connected to the Apple II address and data bus using 3 octal tri state buffers (U6, U8, U9). The 74LS245 bi-directonal buffer was used because the pinout is a better match for the design vs. the uni-directional 74LS244. The gate U4B buffer the clocks for distribution on the card. The dual D-FlipFlop U13 is used to turn the card on and off. The GAL U2 perform the address translation and generates the remaining control signals. The GAL U3 contains the logic to generate the Z-80 WAIT# signal in turbo mode.

Card Testing

We tested the GZ/80 using many versions of CP/M and all worked as expected. On the IIgs it is necessary to set the slot where the card is placed to "own card". With the new A01 it is no longer required to put the system in "slow" mode.
Our team particularly liked the AE CP/AM 5.1.1 as on a IIgs it allows to boot and operate exclusively on 3 1/2" floppies. CP/AM also seems to support smartport based hard drives, but we did not have enough time to test this functionality.

CP/M Version Test Result Comments
Microsoft CP/M 2.20B OK  
Microsoft CP/M 2.23 OK  
AE CP/AM 4.0 OK  
AE CP/AM 5.1 OK Could not get 3 1/2" to work
AE CP/AM 5.1.1 OK 3 1/2" works

GZ 80 in a IIgsAE CP AM

Turbo Mode

Analyzing the bus timing of the Z-80 and the Apple II it becomes evident that the Z-80 could run faster than the 2MHz of the original SoftCard. The GAL U3 takes care of generating the additional control signals to support faster Z-80 speeds. For the faster clock the obvious choice was to use the 7MHz clock already present on the apple II bus. Because the memory access are limited to 1MHz the effective speed is usually around 4MHz (which is slightly less than double the SoftCard).
In addition the higher Z-80 speed does not allow enough time for 6502 refresh cycles preventing the card from working on Apple systems equipped with the NMOS 6502. Only systems with a CMOS 65C02 or a 65C816 work properly in this configuration.
Turbo Mode is enabled by inserting the jumper J1.

JP1 Mode HGR.BAS execution time (mm:ss)
2-3 2MHz (original softcard timing) 1:59
off 2MHz (enhanced timing compatible with IIgs fast mode) 1:59
1-2 7MHz (turbo mode) 1:06

basic programbasic output

Design Files
Filed under: 


Dear GG,
Very nice project! Thank you for te etailed description too.

Sorry for being a little off topic, I came from 8bit Commodore world, plus/4.
I always had the feeling, that on the 6502 based machines CP/M (as a more "serious" opsystem) with serious SWs can do the magic. Wordstar, Supercalc, dBase, Turbo Pascal, they were all super hi-tech for us kids in the early 90s, could be run (AFAIK) on the PCs, XTs (OK, GEOS was a kind of nice answer on C64, C128, AppleII, even on Plus/4, but only with a LOT of RAM, and still the speed...)
Jump: Going into the very details of CP/M cards for me it looks, that the shared memory usage killed the useability in almost all the cases the CP/M implementations, namely the speed of the Z80. (BTW this is the first time I see any graphics test on any CP/M card, all of them were text only applications, congrats! Unfortunately I could not read the BASIC program, wanted to make a benchmark on Plus/4 BASIC to compare the speed).
Some examples:
The CP/M of the C64 crashes very frequently. The built-in Z80 of the C128 runs effectively only at <2Mhz speed (due to CPU, VIC-II and Z80 shared timing, VDC chip control via 8502 BIOS), despite it is being clocked at 4MHz.
Unfortunately I see the same in this project, however hats off for the TTL reverse engineering and even implementing 7MHz Z80 (unfortunately the speed-up is not that much, 30% increase with 250% increase of the CPU frequency). It is not a critique, just want to share with yo some ideas. I am not a HW expert, just a dreamer :-)

Thinking about the matter (for me a long time dream was to develop az eZ80 based external card in Z80 compatible 8bit mode, @50MHz, like a Z80 @150MHz!), the shared memory stuff seems hampering all those efforts.
On the other hand I saw some interesting (old) project, that may let the Z80 work full speed, and able to reach the memory at full speed, and the 6502 and the video display does not take cycles (expect wait cycles from the Z80).
For the Commodore PETs there is an interesing CP/M machine (with even HDD), that ustilized only the keyboard and the display of the PET, forcing it to be a terminal, communicating via IEEE-488 parallel port. So on the PET running a small assembly PRG, taking the display bytes from the Z80, and sending keyboard presses back.
Called SSE Softbox,

Also on Commodore Plus/4 there is an interesting HW project. It is not available yet, but can play full screen colorful video files. It does NOT mind the memory refreshes, just put into the memory from CF card (as a ROM) a certain block of data, typically 2 full screens. The CPU and the display units does not wait to be synchronize, just read out and show what is on the memory address. It is like a kind of DMA. Because none of them want to write at the same time (simulating a ROM), so one is just writing, the other is just reading it, it generates no conflict (as I understood). Detailed descrition here:

So why I put all these? I saw you spent a lot of time speeding up your card, but blocked by the memory bus, and CPU card is a no go (would really limit the use of the card).
Maybe the above two methods together (communicate via the standard protocol, and clone the text of gfx screen to the required memory address and let the AppleII just show what is there) + Z8 with own memory and speed could be a solution? But I do not know AppleII platform, and just chit-chatting here :-)

Thank you for reading all these text :-D

Bye: MMS