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
 

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

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