TRS-80 Model 1 FreHD Expansion Interface

Fred Vecoven's FreHD Hard Disk emulator has been a very popular upgrade for TRS-80 Model 3 and 4 users since it's launch in 2014.
 
If you have a Model 1 with a Radio Shack expansion interface then you can use the FreHD using the Model 1 adaptor board.  This includes autoboot support if you are happy disassembling your keyboard to update the ROM... but stock 16K Model 1 owners didn't have an option unless they could find a Radio Shack Expansion Interface.
 
The Model 1 FreHD Expansion Interface removes the requirement for the Radio Shack Expansion Interface and FreHD Autoboot ROM replacement on a stock 16K Model 1.
 
The small board adds 32K RAM (bringing the total Model 1 RAM to 48K), an optional EPROM mapped to the empty address block at 0x3000 (for hackers who want to put something into this address block... such as the Z80 Monitor from the Dick Smith System/80 Blue Label) and a PIC microcontroller.
 
The PIC emulates just enough of a WD1771 Floppy Disk controller so the standard Level II ROM sees a controller and requests the 256 byte boot sector.  The boot sector checks a FreHD is connected and if found and running firmware with autoboot support (2.13 or later) will load the loads the FreHD autoboot menu.
 
The prototype was built on prototype board using point to point wiring.  It proved that the design worked but was only reproducable by the most dedicated hardware hackers.
 

 
This short Youtube video describes the prototype.

 
The production board was created using the Eagle Light Edition with the board just fitting within the 100 x 80mm size limit.

What parts to do I need to build one?
 
  • 1 x PCB
  • 4 x 74LS245 Octal Bus Transceiver (IC1,IC2,IC3,IC4)
  • 1 x 62256 32K Static RAM (IC5)
  • 1 x 28C16 EEPROM (IC6 - Optional)
  • 1 x 22V10 GAL (IC7)
  • 1 x 18F13K22 (IC8)
  • 8 x 0.1uf Ceramic Caps (C1,C2,C3,C4,C5,C6,C7,C8)
  • 1 x 100uf Electrolytic Cap (C9)
  • 2 x 2N3904 or PN2222A Transistors (Q1,Q2)
  • 2 x 1K Resistors (R1,R2)
  • 1 x 2x20 Pin Header (JP1)
  • 1 x 2x25 Pin Header (JP2)
  • 2 x 2 Pin Header (JP3, JP4)
 
How does it work?

  • IC1, IC2, IC3 and IC4 buffer the signals between the TRS-80 and the expansion board and FreHD.  
  • IC1 and IC2 buffer the address bus.  These signals are always one direction... from the TRS-80.
  • IC3 buffers the TRS-80 /IN, /OUT, /WR and /RD signals.  These signals are always one direction... from the TRS-80.
  • IC4 buffers the data bus.  This is bi-directional.
  • IC5 adds 32K of RAM.
  • IC6 adds 1.5K of ROM starting at 0x3000.
  • IC7 selects IC5 and IC6 when the TRS-80 reads and writes memory above 0x8000 (IC5) or in the block starting at 0x3000 (IC6).  It also selects IC8 when the TRS-80 reads and writes to the floppy disk controller (0x37EC, 0x37ED, 0x37EE, 0x37EF).  When reading from the onboard devices (IC5,IC6, IC8) or the FreHD, IC7 will control the direction of IC4 to push data back onto the TRS-80 bus.  It also generates the /IORQ signal for the FreHD from the TRS-80 /IN and /OUT signals.
  • IC8 runs code that emulates a WD1771 floppy disk controller and provides the 256 boot sector.
  • Both the FreHD and IC8 rely on asserting /WAIT to the TRS-80.  Q1 and Q2 operate as an AND gate to allow either device to asset /WAIT by pulling their own /WAIT lines to ground.
 
Is there a kit available?
Not yet but the design files are available at the link below. This includes the programming files for IC7 and IC8 along with the Eagle Light files for the schematic and PCB.
 
If you would prefer either a complete kit, a partial (PCB + IC7 + IC8) kit or fully assembled unit get in touch with Ian Mavric at http://ianmav.customer.netspace.net.au/trs80/ and let him know you are interested. If there is enough interest we will put something together.
 
Design Files
 

MS11-JP MOS Memory SN#1958348/78

The MS11-JP (M7847-DJ) is a MOS memory board for Unibus PDP11's. In the PDP11/04 I am restoring there are two fully populated boards, each with 32K words of dynamic memory.... and neither board works when accessed from the front panel.

The first board I worked on is SN#1958348/78.

Using the front panel the board did respond to read and write requests to RAM in the assigned memory block but reading data did not show the value that had just been written.  This behaviour was consistent at any address I tested.

The voltages (+5v, -5v and +12v) were correct on the dynamic RAM chips so I used a logic probe to check for activity on the dynamic RAM chips with both no front panel activity and when reading and writing to memory.  

When not attempting to access the memory using the front panel there was activity on CAS (Column Address Strobe) and RAS (Row Address Strobe) which suggested that the refresh circuit was doing something and may even be working.

Attempting to write to memory from the front panel showed activity on WR (Write) which was also expected.

What I did not see was activity on CS (Chip Select).  If CS does not go low then the chips are not selected which means the write does nothing and the read shows random data from the Unibus.

 

Working backwards from CS through the schematic shows that CS is generated by a 7440 NAND Buffer (E114).  I could see activity on the input (pins 9,10,12 and 13) but no activity on output (pin 8).

Replacing E114 with a "new" 7440 sourced from eBay (with what appears to be a 1973 date code) fixed the problem.  It is now possible to write data to RAM and read it back.  I haven't done a full RAM test yet and can't do this until I get the processor board operational.  

These notes are written with the benefit of having solved the problem. The MS11 memory board is a lot more complex than I am used to in microcomputers.  It has it's own refresh circuit independant of the processor that identifies and gives priority to processor requests.  There are also circuits for address mapping (configurable) and Unibus bus interfacing so a lot of time was spent trying to understand how the board worked.  The EK-MS11E-OP-001_Oct76 and MP00019_1104_EngrDrws_Feb78 documents were invaluable in understanding the board and eventually fixing it.

The other MS11 does not exhibit the same symptoms.  Attempts to access the board give a Bus Error.  Initial indications are that the issue is in the refresh generation circuit.  We will see.....

 

 

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.

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