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
 

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.

 

TRS80 Model 1 Fixup - Part 2

Included in Ian's box of "things from the junk box" for FreHD testing was a Model 1 Expansion Interface PCB.


Ian tells me that a common problem is people shipping Expansion Interfaces with the power transformer still inside.  Add an enthusiastic courier driver and you are almost guaranteed to have a broken case. This Expansion Interface had such treatment so had ended up a junk box parts donor.


Apart from the missing case, WD-1771 floppy disk controller and connection cable to the keyboard, the Expansion Interface board looked complete and in good condition.


For anyone who finds a parts donor Expansion Interface board and wants to get it going, as of 2013 the WD-1771 floppy controllers are still available on eBay as are the 4116 dynamic RAM chips.  Best to search around because the prices vary a lot.  Unless you are hung up on period authenticity then the vintage style packaging with the really high prices are not required!


With the chips replaced and a cable made up the initial indications where that the Expansion Interface worked fine.


At this point I realized why they put these in cases... where to put the monitor when you just have a PCB? Things get very spread out.


Taking inspiration from the current trend in acrylic project cases for things like the Raspberry Pi I went looking for a source of acrylic sheet and discovered CTS Plastics in Tauranga.

Here is my solution to the no-case problem.

    2 sheets of 6mm grey perspex plastic

    5 x 50mm bolts, assorted nuts and washers.

Total cost about NZ$25.

 

Much safer than having the EI board floating around on the table, looks smart and with 6mm perspex it is very strong so the monitor can sit on top.

 

The dimensions and drilling information is in the attached pdf for anyone wanting to build their own.

The drill details are:
 
    4 holes (1 at each corner) 20mm from the edges.
 
    2 holes 143mm from the left edge.  One is 82mm from the bottom and the other 202mm.
 
    1 hole 38mm from the right edge.  This is 142mm from the bottom.
 
The two pieces will be mounted together with spacers so the holes need to be accurately drilled on both sheets.

 

 

 

 


 

 
  • «
  •  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