Kaypro / FreHD Adaptor - Part 2

Following on from the post about the development of the Kaypro / FreHD adaptors this post covers the SHIM board that I designed for the Kaypro 4/83 (81-240-n).

Design objectives for the board were as follows:

  • For use in the Kaypro 4/83 (81-240-n) and possibly the Kaypro II - still to be confirmed.
  • Single board solution that provides a TRS-80 Model III/4 style 50 pin bus for connection to the stock TRS-80 FreHD.
  • Selectable between the standard Kaypro ROM (no hard disk support), KayPlus and hopefully Advent TurboROM if we find it for the /83 machines.

The design was assembled on prototyping board for initial testing.  It was a challenge to find pin headers.  The ones I used for the prototype were expensive but also too tall to allow the Kaypro case to be closed with the shim installed.  That had to be worked out for the final version.

The production board schematic and PCB layout were done using Eagle Light. The layout was arranged to fit within the board size limits of this version.

Production of the boards was done by OSHPARK.

I had heard about OSHPARK in episode 149 of The Amp Hour Podcast but until I used the service didn't appreciate how well it worked.

For Eagle users the board files can be directly uploaded.  Just add a credit card and 21 days later three PCB's arrived in New Zealand.

The pin header problem was solved using headers from eBay and offsetting the header that connects to the Kaypro PCB socket from the sockets on the shim where the Z80 and 28C256 EEPROM are installed.

While most signals come from the Z80 and ROM sockets there are two that need to be patched from the Kaypro motherboard.

The standard Kaypro 4/83 (81-240-n) has a 2732 ROM but this is too small for the KayPlus ROM.  Just adding a larger ROM is not enough because the /CS signal to the ROM will be deasserted after address 0x1000 which is the last address in the 2732.  The solution is to connect U60 pins 14 and 15 to the header on the adaptor.  These are combined by the 22V10 GAL to generate the /CS for the 28C256 EEPROM.


If you have a Kaypro 4/83 (81-240-n) and want an adaptor you will need to make it yourself.

The Kaypro is a really nice machine but doesn't have enough community support to make producing these boards for resale viable.

Here are the files you need:

Kaypro 4/83 Adaptor Schematic and PCB (Eagle)

Kaypro 4/83 Adaptor 22V10 GAL

Kaypro 4/83 Adaptor 28C256 EEPROM File

Kaypro II Adaptor 28C256 EEPROM File

FreHD Version 2.14 Firmware


Kaypro / FreHD Adaptor

The thing that struck me when I initially got involved with Fred Vecoven to test the FreHD was the potential for the device to be used on machines other than the TRS-80.  

The FreHD emulates a WD1010 Hard Disk controller + Hard Disk combination.  Western Digital Hard Disk controllers were fairly common in the early 80's with many available as after market additions for the Z80 + CP/M machines of the day.  I definitely recommend reading the archives of "The Computer Journal" and "Micro Cornucopia" to get a feel for how this hardware used.

I have an interest in early 80's business machines so in addition to the TRS-80's I have a Kaypro 4/83 (81-240-n) that I picked up in early 2013 on the local auction site.  The Kaypro worked fine after the standard power supply capacitor replacement and as the TRS-80 side of the FreHD development wound down I started wondering if the FreHD could be made to work with the Kaypro.  

Like most of these projects it takes prompting to get things moving.  For this project it came in a post on the Vintage Computer Forums in late October 2013 by Frank Schieschke asking if his FreHD could be used with his Kaypro 4/84 (81-184-n).

The result by the end of December 2013 was that both Frank and I had the FreHD running with Kaypro 4/83 and 4/84 machines using the Kayplus ROM.  

In the two months that it took to get this going we both learned a lot about the Kaypro machines including:

Which Kaypro models have internal expansion connectors?

1/84, 2/84, 2X/84, 4/84, 4X/84, 10/84 and 12X/84 although we have discovered at not all have the connector actually installed even if they have the position on the main board.

