Kaypro 4/83 Floppy Disk Woes.....

I have written in earlier posts of my project to interface the FreHD hard disk emulator to my Kaypro 4/83.  

The standard Kaypro ROM does not include hard disk support so a third party ROM is required, the most common being KayPlus from MicroCode Consulting or the Advent TurboROM from Plu*Perfect Systems.  

The initial project work was done using KayPlus because there was no known source for the Advent TurboROM compatible with the Kaypro 4/83 (the version for the 4/84 was readily available but the two machines are sufficiently different that it can not be used).  The KayPlus ROM worked but there were a few odd behaviours running some CP/M applications that needed further investigation.

In May 2014 a Kaypro II was purchased from eBay by phorgen on the Vintage Computer Forum that included the rare '83 version of the Advent TurboROM and phogren was generous enough to share a copy of the ROM to help with this project.

Between June and September 2014 the Kaypro sat untouched while "real life" got in the way and I finally got back to it on October.

Working with FrankS (also of Vintage Computer Forum fame) we got the 4/83 + FreHD to boot using the Advent TurboROM (details will be included in a future post) but I had problems reading and writing floppy disks.  

The initial symptoms where that Advent CP/M would not recognize standard Kaypro format floppy disks.  Nor would it read a disk that it just formatted.  

My initial thoughts were that the Advent ROM was not compatible in some way with the KayPro 4/83 so I swapped back to the standard Kaypro ROM.  That wouldn't boot either.

Now suspecting the floppy drive I tried a number of different drives and none would read a disk.  

Finally after closely watching the drive while formatting a new disk I realized that the heads were not stepping even though the formatting program was counting up the tracks.

Given that track stepping is directly controlled by the Western Digital WD-1793 Floppy Disk controller, I replaced the Kaypro WD-1793 with a known good part from a TRS-80 Model 3

The known good WD-1793 worked fine in the Kaypro which was a big relief.  Not sure if it was old age or caused by my handling of the Kaypro PCB but at least now I knew what to replace.

On eBay I learned a few things about the WD-1793 (or FD-1793).

  • The WD-1793 (or FD-1793) is expensive.  
  • They are also frequently described as "collectible" or "super rare" which doesn't inspire confidence that a working part will be had for the money.  
  • The Soviets made a compatible part called a KR1818VG93.  This was even more expensive and collectible.  They may also be metric pin spacing so even if a working part was obtained it wouldn't fit well into a Kaypro socket.
  • Mitsubishi made a compatible part called a M5W1793 which were readily available as NOS parts from China at a much better price. 

The M5W1793 seller (no relationship.... just a satisfied customer) had good eBay feedback so I ordered 2 units hoping they would be genuine.

Two weeks later (very quick.... normally it takes 3-4 weeks from China to New Zealand) and the parts had arrived when installed in the Kaypro worked perfectly.  

 

 

The Model 3 can have it's FD-1793 back.

 

 

GPS Connection to Hans Summers Ultimate 3 QRSS Kit

