RC2014 - Part 1

A quick introduction if you are reading this and have never heard of the RC2014…. it is a kit computer created by Spencer Owen and available from https://rc2014.co.uk.  Notes on the history of the RC2014 are at https://rc2014.co.uk/history/

If you have read other parts of this blog you will likely notice that most retro machines mentioned are based on the Z80.  You can blame this on my first introduction to a microcomputer was with a TRS-80 model 1. 

I first discovered the RC2014 when Hack-a-Day published a review in 2016.  At the time of writing the review is still available at https://hackaday.com/2016/09/08/review-the-rc2014-z80-computer/

I thought it was interesting but having already built Grant Searle’s 7 chip design, both point to point wired and on PCB, Sergey Malinov’s  Zeta V2, rehabilitated a number of other Z80 machines and was in the process of building S100 boards from S100 Computers, I didn’t see it as a compelling design, for me anyway, as someone happy to build things from components and prototype board. 

What I didn’t realize, but it dawned on me in early 2018 was that RC2014 is a great Z80 hardware hacking platform.  The Searle and Malinov single board computers are nice compact designs but not so easily expandable.  S100 is certainly expandable but the board size and interfacing requirements do push up the price to experiment.  Most RC2014 boards are less then 100mmx100mm so you can get 10 boards from many of the “cheap PCB” manufacturers for less than the price of a single S100 board.  It helps to have a few friends to share the surplus.

The first step in my RC2014 adventure was to build a backplane.  Spencer has the official RC2014 boards available from his store on Tindie and there are also several alternative (but compatible) designs but I had a couple of reasons to build my own:

  • Learn Kicad (seeing as my free Eagle license won’t let me build a board that size).
  • Fully understand the design.
  • Use an extended bus similar to the one described here because I want to try making a 68000 processor board.
  • Be able to share the surplus boards with some friends here in New Zealand.  The more local builders the better to keep motivation.