How does the Kaypro ROM and CP/M interact?

To make the most RAM available for running programs the Kaypro CP/M does most IO through routines in the ROM.  It does this by bank switching the lower 32K between RAM and ROM.  

Does the Kaypro CP/M support hard disks?

Kaypro CP/M doesn't use installable hard disk drivers like Montezuma Micro CP/M for the TRS-80 Model 4.  Instead it relies on ROM support for hard disk drives.

Does my Kaypro ROM include hard drive support?

Unless you have a Kaypro 10 then probably not.  You need to install a third party ROM such as Kayplus or the Advent TurboROM.  If the magazines are to be believed even Kaypro 10 users would upgrade to a third party ROM to get the extra flexibility they offered.

We have tested Kayplus on the 4/83 and 4/84 (with the Kaypro II planned for early 2014) and Advent on the 4/84.  So far we have had no luck locating the '83 version of the Advent TurboROM.  If you have a Kaypro with this installed we would love a copy for testing.

I have a 4/83 which has a 4K ROM but the Kayplus '83 ROM file is 8K.  How do I use it?

This was one of our first big questions.  The Kayplus web site isn't really clear on how this works.  After some disassembly with IDAPro to see what it did we just "tried it" using a 2764 EPROM (8K).  The 2764 has 28 pins where as the "normal" 2732 has 24 pins.  As you can see from the picture below the pinouts for the two chips are very similar so making an adaptor for the 2732 socket was practical.  


The adaptor wiring is as follows:

  1. Connect 2764 Pins 28 (VCC), 27 (/P) to 2732 Pin 24 (VCC).
  2. Leave 2764 Pin 26 (NC) disconnected.
  3. Connect 2764 Pin 1 (VPP) to 2764 Pin 14 (VSS).
  4. Connect 2764 Pin 2 (A12) to A12 on the Kaypro Motherboard.

Recommended source for A12 from U60 Pin 1

That was easy but unfortunately it isn't quite enough.  The ROM U47 is enabled when Pin 18 (/CE) is pulled low.  In the 4/83 this is controlled by pin 15 of U60.  

U60 Pin 15 provides /CE for U47 Pin 18

U60, a 74LS138 is a "1 of 8 Decoder".  It's job is to enable the ROM via Pin 15 when A12 and A13 are 0 (memory addresses from 0..4095 / 0x0FFF) and the video memory via Pin 12 when A12 and A13 are 1 (memory addresses above 12288 / 0x3000).  

This works fine for a 4K (4096 bytes) ROM but we need 8K (8192 bytes) for Kayplus '83 so ROM Pin 18 (/CE) needs to remain low for addresses up to 8191 / 0x1FFF.

The solution is to take U60 Pins 15 and 14 and combine these to provide the /CE.

The truth table for this is as follows:

U60 Pin 15 U60 Pin 14 U47 Pin 18
0 1 0
1 0 0
1 1 1
0 0 X (not possible)

The 4/83 (81-240-n) motherboard has an unused "OR" gate on 74LS08 U60 pins 8, 9 and 10.  This was used for the initial testing to combine U60 Pins 15 and 14. 

Frank's early prototype ROM adaptor using an IC Socket


I have a 4/84. Do I have to do all that stuff to get the KayPlus ROM to work?

No.  The good news about the 4/84 (81-184-n) Kaypro model is it has a 2764 ROM on the board.  All you need to do is program a 2764 with the Kayplus (or Advent) firmware.

How do I connect the FreHD to a Kaypro?

The FreHD interface connector is, with the exception of /EXTIOSEL standard Z80 address, data and IO control signals with the same pinout as the TRS80 Model 3 and 4 expansion connector.

Connecting this to a Kaypro depends on the model you have.

This depends on the Kaypro model. 

The '84 machines have an internal expansion connector with all the requied Z80 signals.  There have been reports that some models with what is called the "universal board" may not have a connector fitted.  They may also be missing some of the buffer chips for the normally used with the expansion connector.  While these could be added it may be easier to treat them like an '83.

