Living Computer Museum - DEC Rainbow 100


Replacing 2708 EPROM with 28C16 EEPROM

Restoring vintage computers is sure to mean dealing with old EPROMs.  

Many restorers have a modern EPROM programmer (i.e it was cheap, made in China and I got it on eBay) or two but there is a very good chance that neither will write (or even read) older parts even if the "supported parts list" suggests they will.

I ran into this problem with the 2708 EPROM on the Northstar ZPB Z80 CPU board.  To debug the machine I needed it to run some known software.

An easy replacement for a 2708 is a 28C16 EEPROM with a home made adaptor.  As shown in the diagram below they are pin compatible for all pins except 18,19 and 21.

The wiring for the adaptor is shown in the 28C16 image.

  • Pin 21 /W is connected to pin 24 VCC.  This ensures it is not connected to the -5V supplied by the 2708 socket and ensures the chip will only be read.
  • Pin 19 A10 is connected to pin 12 VSS.  This ensures it is not connected to the +12V supplied by the 2708 socket and allows only the first 1K of the 28C16 to be read by forcing A10 to always be 0.
  • Pin 18 /E is connected to pin 12 VSS.   On some 2708 sockets this may be omited but on the Northstar ZPB board, wiring like this ensures the 28C16 is always enabled with pin 20 /G latching data on pins DQ0-DQ7.  The 28C16 is low power compared to the 2708 so having the chip always enabled is OK.

I built the adaptor from a small pice of prototype board with offset pin header and pin socket rows.

Adaptor - Top

Adaptor - Bottom

Solder bridges are used to connect pins where no wiring adjustment is required. 

The red wires are the 28C16 wiring adjustments.

Ignore the two blue wires... they are used in place of a solder bridge for pins 8 and 9 because the pads had come off the prototype board!



The Hacker Spirit


Living Computer Museum - Control Data Corporation 6600


Living Computer Museum - DEC PDP-11



The following DECUS NOPSIG posters were produced around 1990.  I was recent given copies in perfect condition so have uploaded them to as TIFF files suitable for reprinting.

Click on each poster for the link.  The text below each poster is written on the back of the originals.

