Computer Specialists Ltd - CS-16/64 Single Board Computer

A while back I was given a Z80 single board computer by Keith (ZL1BQE) when he found out that I really liked the Z80 microprocessor.

The board was made in New Zealand by Computer Specialists Ltd and sold as a "controller".  Apparantly it was also sold as a basis for a complete Z80 machine with a disk controller and could run CP/M.

I don't know the history of this particular board.  There are hand written comments on the documentation about "Pye TV's" and "Sheraton Rotorua" and I had an email discussion with Mark Eaton at Compuspec (the manufacturer still exists) and he said some of these boards were used to drive information screens in hotels.

I only have the main PCB (not the video or disk controller described in the documentation) which had been burgled for a few parts but thanks to the documentation it was actually pretty easy to get going.

It needed a replacement 4.9152 mhz xtal for the STC (AM9513 System Timing Controller).  This is used for the real time clock but more importantly the timing clock for the SIO/0 (Z80 SIO/0 serial IO controller).  Also a clean up around the reset circuit.  Looks like a reset switch or something was removed so the board by someone with a plumbers soldering iron so it wasn't in great shape there.  

The serial level converters needed to be replaced (MC1488 and MC1489) although they may never have been fitted because the serial port CTS pullup resistors were not fitted to the board (more on that below).

It took some digging into the ROM to work out why the CPU seemed to run and the STC was configured to generate the correct SIO clock frequency but nothing appeared in the terminal.

Two things.... the console is actually on port B of the SIO (not directly stated in the documentation although implied by the pinout on the serial header).

Also because the CTS pullup resistors were not fitted.  These pull the CTS lines at the serial connector to +12V which is inverted by the MC1489 to be "active low" for the SIO /CTSA and /CTSB signals. Without the resistors these signals are +5V and the SIO won't transmit anything.

So it works. Monitor ROM and Tiny Basic both run and work as documented.

 

Documentation for the CS-16/64

Technical Manual Schematic for CPU Board Schematic for Video Board Layout for CPU Board Schematic for Memory Board

 

M9301 Repair

The M9301 is a ROM/Terminator board for Unibus PDP11's.  In the PDP11/04 the PROMs on this board provide the boot loader and programmers console code.

The PROMs are mapped into two address blocks starting at 773000 and 765000 respectively.

Using the front panel I was able to read bytes from the 773xxx address block but not 765xxx which caused a "Bus Error".  

Initial testing with a logic probe showed that the Pin 8 of E17 (7420) was not going low when addresses in the 765xxx block were requested.

E17 was replaced and the board retested.

After this the logic probe showed activity on Pin 8 of E17 (7420) but reads to the 765xxx addresses still caused a Bus Error.

The following capture shows the the traces from E17 (7420).  It doesn't show the signal labels but starting from the top they are pins 8,9 (A12),13 (A11), 12 (A10) and 10 (A9).

Notice the "glitch" on pin 8 which is why the logic probe showed activity suggesting that the decoding was correct.  

Pin 9 (A12) is the wrong state for the address 765000.  It should be High (5v) rather than Low (0v).

Tracing this back through the M9301 ended up at E58 (74175 flip flop) on the M7859 controller board for the programmers panel.

The following trace shows the input and output of the A12 signals on E58 (74175) at the point when it is clocked.

You would expect that the Pin 2 matches Pin 0 after the clock and that it would be Low (0v) but instead High (5v) is going to the M7859 Unibus driver input.  

This gets inverted by the M7859 Unibus driver and then inverted twice on the M7859 so Low (0v) ends up at M9301 E17 (74175) Pin 9 when it should be High (5v).

Requests to 773000 work fine because A12 is '1' in that address.  Same for the DL-11W serial boards that live in the IO space around 7775xx.

So there you go... can't trust anything with this machine.  This is the second 74175 I have replaced on the M7859.  

Replacing the 74175 solved the problem and requests to the 765xxx address block now work.

The other unexpected behavior while testing was the high byte was always reading with all bits set.  

Removing the PROMs from their sockets and inserting them again fixed this problem so it was caused by poor socket/PROM contact.  A lot better outcome than the PROM being faulty.  I will replace the 4 sockets to prevent future problems.

 

KY-11LB SN#0416541 Repair

The KY-11LB Programmers Panel had been working well and being critical to testing the various boards in the PDP-11/04 it was disappointing to power it up and find the 7 segment displays not updating correctly.

The left most (most significant) digit was very bright and all the other digits very dim.  The digits did show the correct values entered on the keypad.

The display is multiplexed using control signals from the M7859 control board.  The issue with the left digit suggested that the drive control line was permanently "on" rather than cycling.

This was confirmed with a logic probe that showed no activity on E7 (7417) Pins 12 and 13.  E7 is on the front panel board and driven from E72 (7417) on the M7859.  Pins 8 and 9 on E72 also showed no activity.

 

Tracking back through the schematic showed E72 being driven by pin 6 of E57 (74175 Flip Flop).   Activity on pin 5 (D) of E57 was reflected on Pin 7 (Q) but not Pin 6 (/Q).

Replacing E57 (74175) fixed the problem and the display is back to normal.  

All that remains to complete the KY-11LB is replacing one of the HP-5082-7730 7 segment displays which has a faulty segment.

 

Kaypro / FreHD Adaptor - Part 3

A friend from out of town was visiting so he was able to being his Kaypro II with him to we could try the Kaypro '83 FreHD SHIM adaptor.

The physical arrangement of the Kaypro II PCB (81-110-n) is very similar to the 4/83 (81-240-n) so the SHIM does physically fit.

Interestingly this Kaypro II is fully socketed so I needed to add a spacer to ensure the shim would fully clear the other chips.  I used the same machine SIL strips that I use as sockets for the ROM and Z80.  Inserting these between the SHIM and the PCB sockets worked. The higher socketed chips were well cleared and the case would still close!

Kaypro FreHD SHIM installed in a Kaypro II (81-110n)

SHIM with FreHD attached

CP/M running from the FreHD

I discovered two changes required to the SHIM to work with the Kaypro II.

The Kaypro II has a 2716 EPROM (v 2732 on the 4/83).
Pin 21 on the 2716 is VPP but on the 2732 it is A11.  The Kaypro II PCB pulls pin 21 to VCC.  Not good for ensuring the ROM is addressed properly because the SHIM expects pin 21 to be A11.
This was easy enough to handle.  I just removed the pin on the SHIM and routed A11 directly from the Z80.

With that sorted the stock ROM would boot but Kayplus reported "ROM Error".

I had seen this in the ROM when I disassembled it during the SHIM development.  The ROM does a checksum so "ROM Error" was because the full 8K was not being addressed.

This is because U60 (74LS138) on the Kaypro II has A11, A12 and A13 as inputs.
On the 4/83 only A12 and A13 are used with the unused input tied to VSS.
Also different is the sequencing of the address lines to the U60 inputs.
On the Kaypro II it is A11 (A), A12 (B) and A13 (C).  On the 4/83 it is A12 (A), A13 (B), VSS (C).
 

To access the full 8K I needed to connect U60 pin 13 (in addition to Pins 14 and 15) to the GAL and make a small change to the equations to generate the /OE signal for the larger ROM.

Good thing the SHIM uses a 22V10 GAL and had a couple of spare pins.

Kaypro II (81-110-n) ROM Address Decoding

Kaypro 4/83 (81-240-n) ROM Address Decoding




 

 


Page 7 of 29

Powered by Easytagcloud v2.1

Contact Andrew Quinn

jaquinn@ihug.co.nz http://twitter.com/jaquinn