The '83 machines have no internal expansion connector.  To get access to the required Z80 signals a shim in the Z80 socket is used.  The shim provides access to the required Z80 signals but also adds buffering to the address, data and IO control lines.

Does that mean the Kaypro used the same pin arrangement as the TRS80?

No.  All the required signals are there but the pin arrangement is different.  

To connect the FreHD to a 4/84 (81-184-n) requires a wiring adaptor.

To connect the FreHD is an 4/83 (81-240-n) requires either a shim that provides the standard Kaypro pinout and then a wiring adaptor or a shim that provides a TRS80 compatible pinout.

Andrew's prototype shim for the 4/83 with 8K ROM support and TRS80 BUS Connector

So if I have a shim or wiring adaptor will the Kaypro be able to talk to the FreHD?

Yes... but the standard ROM and utilities will not recognize it as a hard disk drive.  This is because in addition to correctly connecting the signals, it is also required that the FreHD respond to commands at the Kaypro IO port addresses.

Port mapped IO on Z80 based machines like the TRS80 and Kaypro provides 256 different addresses.  Devices such as a hard disk controller use a number of these addresses for specific purposes but will only respond to the addresses they are configured for and ignore others.

The FreHD comes configured to emulate a WD1010 hard disk controller on a TRS-80.  These controllers mapped in the IO block 0xC8...0xCF.  In addition the FreHD adds some "special" registers to support volume management, autoboot, etc in the block 0xC0..0xC7.

The standard hard disk configuration for a Kaypro used a WD1002 based controller mapped in the IO block 0x80..0x87.

IO Port address decoding on the FreHD is handled by the 16V8 GAL (it tells the PIC that there is a request in the block 0xC?) but also by the PIC which looks at the lower 4 address bits when it gets the /PIC_SEL signal from the GAL alerting it to the 0xC? request so it can work out which register is being accessed.

While it would easy to change the 16V8 GAL programming to respond to the 0x8? block it would also require PIC firmware changes... something we were hoping to avoid.

An easy solution was to use an inverter on A6 and A3 to move Kaypro requests in the block 0x80..0x87 to 0xC8..0xCF.  This meant that the FreHD special registers appear in the block 0x88..0x8F.  No real problem but it means special Kaypro versions of utilities such as VHDUTL and IMPORT2 are required.  More about that later.....


Frank's early wiring adaptor and IO address changer for the 4/84

As a first test to validate that the Kaypro and the FreHD were in fact communicating we modified VHDUTL to use the Kaypro address ports.

With this we were able to report the FreHD version, read the directory of the SD Card and display the mounted drive volumes.

A significant step forward in that it validated that at some level the Kaypro and the FreHD could communicate.

The first successfull connection between a Kaypro 4/84 and the FreHD

With a wiring adaptor or shim will my standard TRS-80 spec FreHD work with a Kaypro?

Not quite.  While the VHDUTL test proved that the Kaypro and FreHD are connected and talking it isn't the same as CP/M running and recognizing the FreHD as a hard disk.  This was the next test.

Initial testing was done using the KayPlus ROM and a KayPlus bootable disk.  It seemed to recognize a hard disk but running HDCNFG would hang the FreHD.  More research required.

At this point we discovered after digging through the documentation that the Kaypro Hard Disk drivers expect a WD1002 controller and will configure it for either 512 or 1024 byte sectors.  The standard FreHD 2.13 firmware was written to emulate a Western Digital WD1010 hard disk controller.  While the WD1010 does support 128, 256, 512 and 1024 byte sectors selected using the Sector Size bits of the SDH register, common TRS-80 operating systems use 32 x 256 byte sectors per track so the FreHD 2.13 firmware did not care about the Sector Size bits. 

With assistance from Fred Vecoven we added support for 512 and 1024 byte sectors based on the Sector Size bits of the SDH register.

Also required was a small enhancement to the virtual hard disk file format.  