The NOP SIG is dedicated to the retention, restoration and running of Nostalgic, Obsolute Products (NOP's).

Eight generations of PDP-8 computer architecture have come between the PDP-8 of 1965 and the DECmate III of 1985.  The PDP-8 was the original minicomputer that set DEC on the road to fame and fortune. It has been re-implemented every few years in newer technology.

  • 1965 - PDP8
  • 1968 - PDP8/I
  • 1970 - PDP8/E
  • 1974 - PDP8/A
  • 1977 - VT78
  • 1980 - DECmate I
  • 1982 - DECmate II
  • 1985 - DECmate III

This PDP-8 is on display in DEC's Australian museum.  It was sold with 6,14 bytes of mrmory and a teletype for $18,000.  The DECmate III shown has 98,304 bytes of memory, 800,000 bytes of disk and sells for 25% of the above.

No 1 in a series.

The DECUS NOP SIG is dedicated to the retention, restoration and running of Nostalgic Obsolete Products. (NOP's).

Twenty one years of Unix* software is represented here, between the PDP-7 of 1967 and the VAXstation 2000 of 1988.

The PDP-7 was the original computer on which Ritchie and Thompson wrote the UNIX* operating system at Bell Labs in 1967.

The VAXstation 2000 sitting on the butterfly table of the PDP-7 is running the Ultrix operating system.  It is showing 12 windows simultaneously.  This PDP-7, serial No. 60, was the third DEC computer to enter Australia.  It was installed at the Australian Atomic Energy Commission, Lucas Heights, on 27 January, 1966 and run for 14 years, clocking up 111,577 hours.  The PDP-7 was an eighteen bit machine with a cycle time of 1.75 microseconds.  It was notable for the solidity of its construction and for its weight-just over a half a ton!  It sold with 4096 words of memory and a teletype for $45,000. 

The VAXstation 2000 has 500 times the memory and sells for one quarter of that price.  This PDP-7 is on display in DEC's Australian Museum.

No. 2 in a series.

*UNIX is a trademark of Bell Labs

The DECUS NOP SIG is dedicated to the retention, restoration and running of Nostalgic Obsolete Products. (NOP's).

The poster was made by the DECUS NOP SIG to mark the 20th anniversary of the PDP-11 in 1990.

The poster shows three generations of the PDP-11.  On the right are two of the original PDP-11/20 computers mounted in the same cabinet.  The PDP-11/20 was released in 1970.  These units were used by the CSIRO to control an X-RAY diffractometer.  In front is an ASR-33 teletype.  In the middle is the PDP-11E10 of 1973 vintage.  

This was the first "packaged" system ever sold by Digital.  It comprised a PDP-11/10 central processor with 16,192 words of core memory, bootstrap, 2.4 Megabyte cartridge disk, dual magnetic cassettes and LA30 DECwriter console, all installed in a 6 foot cabinet.  This unit also had the LPS laboratory peripheral unit.  The package configuration saved 25% over the sum of the parts.  It was installed at the Preston Institute of Technoloy in 1974.  On the left is the top of the line PDP-11/70 of 1975 with console and expander cabinet.  This PDP-11/70 was the first RSTS/E machine installed in-house by Digital Australia - the famous node SNOE01.  These units are on display in DEC's Australian Museum.

No. 3 in a series.

The DECUS NOP SIG is dedicated to the retention, restoration and running of Nostalgic Obsolete Products. (NOP's).

After it was launched in October 1977, the VAX-11 / 780 quickly became the performance standard against which all following computers were measured.

The VAX-11 / 780 was rated as one VUP (VAX Units of Performance).  Even today, when the industry uses a benchmark known as SPECmarks, (issued by the Systems Performance Evaluation Co-operative), the VAX-11 / 780 is the reference point for one SPECmark.


Northstar Horizon Repair

In mid 2015 I was lucky enough to acquire a Northstar Horizon computer from a fellow collector who was disposing of his equipment.  

After seeing my father work with MDL (MicroProcessor Developments Limited of Pah Road, Auckland, New Zealand) S-100 bus machines at the Auckland University Medical School back in the early 1980's, I had always wanted to restore an S-100 bus machine.  

It may also have been something to do with this guy who appeared frequently in Byte Magazine in 1979 - having gear like that to write software sounded so cool back in 1979!

Shugart MiniFloppy Advertisement from Byte July 1979 - featuring a Northstar Horizon

I believe that this Northstar Horizon was used by the New Zealand Northstar agents "Anderson Digital Equipment" as a support/test machine. It is in stock Horizon configuration with a ZPB Z80 CPU board, HRAM-64 Dynamic Memory board and MDS Floppy Disk Controller board.  It came with a large pile of manuals with "Anderson Digital Equipment" labels.  Only a single floppy disk drive is installed in the case and a small panel with a push button and switch is installed where the second drive would normally be.  

The Northstar Horizon with the ZPB Z80 CPU board in the extender....

Tracing the wiring showed that the push button was an extension of the back panel reset switch.  For a test machine that would make sense being a lot easier to access.

The switch is used to enable or disable the PROM option installed on the Z80 CPU board.  The installed PROM was a 2708 containing the Northstar HDT "Horizon Debug Tool" monitor program.  With the switch in "PROM Enabled" position the machine would boot into the HDT monitor and in "PROM Disabled" it would attempt to execute boot code at 0xE800.  In a Northstar this is commonly the boot code of the MDS Floppy Disk Controller. I know all this now... but it took some time to get there.  

ZPB Z80 CPU, HRAM-64 and MDS Floppy Controller Boards in the Northstar Horizon

The first test step was to confirm the main power supply worked.  I had no idea if this was in 110V or 240V configuration or the state of the large capacitors.  Reforming the capacitors and then slow powerup with a variac confirmed that the power supply worked and the transformer was wired for 240V.  That was the easy part.....

Powering up the Horizon with only the Z80 CPU board installed (the documentation said that the HDT ROM did not require RAM on the machine.) and a terminal connected to the left serial port (commonly the console) I expected some activity on the terminal but got nothing.  

The first check was to use the logic probe to check for activity on the Z80 CPU.  This showed activity on /MREQ and /IORQ so the Z80 wasn't dead.  Time to check the serial ports....

The Horizon serial ports are driven by two Intel 8251 UART on the motherboard.  Checking the /CS pin (pin 11) on the 8251's showed activity which I assumed would be the HDT polling the UART's for received characters.  The DTR lines (pin 24) were pulled low which is required for the 8251 to transmit data (subject to the loaded configuration).  The clock inputs into the 8251 were correct for 9600 baud.  Everything looked right.... but no output to the terminal.

At this point the Z80 seemed to be running but that was all I really knew.  There were plenty of questions:

  • Was the HDT ROM OK?
  • Did HDT really work with no RAM in the machine?
  • Was there a problem with the Z80 CPU board?  
  • Was there a problem with the Motherboard?  
  • Had I not understood the Northstar manual and got the serial configuration wrong? 

Faced with this many questions I went down the track of removing unknows.  The first was the HDT ROM.  

Having never seen HDT before I didn't really know what to expect.  Executing known code seemed a good way to start the debugging so I wrote a small text program in Z80 assembler that would send 'A' continually to the left serial port and 'B' continually to the right serial port.

Writing the code wasn't difficult but getting it onto the Z80 board was a roadblock.  The PROM option on the ZPB Z80 board uses a 2708 EPROM.  The 2708 is an early generation part and requires +5V, -5V and +12V (higher for programming).  My cheap chinese programmer (a Genius G540) won't even read a 2708 let alone program one.

I still want to solve the reading problem to get a dump of the HDT code (I can't find this archived anywhere on the net) but worked around the problem by building an adaptor for a 28C16 EEPROM. 

28C16 EEPROM in 2708 Adaptor

With the 28C16 installed I could see activity on the /CS pin (pin 11) of both 8251 which confirmed my code was reading or writing to the correct IO port and that some of the address decoding on the motherboard was working but still no output from the TxD pin (pin 19) on either.

The test code configured the 8251 to require DTR low to transmit data, checked that DTR (pin 11) was low which it was.  

Further probing of the 8251 pins showed unexpected activity on the RESET pin (pin 21) of both 8251 which sent me back to the schematics for further research.

The Northstar motherboard will reset the 8251 on first power up using the S100 Bus /POC line (bus pin 99) but can also be reset in software by writing 0x00 to Z80 IO Port 6.

I knew my software wasn't writing to IO Port 6 so I spent some time studying the motherboard schematic and checking signals with the logic probe.

  • The 8251 reset line is driven from the output a 74LS132 NAND gate at board position 8D.
  • The pin 8 output of the 74LS132 showed continuous activity.
  • The S100 /POC input to pin 9 of the 74LS132 was stable (as expected).
  • The "software controlled reset" to pin 10 of the 74LS132 showed continuous activity (not expected).
  • The "software controlled reset" is decoded by a 74LS138 at board position 9B and output on pin 15 connecting to pin 10 on the 74LS132.
  • The 74LS138 should drive pin 15 low only when the byte written to Z80 IO Port 6 is in the block 0x00 - 0x0F (which my test code was not doing).


74LS138 -> 74LS132 -> UART RESET

At this point I was suspecting the 74LS138 but wanted to be sure before I went to the effort of removing the motherboard from the case and heading off to the local Jaycar store to pick up a replacement part.

I connected the Saleae Logic analyser (a great tool for retrocomputing repairs) to the board and triggered on the pin 15 output going low.  

The capture shown below confirmed that the 74LS138 seemed to be at fault.  

The value on the data bus was in the range 0x00 - 0x0F the Y0 output on pin 15 should not be going low.

Note:  The rows use Northstar schematic notiation so U4 = 74LS138 A2, U5 = 74LS138 A1 and U6 = 74LS138 A0, E6 = 74LS138 G1, E5 = 74LS138 G2B and E6 = 74LS138 G2A.

Saleae Logic Analysis of 74LS138 at board position 9B

Replacing the 74LS138 stopped the activity on the 8251 RESET pins and solved the serial port problem.  After replacement and with the test code running, each serial port would send the stream of 'A' and 'B' characters.

Reinstalling the HDT ROM confirmed that also worked with the power on prompt displayed on the console.

It is quite impressive that the machine required only a single part changed.  There is a label on the motherboard suggesting the last service was in 1981.

Next step..... testing the Northstar HRAM-64 memory board.


Replacement 74LS138 in board position 9B



IOT for the Small Block - Part 1

There has been much written about IOT (Internet of Things..... devices that we wouldn't initially think of as computers connected to the internet.... smart thermometers, refrigerators, coffee machines, etc) and while there are some interesting, fun and possibly limited utility applications of IOT for the average apartment dweller, for those of us that live on lifestyle blocks IOT devices really can help.

This is the first in a series of posts describing how I have used an IOT device (a little computer really) that connects to my block wide WIFI network and does really useful things.

The basis for all my IOT devices to date is the BlockTECH WIFI Controller board.  


Assembled BlockTECH WIFI Controller v2

On my block I use the BlockTECH WIFI Controller for the following:

  • Monitoring inputs and triggering outputs when the input state changes (a smart burgler alarm - great for the workshop).
  • Automatic monitoring on/off at configured times (no need to remember when to enable the alarm).
  • Manual output control from my smart phone (switching off the electric fence before I walk out of the house so the horses, always happy to see me and their breakfast don't zap themselves).
  • Monitor bore and pump running state and chart the results (find out which neighbor has the leak that causes the shared bore to run 24 hours a day).

The BlockTECH WIFI Controller is modular and can be assembled with only the components required for the task at hand.  

  • If only monitoring then exclude the relays and drivers.
  • If you only want to control the electric fence or the front gates from your smart phone then exclude the input circuits and install a single relay.  
  • If you want to monitoring the bore and pump then exclude the relays and use a single input.

I will write a seperate posts for each showing how the board is assembled and the software configured.


BlockTECH WIFI Controller v3 Schematic



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 its 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 don't have this 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 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)
  • 2 x 4K7 Resistors (R3,R4) - Version 1.1 PCB only.
  • 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.
Are assembled boards available?
Yes.  Bas Gialopsos (UK and Europe) Ian Mavric (the rest of the world) and make these available.  Contact Bas - This e-mail address is being protected from spambots. You need JavaScript enabled to view it and Ian -  This e-mail address is being protected from spambots. You need JavaScript enabled to view it
Ian created a great video showing the interface in action.

Design Files.... if you want to build it yourself!
Version 1.1 contains the following minor changes:
  • Adds 2 x 4K7 pull up resistors (R3 and R4) on the FreHD /WAIT and /EXTIOSEL lines to prevent these floating when the FreHD is not connected.
  • Minor change to the board overlay symbol for the three links.
  • Minor change to the board overlay to put the JP1 symbols on the top of the board.
Version 1.2 contains the following minor changes:
  • Corrects connection of IC5 62256 /CE and /OE pins
  • 18F13K22 Configuration included in .HEX
Version 1.3 contains the following minor changes:
  • Added 2.1mm DC power plug.
  • Relocated mounting hole to fit 2.1mm DC power plug.
  • Relocated C9 to fit 2.1mm DC power plug. Might be tight for an electrolytic but a tantulum will do the job.
  • Mounting holes reduced to 3mm.



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.



Page 2 of 11

Powered by Easytagcloud v2.1

Contact Andrew Quinn