The result was a 7 slot backplane with 78 pin extended bus sockets. The board was produced by Dirty PCBs (https://www.dirtypcbs.com), a supplier I have used often and with whose boards I have always been happy with.  It also helped that they offer an option of 2mm board thickness which I used for the backplane…. a good choice to reduce flexing.


Other features of the backplane include:

  • A 5v switching regulator in place of the commonly used 7805.  These are available on Aliexpress in TO-220 form factor and are a good alternative for a backplane with a higher current draw from many installed boards.
  • MC34064 reset controller.  This TO-92 sized package will hold the /RESET line low until the backplane power has stabilized.  A jumper is provided to connect (or not) the MC34064 to the bus /RESET line so the backplane can be used for boards that have their own reset circuit.
  • Momentary Reset switch.
  • On/off Power switch.

What would (will) I do differently for the next batch of boards?

  • Use an 80 pin (2 x 40) rather than 78 pin (2 x 39).  It saves cutting the sockets or removing pins.
  • Larger bus track isolation pads.  The 0201 resistor pads that I put on selected bus tracks so section of the board could be isolated looked more than big enough to solder on Kicad… they certainly are not on the final board.


 
 

Building the S100 Computers Z80 SBC

The S100 Computers site (www.s100computers.com) has a range of new S100 bus designs and from time to time, PCB's are made available to the site community.

I ordered their Z80 Single Board Computer PCB (www.s100computers.com/My%20System%20Pages/SBC%20Z80%20Board/SBC%20Z80%20CPU%20Board.htm) when it was first made available in 2015 and it sat patiently in the pile of "to be completed" projects.  Finally, in July 2018 the construction was finally kick-started by the need for an S-100 Bus Master to help in the bring up of the new PDP11 V2 board (www.s100computers.com/My%20System%20Pages/PDP11%20V2%20Board/PDP11%20Board%20V2.htm).

The Z80 Single Board Computer project page has a pretty comprehensive set of steps for the board assembly. 

Key to this is completing and validating operation at build checkpoints before moving to the next.  I had built plenty of boards over the years and was confident in kit assembly so was pretty sure that those steps didn't apply to me....

Pity because I was wrong.  On first power up the board did absolutely nothing.

One thing is sure, debugging a board forces to you learn a lot more about the design than if it works first time.

The first problem I discovered was a bad solder joint on U10 Pin 7.  U10 is one of the wait state generators so this bad solder join would cause Z80 /WAIT to be continually asserted. 

The second was another soldering problem but this had some really interesting symptoms.

Despite the /WAIT issue being fixed, the Z80 would not clock.  There was no activity on M1, /MREQ or /INT and /HALT was not asserted by the Z80.  At first investigation, the 4MHz clock signal into the Z80 looked correct but when compared with the buffered output from the clock module, the clock was only transitioning between 5v and 2.5v, not 5v and 0v as would be expected.

Equally strange was that this would only happen with the Z80 installed on the board.  If Z80 was removed from the board then the clock was perfect.  Changing the Z80 to alternative, known good parts did not help.

Clock Trace from Oscillator and U36 Pin 4 (Good)

Clock Trace from U36 Pin 2 with Z80 installed (Bad)

The problem..... a bad solder join on the Z80 GND pin so it was floating.

My take away from this was that S-100 board ground-planes are large and they suck a lot of heat from the iron which makes bad joints a lot more likely.  Even under a microscope, the joint did not look bad but the multimeter confirmed no continuity to ground and reworking it fixed this.

After fixing the two solder joints the Z80 was now running.... activity was visible on the M1 and /MREQ lines but still no monitor prompt on the terminal.

On my board, I used the DLP-USB1232H rather than the earlier DLP-USB245M (both from DLP Design www.dlpdesign) to provide the serial interface.

The SBC design powers the DLP-USB1232H from the SBC regulated 5V supply.  It is not powered by the USB host.  The effect of this is that there is some time required after the S100 Bus Power is applied before the DLP-USB1232H is powered up and has established a connection with the PC host.  This wasn’t my initial problem but it is something to be aware of.  If using the USB serial connection, you will need to press reset on your S100 motherboard after power is applied to get power on messages to appear.

After some research on the DLP-USB1232H I discovered the following: 

  • The onboard FTDI chip is the FT2232H.
  • The FT2232H provides two ports for connection by the USB host.
  • Only PORTA is used on the DLP-USB1232H in the 245 FIFO mode as used on the Z80 SBC.
  • There is a Windows utility called FTPROG (available from www.ftdichip.com/Support/Utilities.htm#FT_PROG) that allows the configuration of the FT2232H to be adjusted.
  • The following configuration is required to work with the SBC hardware (245FIFO) and to appear as a COM port on the USB Host for connection by applications such as PUTTY or TERRATERM:
    • Hardware Specific/Port_A/Hardware = 245FIFO
    • Hardware Specific/Port_A/Driver = Virtual COM Port

To update the configuration without relying on S100 Bus Power:

  • Remove the DLP-USB1232H from the SBC.
  • Use a jumper to connect pins 8 (EXTVCC) and 9 (PORTVCC).
  • Connect the USB cable and run FTPROG to adjust the configuration.
  • Remove the jumper when done.
  • Reinstall the DLP-USB1232H in the SBC.

After reconfiguration and restart..... the Z80 appeared to be running but still nothing on the terminal, even after S100 Bus reset.

As a builder of Z80 projects, one of the most useful tools you can have is the Tauntek Z80 ICE (www.tauntek.com/z80-in-circuit-emulator.htm).

With the ICE installed in place of the onboard Z80, it is possible to read and write memory and IO ports, perform memory tests and to step through executing code.  It was this last feature, stepping through code that helped solve my problem.

The cold boot code in the Z80 Monitor for the board is as follows:

COLD: 

; LD A,'#' ;For quick hardware diagnostic test

; OUT (S100_CONSOL_OUT),A ;Force a "#" on the CRT if ROM access is active

; OUT (USB_DATA),A ;Force a "#" on the CRT if ROM access is active


CALL INIT_LBA ;Zero in LBA paramaters after a reset


BEGIN: ;Can use the next 3 lines initially to debug hardware

DI ;No interrupts

XOR A ;SET INTERUPT TO PAGE 0H

LD I,A ;Z80 Interrupt page 0

OUT (SW_TMAX),A ;Make sure TMA0*,TMA1*,TMA2* & TMA3* S100 lines are high on V2 SMB


SETUP_STACK:

LD SP,AHEAD-4 ;SETUP A FAKE STACK

JP MEMSZ1 ;RETURNS WITH TOP OF RAM IN [HL]

DW AHEAD ;A Return opcode will pick up this address

AHEAD: LD SP,HL ;[HL] CONTAINS TOP OF RAM - WORK AREA


PUSH HL

POP IX ;Store stack pointer for below in [IX]
 

When I stepped through I could see the call to INIT_LBA jumping to the correct code but things went wrong on the RET and the Z80 would execute an RST and jump to address 0x0038.

It was obvious why when looking at the code and understanding how the SBC hardware works.

  • The SBC has a ROM in the memory block 0xE000 to 0xFFFF.
  • The Z80 default stack pointer is 0xFFFF if not initialized.
  • The call to INIT_LBA would push the return address onto the stack at bytes 0xFFFE and 0xFFFF.
  • When executing the RET from INIT_LBA the Z80 would take the return address from 0xFFFE and 0xFFFF.
  • Because these addresses are ROM on the SBC the value returned is not the pushed return address and will be what is in these ROM locations.
  • The Z80 SBC Monitor does not completely fill the 0xE000 to 0xFFFF address block so bytes 0xFFFE and 0xFFFF will depend on your programmer. In my case they were set to 0xFF.
  • The RET at the end of LBA_INIT would receive 0xFFFF as the return address.
  • Address 0xFFFF contained the byte 0xFF which is the Z80 op-code for RST 0x38.
  • The Z80 would jump to address 0x0038.
  • Address 0x0038 is RAM in the SBC. At this point, the contents would be unknown.
  • The Z80 proceeds to execute “random” op-codes from RAM and disappears into the weeds….

So the cause was that the stack pointer had not been initialized prior to the call to INIT_LBA in the SBC Monitor code.

As of 22 July 2018 there is an updated SBC Monitor available (www.s100computers.com/My%20System%20Pages/SBC%20Z80%20Board/SBC%20Z80%20CPU%20Board.htm) which fixes this by removing the LBA_INIT subroutine, removes the call to LBA_INIT and inserts the code from LBA_INIT into the COLD boot subroutine.  This certainly works.  My approach was to relocate the call to LBA_INIT until after the stack pointer has been initialized and keep the IDE functions intact.

With the monitor changes in place, the S100 Computers Z80 SBC works well.

A fun and educational experience.

On to the PDP11…..

 

A Pile of Kaypro

From time to time I hear about someone who has enough retrocomputers and isn't looking for any more.  I am trying to be like that person but it doesn't always work out, particularly when you try to help out a friend.

It all started when I saw an advertisement on the New Zealand Trade Me auction site for a Kaypro 4.  I didn't need a Kaypro 4, I already had one but I knew someone who did - my friend Philip in Christchurch.  I was even silly enough to volunteer to go a pick up the machine and sort out shipping to increase the chances that it would arrive in Christchurch in one piece.

Philip won the auction (good price too!) and called the seller to explain that some other person would come and pick up the machine.  

He then called me back and the call went something like this....

Philip:  He is OK with the pickup.  You can call him on xxx to make the arrangements.

Me: Great.  That sounds easy.

Philip:  He said that he also has some manuals, disks and two other Kaypro.  They are labelled Kaypro II.

Me: Oh... I don't really need any more machines and who knows if they would work.

Philip: Sure you don't want them?

Me: OK... offer him $x and we will take the lot and see what works.

 

... and so arrived the tower of Kaypro, the challenges of which wil be explained in future articles.

 

 

Machines with a history / Restoring Arne’s TRS-80 Model 1

I am a collector of 70’s and 80’s vintage personal computers.  Of many of the machines acquired over the years, I have no knowledge of their history or previous owners. I know nothing of how they were used, as work horses or toys, for a long time or quickly replaced.  They are anonymous representatives of their type in my collection. Operational yes, but with little character to distinguish them from others of their type.

A small number of machines stand out as different....

Two machines (Kaypro IV and TRS-80 Model 100) are notable in that they have name tags still attached. Presumable a personal or assigned machine for the person named on the tag.  Given the tags are still attached it seems plausible that the machines have gone from the user to the closet, surfacing 20 or more years later on an online auction site.

Two machines (TRS-80 Model 4 and Amstrad PCW 8256) have a closer personal association

In the early 1980’s I had holiday employment with Porterfield Computers, the Radio Shack agent and later Amstrad dealer in Dominion Road, Auckland. During this time, Bill Porter the owner used a heavily modified TRS-80 Model 4 for software development.  10 years after the business closed I was able to buy the machine when the current owner answered my “TRS-80 wanted” advertisement in a buy/sell newspaper.  A much loved machine, I make a special effort to keep it operational.

By the mid 1980’s, personal computers had become capable and affordable enough for small business owners to consider. Lomas Matheson, a local quantity surveyor and family friend was looking for a machine for Word Processing, Spreadsheets and my school friend Mark to learn something about computers. The Amstrad PCW8256 was the perfect machine for the job and did sterling service for the family. 25 years later Lomas insisted I have the machine, something I couldn't refuse knowing the history. It also still runs well today.

Where this is leading to… is sometimes a machine turns up with history and an owner to tell you about it.

In my case, this was an TRS-80 Model 1 gifted to me by Arne Rhode. This is a machine with an interesting history.  Arne purchased it “new” in Denmark when he worked there as an embedded software developer for B&O and brought it out with him when he relocated to New Zealand.  

What originally started as a standard 16K Level II Model 1 (26-1xxx) with Monitor and CTR-80 cassette went through a series of enhancements, both standard and non-standard to become the machine I have today.

 

The configuration I received was as follows:

  • Model 1 Level II 16k Keyboard with
    • Numeric keypad with extra function keys
    • Lower case modification with hand made PCB
    • Soldered Expansion Interface connecting cable
  • Expansion Interface with 32K
    • Radio Shack Double Density Kit
    • Clock board with hand made PCB
    • External Drive Bay with 2 half height drives
    • Power adaptor (240V to TRS-80) with sockets for European mains plugs

Arne told me that he upgraded to a Model 4 and later IBM PC’s when they came available and put the Model 1 into storage.  It hadn't been used for the best part of 30 years but did follow him through a couple of house moves.

After a quick email external clean (amazing how dust gets into sealed boxes), I first powered up the keyboard using a known good Model 1 power supply and monitor. It is not good to blow things up on first power up.

 

The keyboard LED lit but nothing appeared on the screen.

Debugging time....

  • 5v and 12v power supply regulator outputs were working and the values within tolerances.
  • Tested the Z80 processor with a logic probe which showed no activity on the /MREQ or /IORQ pins so it was replaced. This was a MOSTEK variant common in TRS-80 machines and is not the first that I have replaced one.
  • The replacement Z80 showed activity on /MREQ and /IORQ but still nothing on the screen.
  • Installed the Z80 ICE board and tested the clock, RAM and ROM, all of which checked out OK.

Time to look at the video circuit....

I worked backwards through the video circuit with a scope and found that no synchronization signals were being generated.  This was caused by faults with Z5 (74C00) and Z6 (74C04).  

 

Unfortunately 74Cxx parts are not so easy to get these days.  I tried replacing with 74LS00 and 74LS04 parts.  The video seemed fine when viewed on a monochorome composite monitor but was not so good when connected to an LCD monitor.  Instead of white text on a black screen there was a pink color to all the text.  Substituting the 74C00 with 4011 and 74C04 with 4096 worked well and the video was back to "Model 1 normal".

 

 

 

TRS-80 Model 1 Keyboard Repair

If you have been involved with retrocomputers for any time, the chances are very high that a machine that worked perfectly when last used has now developed a new fault (or two or more.....).
 
This happened to me recently with a TRS-80 Model 1.  In the time I have had the machine it has been very reliable.  I pulled it out of storage after 6 months to do some testing with the Model 1 FreHD Interface and found that the Shift Keys had stopped working.  
 
Failure of individual keys is a pretty normal occurance on machines this age.  Failure of a single Shift key wouldn't be a big problem because there are two Shift keys.... but in this case neither worked.
 
The TRS-80 Model 1 keyboard is memory mapped.  The ROM polls a set of memory addresses in the block 0x3801 - 0x3880.  When keys are pressed this pulls up the matching bit on the data bus.  Most addresses link to 8 different keys except for 0x3880 which on the Model 1 is used only for the two parellel wired Shift keys.
 
The only component that would affect 0x3880 and the Shift keys but no other keys on the keyboard is Z2 (74LS05).
 

After Z2 was replaced the keyboard was fully operational.
 

 

SD-Systems SBC-200 Testing - Part 2

In the earlier post I wrote about testing an SD-Systems SBC-200 single board computer for the S-100 bus using my Northstar Horizon mainframe.

The end result of that testing was that the board seemed to work correctly but Philip had been unable to get it to operate in his s100computers.com S100 Bus motherboard.  

It happened that I had an unbuilt PCB for the same motherboard in my projects box... this was the kick I needed to get it assembled so see what was going on.  

Philip was kind enough to include a partial parts kit when he shipped up the SBC-200.  While most of the components were easily available from Jaycar or RS Components, the 270 ohm 9 resistor SIP resistor packs were proving difficult to locate and these were in the partial kit.  Thanks Philip.

My motherboard is labelled Revision 02 and differs slightly from Philip's in having an extra two slots and some rearrangement of the onboard components but is essentially the same design.  There were a couple of gotcha's documented on the web... the silk screen for Q1 is reversed and the fuse links are only fuses for the power status LED's (interesting) so can be replaced with links.

The motherboard undergoing smoke testing with my home built variable supply while waiting for the switching power supply modules to arrive.

Powering an S100 motherboard requires DC supplies of +8v, +16v and -16v.  The current thinking when using switching supplies is to run +7.5v, +15v and -15v if possible to have less heat dissipation in the onboard regulators.  Aliexpress came to the rescue with adjustable switching supply modules providing the right voltages at reasonable prices including shipping to New Zealand.  

 

S100 motherboard with switching supplies and SBC-200 installed.

 

S100 motherboard with switching supplies and SBC-200 installed.

With the motherboard assembled, the power supplies connected and the "known good" SBC-200 installed, I was surprised to find that the board didn't start properly.

Testing with a logic probe and a meter showed that the /RESET line did not go below 1.7v when the reset button was pressed which caused the SBC-200 to not reset correctly.  A clean /RESET is critical to the start address hardware on the SBC-200.  

The schematic showed R18, a 470 ohm resistor between the RESET button the GND.  I assume this was on the board to prevent a direct short to GND in the event that the other side of the reset button was tied directly to VCC rather than via a pullup resistor. The SBC-200 had a pullup resistor so the effect of R18 was to prevent /RESET going below 1.7V when the button was pressed.

Replacing R18 with a jumper solved the problem and a good reset was had with /RESET going to GND and the SBC-200 starting properly. The same solution worked for Philip's Revision 01 board.

 

SD-Systems SBC-200 Testing - Part 1

One of the challenges with retro-computing is knowing which of the many new/untested components you are trying is causing the headache.

My friend Philip was having just this problem with his SD-Systems SBC-200. 

The SBC-200 is a Z-80 based single board computer for the S-100 bus as is described on www.s100computers.com

Philip had spent a couple of months trying to get either of his two SBC-200s to show any sign of life and was starting to pull his hair out when he emailed wondering if I was willing to have a look.  In addition to 30 year old board, an extra variable was new build S-100 bus motherboard that Philip was using.  This is a DIY board from the www.s100computers.com family so there was a risk of the problem being there rather than the SBC-200. 

Having a known working S-100 test machine (The Northstar Horizon) and an unbuilt PCB for the S-100 bus motherboard put me in a good position to remove some of the unknowns so I agreed.  Always one for an interesting retro project also. 

Before Phillip shipped me the board we tried running a boot EPROM that, if my code was right would send a continuous stream of ‘A’ characters to the serial port.  The same technique worked well when initially testing the Northstar.  Unfortunately we got no output on the serial port so the boards duly arrived.  Philip also commented about the problems he was having getting the board to reset using the motherboard reset button and had to use creative techniques like grounding the Z80 /RESET pin with a piece of wire.  Interesting!

The documentation for the SBC-200 suggests these were often assembled from kits and inspection of the boards confirmed this as there were some differences in the construction technique, particularly the default configuration jumpers.  I was a bit surprised when I first looked at the boards that there were no jumpers at all for most options yet the manual has pages of configuration options listed.  It turns out that the jumpers are printed as PCB traces which must be physically cut if a different configuration is required.  One of the two boards had the default configuration traces in place, the other had most cut and headers installed on the board.  I can only assume the constructor wanted to try different configurations.

The default configuration of an SBC-200 has a 2716 EPROM at 0xE000, 1K of static RAM at 0xF800 and a start on power up address of 0xE000.  The documentation also suggested that the SD-Systems monitor expected to reside at 0xE000 so this looked like a configuration to go with. 

Based on all this I picked the “uncut” board to test first.  It also happened to have the test ROM so my guess it was the last board Philip tested.

I cross checked all configuration traces against the manual to confirm the configuration.  I didn’t see any configuration issue with this board… Philip had that bit right.

With the board installed in the Northstar I tested the reset circuit with a logic analyser.  The board uses a 74LS74 flip-flop to control the pull up of the A15-A12 address lines based on the power on address configuration.  This circuit relies on a clean reset from the S100 bus to reset the flip-flop and pullup the address lines.  The boot code is later expected to read IO port 0x7F to clear the flipflop and disable the address line pullup.

For any start address other than 0x0000 this is a critical circuit.  

In the Northstar it worked perfectly and I could see A15, A14 and A13 high after reset. 

The next step was to run the board with the Tauntek  Z-80 In-Circuit Emulator and test the memory and IO port decoding. 

The Tauntek is a fabulous board for debugging Z80 based hardware.  After power up I could display the test code at 0xE000 which confirmed that the ROM was correctly addressed and reads would return the correct data.

OK ===> D E000

E000   D3 7C 18 FC 00 00 00 00-00 00 00 00 00 00 00 00    ................

E010   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................

E020   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................

Disassembled this is as follows which was correct for our test ROM (that did nothing but write to a port in a continuous loop)..

OK ===> L E000
E000 D3 7C          OUT (7C),A

E002 18 FC          JR E000

E004 00             NOP

Running the code starting at 0xE000 and breaking showed the CPU cycling between 0xE000 and 0xE002 which is correct.

One thing I missed in the documentation when writing the test code was the requirement to read port 0x7F to clear the 74LS74 flipflop and release A15, A14 and A13.  For ROM code at 0xE000 this should be coded as follows to set the Program Counter and then clear the address line pullup.

JP E0003

IN  A,(7F)

Reading 0x0000 without doing this means you are always accessing memory with these address bits high so it reads the EPROM.  This is correct behavior and the board worked as expected.

OK ===> I 7F

 ---> FC

Reading port 0x7F correctly resets the 74LS74 circuit after which reading 0x0000 returns 0xFF which is correct for a Z80 with nothing at that address.  The board worked as expected.

A quick memory test of the onboard RAM from 0xF800 to 0xFBFF reported no errors confirming that the onboard 1K static RAM was operational and was correctly addressed.

OK ===> MT F800,FBFF

Seeing it was all going so well I installed a Northstar 32K Dynamic RAM card configured for 0x0000 and ran a memory test on the first 0xFF bytes which also passed... so the buffering to the S-100 bus is also working.

So far things looked good so it was time to check out the serial port.  The manual and a multimeter confirmed that the serial port edge connector required the following minimum set of connections to a DB9:

J2 Pin 3 -> DB9 Pin 3

J2 Pin 5 -> DB9 Pin 2

J2 Pin 13 -> DB9 Pin 5

Installed the ‘Send A’ test ROM after updating it to IN 0x7F on start and configured for 9600,N,8,1 the terminal started filling with a stream of  ‘A’ characters.  The SD Systems Monitor also worked.

This was a good board… it seemed Philip’s problems were elsewhere….

 

Living Computer Museum - VAX 11/780

 

Living Computer Museum - DEC PDP-12

 

Living Computer Museum - Data General Nova

 

Living Computer Museum - DEC TU56 and RK05

 
  • «
  •  Start 
  •  Prev 
  •  1 
  •  2 
  •  3 
  •  4 
  •  5 
  •  6 
  •  7 
  •  8 
  •  9 
  •  10 
  •  Next 
  •  End 
  • »


Page 1 of 11

Powered by Easytagcloud v2.1

Contact Andrew Quinn

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