The FreHD virtual hard disk files implement a format originally developed by Matthew Reed for his emulator called "VHD1".  This format comprises a 256 byte header that defines drive geometry plus the drive data.  This header includes a "sectors per cyclinder" value.  For TRS-80 operating systems that always use 32 sectors per track this is sufficient to calculate the number of heads.  The header does not include any detail on the sector size because TRS-80 operating systems always use 256 byte sectors, presumably for consistency with the floppy disk sector size.

Adding support for selectable sector size required that the head count be added to the header.  We agreed with Matthew Reed that we could use a spare header byte to hold the head count.  

Testing with the updated FreHD firmware was inconsistent.  The 4/83 and Advent ROM worked well but the Kayplus ROM did not.  Some utilities would recognize that a drive was attached but not all.  

Trying to track this down involved disassembling parts of the Kayplus ROM.  ROM code that interacts with the hard disk is fairly easily to identify.  In the Kaypro it uses IO instructions such as IN and OUT that access the ports in the 0x80..0x87 block.

In the disassembly we identified that the KayPlus ROM used a "Test" (0x90) command.  The standard hard disk controller for a Kaypro is the WD1002.  The WD1010 controller commonly used on the TRS-80 does not provide a "Test" command so it was not implemented in the FreHD firmware.  As a result when the Kayplus ROM sent the command to the FreHD it did not get the "no errors" response that it expected.  

Implementing the "Test" command required another small enhancement to the FreHD firmware and once "Test" was implemented both the Kayplus and Advent ROMs worked well and would boot both 4/83 and 4/84 Kaypro from the FreHD.


Kaypro 4/83 and the FreHD running CP/M 2.2


System 80 / FreHD Adaptor

The Dick Smith System 80 was a TRS-80 Model 1 clone that was popular in New Zealand and Australia in the early 1980's.

While the machine was largely software compatible, it is a different hardware design.  This is particularly true for the expansion bus on the back of the machine and the design of the expansion interface.

This difference in expansion design means that the FreHD cannot connect directly to the keyboard or the expansion interface of the System 80.

The TRS-80 Model 1 and the companion 26-1132 Model 1 Hard Disk Adaptor made FreHD connection easy.  The 26-1132 connects to the expansion connector on the left side of the expansion interface.  This expansion connector is a duplicate of the connector on the back of the keyboard with the exception of the dynamic memory refresh signals.

The System 80 expansion interface does not duplicate the keyboard expansion connector for further expansion.  In fact it doesn't provide any externally accessible expansion ports that could be used for a FreHD connection.

What the System 80 Expansion Interface does provide is an internal 50 pin connector that is intended for an optional S-100 bus adaptor.

In the two expansion interfaces I have seen this 50 pin connector is an edge connector socket mounted on the PCB.  The connector pinout is documented in the Video Genie EG-3014 technical manual available from http://www.classic-computers.org.nz/system-80/manuals_expander_EG3014_technical_manual_1981.pdf

The first challenge for a prototype was to connect using this 50 pin connector.  I didn't want to make a board without knowing the final design so created an adaptor for the edge connector socket that provided a pin header connector to the test board.  An old ISA bus parallel port board was sacrificed to provide the edge connector.

On top of the edge connector was soldered a 50 pin header and spacers to ensure the edge connector would insert into the socket and make contact.

The initial attempt at an adaptor board was to build a wiring adaptor. Unlike the Model 1 which combined the Z80 /WR, /RD and /IORQ signals to generate /IN and /OUT (and needed to be seperated back to the standard signals by the 26-1132), the System 80 provides the standard signals so all that was required (or so it seemed) was to match these to a Model III/4 type expansion pinout.

Problem was it didn't work reliably.

After a lot of testing by Ray Whitehurst (a System/80 enthusiest from Australia), head scratching and review of the Expansion Interface schematics we were able to get a reliable adaptor.