A few years back I built a QRSS transmitter (for slow morse and WSPR) based on a recycled DLink DSL-502T router running OpenWRT and connected to an Si570 DDS module. (http://www.quicktrip.co.nz/jaqblog/home/44-si570qrss)

This worked well for a while but eventually the DSL-502T failed and would no longer connect to the network.  Not great for a time synchronized QRSS transmitter that relied on NTP service.

The replacement is a Hans Summers Ultimate 3 QRSS kit.  (http://www.hanssummers.com/ultimate3.html).  The Ultimate 3 is a combination microcontroller and AD9850 DDS module that if connected to a GPS providing 1PPS and $GPRMC NMEA sentences will generate time synchronized messages in a number of formats with no requirement for network connectivity.

In my parts bin I had several Ashtech g8 GPS modules.  The Ashtech g8 is a late 1990's GPS module designed for integration into OEM equipment.  I picked up a several at an Amateur Radio junk sale a few years back and hadn't really put them to use.

The g8 meets the requirements for the Ultimate 3 by providing the required 1PPS signal and $GPRMC sentence.  Unfortunately the default configuration on power up does not send $GPRMC and instead sends $GPGGA and $GPVTG at 4800 baud.  The startup configuration can be changed by connecting via the serial interface, changing the configuration and saving to backup memory but to retain this (and the GPS almanac for fast power on) when the power is cycled requires a 2.7v-5.5v power source on the V_BACKUP line.

With fast startup not critical for this application and not wanting to worry about backup batteries going flat, I decided to go with a different approach and use a microcontroller to reconfigure the g8 on power up.  

With a number of other applications for GPS in the shack I also decided to buffer the 1PPS and Serial outputs of the g8 and make these available for use other than the Ultimate 3.  This is done using a standard 74LS buffer.  More on this in the next article.

The GPS configuration is handled by an AVR ATTiny2313A with the code written in C using AVRStudio with the compiled code using 508 bytes (28%) of the available flash memory.

The approach is as follows:

  • Wait 5 seconds on startup for things to settle
  • Start receiving serial data from the GPS at 4800 baud looking for 0x0D, 0x0A,$ indicating the GPS is in the default configuration sending data at 4800 baud
  • Configure the GPS to send data at 9600 baud using the command $PASHS,SPD,A,5
  • Start receiving serial data from the GPS at 9600 baud looking for 0x0D, 0x0A,$ indicating the GPS speed configuration command worked correctly
  • Configure the GPS to stop sending $GPGGA and $GPVYG (actually stop all data) using the command $PASHS,NME,ALL,A,OFF
  • Configure the GPS to start sending $GPRMC using the command $PASHS,NME,RMC,A,ON
  • Sleep

I have included the code here should it be useful for anyone wanting to perform similar configuration but note that your GPS may require different commands.

 

ATTiny2313A and 74LS buffer.  The ATTiny2313A can be run from an internal oscillator with no external crystal and capacitors required but they were already on the board after an aborted attempt to get C code to run correctly on old AT90S2313 parts from the junk box.  The LED's are for debugging and indicate the current state machine step.

Alternate view showing the Ultimate 3 and the g8 GPS module.

 

TRS80 Model 4P FreHD Installation

Following on from the post about the Model 4 FreHD installation, here are a few pictures showing the installation of a FreHD Hard Disk Emulator in my TRS-80 Model 4P.

The mounting chassis is the frame from a dead Miniscribe 8425 hard drive.  The FreHD is mounted on a piece of plastic attached in the drive frame.

The FreHD is connected to the Model 4P expansion connector with a long 50 way ribbon cable.  Installation required a lot more disassembly of the machine than for the Model 4. The ribbon cable routes from the expansion connector across the 4P motherboard and comes out at the front of the chassis (but inside the plastic case) before it can get into the drive bay.

An SD Card extender (available on eBay) was used to make the SD Card accessible outside the Model 4P case. In this installation the SD Card socket is accessible in the modem port bay at the back of the 4P.

 

 

FreHD in recycled Miniscribe Drive Chassis

4P front view replacing a 5.25" Floppy

4P rear view showing SD Card slot and expansion cable

 

 

TRS80 Model 4 Internal FreHD Install

A few pictures showing the installation of a FreHD Hard Disk Emulator in one of my TRS-80 Model 4's.

The mounting chassis is the frame from a dead Seagate ST4766N hard drive.  I picked up a box of these in the early 2000's and that sat in the corner of the workshop waiting for a project just like this.  The FreHD is mounted on a piece of plastic attached in the drive frame.

The FreHD is connected to the Model 4 expansion connector with a long 50 way ribbon cable.  Installation required removal of the Model 4 PCB so the ribbon cable could be routed between the PCB and the metal chassis frame.  The cable comes out at the top of the Model 4 chassis and then attaches to the connector on the FreHD.

An SD Card extender (available on eBay) was used to make the SD Card accessible outside the Model 4 case for the few times I want to change the installed software.  I don't change the software on the cards often so having the SD card accessible from behind the machine rather than from the front isn't really a problem.  The SD Card extenders work well but the FreHD doesn't recognize that the card has been removed and inserted because it relies on a physical switch on the SD Card socket.  Best practice is to power down the machine before changing the SD Card if you use an extender.

FreHD installed in Model 4 Drive Bay. Expansion cable visible.

Alternate view showing SD Card extender cable

Not as shipped from the factory but a tidy installation

 

 

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




 

 

DL11-W SN#1014374 Repair

This board was accessible from the front panel when installed in the PDP11/04 but the values read from the receive and tramsit data registers were not as I expected.

On initial power up the receive data register would report 377 octal and the status register 200 octal.

Receiving a character from the attached terminal would change the data register.

Sending a * from the terminal should load 052 octal in the data register.  This board would display 352.

The board was also inconsistent with some characters not being recognized.

Unlike DL11-W SN#1727869 the UART on this board is a genuine M5303 and is socketed.  There is no service tag on the board so I don't know if this came from the factory socketed or has been replaced in service.

Investigating the board with a logic probe shows that the values displayed on the front panel did match the data out pins on the M5303 UART suggesting a fault with the UART.

The M5303 UART is still available from some eBay vendors (2014) but the prices are quite high.  

An alternative part is the General Instruments AY5-1013A.  There were several vendors for this part (2014) with a wide range of prices (USD3 to USD50).

I ordered two from Bulgaria for USD3.  They both worked well when installed.

The board is now operational and will send and receive characters.

 

DL11-W SN#1727869 Repair

When installed in the PDP11/04 this board caused bits 4, 5 and 8 on the data bus to be set for any Unibus requests. 

The schematic shows that these bits are part of the interrupt vector address.

The "stuck bits" matched the settings for S2-3, S2-6 and S2-8.

Tracking back through the schematic the fault was traced to E63 (7474 flip-flop) that was not clearing correctly leaving /Q low.  E63 was itself not the fault.

The pin 1 gate of E62 (7402 NOR gate) which clears E63 was reading 1.78 volts with no activity when it should be 5v.

Replacing E62 with a new 7402 fixed the problem.

The board is now operational and will send and receive characters.

 

Making ROMs with SRECORD

The Kaypro / FreHD adaptor uses a 28C256 EEPROM chip that contains multiple ROM images.  The active image is controlled by jumpers on the high address lines.
 
The challenge I had while doing the project was how to program the EEPROM with multiple ROM images.
 
The solution was the SRECORD set of utilities and specifically SREC_CAT.
 
The following features of SREC_CAT were used:
  • Generate a HEX file from a binary ROM file
  • Exclude the footer from the HEX file
  • Offset the load addresses in the HEX file
The following Windows command file shows srec_cat generating HEX files from three Kaypro binary ROM file and combining them together in a single HEX file that was programmed into the 28C256.
 
@echo off
echo Make Combined Kaypro ROM
del 81-232.HEX
del KPLUS83.HEX
del TROM34.HEX
srec_cat roms\81-232.ROM -binary -o 81-232.HEX -intel -disable=footer
srec_cat roms\KPLUS83.ROM -binary -offset 0x2000 -o KPLUS83.HEX -intel -disable=footer
srec_cat roms\TROM34.ROM -binary -offset 0x4000 -o TROM34.HEX -intel
copy 81-232.HEX+KPLUS83.HEX+TROM34.HEX TEST.HEX
 
  • «
  •  Start 
  •  Prev 
  •  1 
  •  2 
  •  3 
  •  4 
  •  5 
  •  6 
  •  7 
  •  8 
  •  9 
  •  Next 
  •  End 
  • »


Page 1 of 9

Powered by Easytagcloud v2.1

Contact Andrew Quinn

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