Advanced troubleshooting

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
Post Reply
Posts: 21
Joined: 05 Jun 2018, 12:05

Advanced troubleshooting

Post by xopr » 29 Jun 2018, 14:09

This post might be updated by me (or moderators) from time to time to make sure the information is relevant and useful.
I (xopr) managed to not get the Gigatron up and running on the first try (please don't judge me)

Advanced troubleshooting (with cheap/affordable hardware)
for people fairly new to electronics

Edit (moderators): The instructions listed on the Troubleshooting page normally solve any problem encountered while building the kit. Please check those carefully first.

One of the first things in troubleshooting (and also mentioned by the manual) is: measure the power supply and clock signals.
Since the clocks are alternating between GND and 5V every 80 nanoseconds (with a 50% duty cycle), the multimeter will pick this up as roughly half of the supply voltage.
Measure signals is harder since the bit pattern can be somewhat random which will result in an unstable value, but can give an indication of a busy bus.

There are a variety of 'scopes in all different price ranges; one of the cheapest ones can measure till about 200kHz and will set you back around $15,-. This one is not nearly fast enough to measure the clock signal, but can display the slower switching values like the upper program counter or RAM address bus bits.
With a cheap DSO138, the ROM's pin 25 activity can be seen with about 195kHz, pin 26 with 97kHz and pin 27 with 50kHz, depending a bit on how irregular the software jumps/branches.
Pins 21 to 24 (the lower nibble of the program counter) is readable with a faster (real) oscilloscope.
The upper byte of the program counter might actually not change that much if the program loop doesn't reach that part of the ROM.

Chances are, you have an Arduino lying around.
You can use it to generate a slow clock signal (with the option to pause/step through the program).
Connect the generated clock signal to the left side of R1 with a crocodile clip and make sure to match GND (for example, have both Gigatron and Arduino use the same USB power supply and don't use long USB cables.
Downside is that audio and video will not be generated correctly and won't work. Optionally, you can use Arduino Uno input 13 (the LED) to verify one designated bit on the Gigatron.
You can expand this set-up in two ways:
  1. inject a set of custom opcodes and operands on pins x-y in the socket with dupont/jumper cables where the ROM would go (remove it).
You will need an extra 16 I/Os for this, so an Arduino Uno will suffice. Pins 19-12 are for the opcode/instruction, and pins 10-3 are for the operand
  2. use it to read the bits off a bus.
You need at least the same amount of I/Os as the number of bits on the bus.
Note that this set-up is somewhat similar to the logic analyser set-up
TODO: put xopr's Arduino frankenstein proof of concept on GitHub

Logic analyser
Far-out the most effective way to troubleshoot the Gigatron is using a logic analyser.
Look on the internet for Saleae Logic or USBee (clones) in conjunction with sigrok's PulseView (open source: see for the supported hardware). Make sure to include probe hooks. With less than $10,- it's worth a try.
This will sample a short amount of time with a predefined sample rate, which you can inspect (and decode if its regarding a protocol) later on.
Here is a screenshot:
PulseView screenshot
740e84ec-5b2f-48d5-ab39-d0700c6e9927.jpeg (87.65 KiB) Viewed 1342 times
Other ideas
  • One can also use a double throw switch with a flip-flip, or pushbutton with RC circuit combined with a schmitt trigger to generate a manual clock
  • Likewise, command injection could be done with a set of 16 extra switches to 'key' in an instruction similar to the Altair 8800 or PDP-8
(updates and suggestions to this post are welcome)

Posts: 21
Joined: 05 Jun 2018, 12:05

Re: Advanced troubleshooting

Post by xopr » 02 Jul 2018, 07:25

I'm not able to edit the post anymore, so here is a post with the simple test scenario using Arduino on github:

As of time of writing, the steps to test the all of the states for Bus access decoder, Condition decoder, Addressing mode decoder and Instruction decoder are not added yet.

Posts: 21
Joined: 05 Jun 2018, 12:05

Re: Advanced troubleshooting

Post by xopr » 12 Jul 2018, 20:13

Eventually, I got my Gigatron up and running by following the instructions on the Troubleshooting.xls spreadsheet, only using a multimeter.

ICs that were shorted, placed wrong or maybe overheated in a way are not necessarily broken, but could become slow (and unusable).
I discovered this (on my Gigatron with some questionable ICs due to wrong placement among a loose solder joint) by applying a slow (500kHz) clock generated by an Arduino.

Desoldering ICs might be a bit of a challenge: the holes are metallised (vias) since it is a double sided PCB which sucks in tin to the other side.
Some of the connections also have more connected copper around it which dissipates heat and makes it more difficult to desolder the whole IC even if you add a lot of tin to keep all of the connections 'runny'.
Be patient but note: heating too long (>30s) might cause the copper and vias to let loose from the PCB which means you need to run wires between the original connections.
Applying force will definitely break a connection.

An automatic desoldering iron might be the second best option, followed by desoldering wick and a cheap desolder pump.
What I did was not to economise on the ICs and cutting off the pins near the IC itself, manually heat each island and picking out the pins with a pointed nose plier.

Clean/open up the holes with desolder wick (you might want to add a bit of tin in the closed hole for better head conduction).
Gently scratch away the burnt resin (make sure you don't scratch off the green coating) and clean off with a cotton swab dipped in 70-90% alcohol.

Replace removed ICs with new (genuine) ones from a renowned dealer.
If you are willing to spend a few extra bucks on sockets: this will help repairing (and future hacking) time tremendously.

I also want note that all the pins connected to the bus measured lower than the original 600-900mV: somewhat above 500mV.

Post Reply