In addition to the pin mapping it also required:

  • Termination resistors on the data, address, /IORQ, /RD and /WR lines immediately after the S-100 connector.
  • Following the termination resistors added a 74LS245 buffer on the data lines.

Ray"s First Working Board

Final Prototype with SIP Terminating Resistors

System 80 Expansion Interfaces are very difficult to find in New Zealand.   I am very grateful to Mark Barlow of Techvana for lending me his Expansion Interface and Ray Whitehurst for all the prototype boards he assembled for the FreHD validation.


TRS80 Model 1 Fixup - Part 3

So with a power supply, working power switch, restored Expansion Interface and a suitable case, things were looking good for a quick test of the Model 1 / FreHD adaptor and move on to the next project.

As they say on the billboard advertisements for Tui beer in New Zealand.....

I do however now have a lot better understanding of the WD1771 floppy disk controller and how it is integrated with the Model 1 EI.

For those that like to jump to the end of the book.... the problem was C62 (a 33uf electrolytic capacitor) in the "later revision" EI (not sure how EI's are actually named and probably a different component reference in the early version). Replacing this cured all the boot problems.

The path to discovering this is the interesting bit.

The behavior of the machine was that it would boot "sometimes".... perhaps 10% of the time. It didn't make any difference if it was a boot from power on or pressing reset.  If the boot failed it would just hang with a blank screen.  If it did boot then LDOS would run perfectly but a reset or power recycle and it was back to the "will it boot" problem.

Went through all the basic problem solving steps by changing the following:
1. Floppy drive (both 3.5" and 5.25")
2. Drive cable
3. Keyboard to EI cable
4. WD1771 controller
5. Added a Percom Data Seperator

None of these improved the situation to any extent.

One interesting difference that pushed me down an incorrect path was that sometimes when the boot failed the disk heads would step inwards to the center of the disk and stop when the drive hit the stops.  This made me suspect the 7416 driver that controls the direction and step lines.  I replaced this with a 7406 but it didn't fix the boot problem.  I discovered afterwards that this behavior would only occur with certain WD1771 chips. I have two different types... an original RS part that I got from Ian and some later "1982" NOS WD1771's that I got on eBay.  Only the "1982" versions exhibited the stepping behavior.

Spent some time writing some simple basic programs to test the FDC.  It was with these that I discovered that I could cause a similar problem.  Some requests to the FDC to move to different tracks would not complete and the WD1771 status register would report "busy" until it eventually timed out and the busy flag was cleared.  Further digging with the logic analyzer showed that the WD1771 "Ready" line was being deasserted before the command completed.

In the WD1771 datasheet it says that "Ready" is how the drive tells the controller that it is ready for the next command (such as stepping commands when seeking a track).

In the Model 1 (and possibly the Model 3/4) "Ready" doesn't come from the drive (because mini-floppy drives don't seem to have a concept of "ready") and is generated in the EI.  When a drive is selected by writing to 0x37E0 drive select latch this is loaded into Z47 (a 74LS175 flip flop).  The DS outputs are OR'ed to generate the "Ready" so this will high if any drive is selected.

Because "mini floppy" drives are not intended to run continually Z33 is used to clear Z47 and deselect all drives approximately 2-3 seconds after the drive is selected. Z33 is a 74LS123 and uses R25 and C62 to generate a "delay" during which the drive select is active.  If the drive is not re-selected this will timeout and "Ready" will clear.

As C62 had aged it's value has changed (reduced) so Z33 was timing out early and as far as the WD1771 was concerned the drive had gone off line.

This caused problems at boot because the bootstrap code is pretty simple and didn't expect that it needed to reselect the drives during the process because the C62 would keep the drive selected.  The reason it worked sometimes was just luck and where the heads happened to be from the last failed attempt.

Replacing C62 with a new 33uf Tantalum capacitor ($2.50 at Jaycar in New Zealand) fixed the problem and all disks I have now boot.


The offending C62....

... and it's replacement.


Page 9 of 29

Powered by Easytagcloud v2.1

Contact Andrew Quinn

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