Not functional; Blinkenlights static

[River-of-Dust]

Hello!

I'm hoping someone can help me with this, because I've been trying to troubleshoot it on my own for a few weeks on and off with no luck. I ordered a set of boards from a Tindie vendor, ordered the parts I didn't already have from Digi-Key, Mouser, etc, and put it all together. The power light illuminates, the clock ticks at the right frequency, the voltages look good, but the Blinkenlights just come on and stay that way. Usually, it's all of them, but sometimes two or three of them. No video, no audio. (See attached photos of my build.)

WHAT I'VE TRIED:
(1) Examined my soldering under magnification (multiple times). No shorts and no bad joints found.
(2) Re-soldered three of the chips that I suspected just in case. No change.
(3) Re-examined the installation of all IC's for orientation or wrong-socket issues. No issues found.
(4) Burned multiple copies of multiple versions of the ROM into different EPROM's (Ver. 5a, 4, and 3) and tried them all. No change.
(5) Removed all chips (socketed) and tested all TTL chips in my EPROM burner / TTL tester. All show as good. Re-installed: No change.
(6) Examined the installation of all non-IC components twice (including the only TO-92 component). All appear to be correct in both component value and direction (where it matters).

(7) Examined board according to the "Troubleshooting" Excel spreadsheet. Results:
(a) According to "Diode Mode" check page, all values are within 100mV of nominal. Most non-zero values are off by 100mV, but if I understand the directions, this is good enough. All nominal-zero values are very, very near zero.
(b) According to the "Voltage Mode" check page, several things are wrong:
(i) U1 pins 5 & 8 are 1.96V instead of 2.5V
(ii) U3 pin 11 is 5.0V instead of 2.4V, pin 14 is 3.7V instead of 2.8. Others are close.
(iii) U4 pins 11-14 are all wrong.
(iv) U14 most of the yellow-highlighted pins are wrong.
(v) U39 yellow-highlighted pins all wrong.

(8) Connected my Arduino Uno to the board according to the instructions in that test sketch (linked from another forum thread). Found a strange issue with the instructions where they skipped Arduino Pin 12 but used Pin 13 twice, without mentioning that this was intentional. As one use of Pin 13 was as a "probe" line and the other wasn't, I made the (unwarranted?) assumption that the first mention of pin 13 was intended to be Pin 12. Proceeding thusly:
(a) First Test:
The Blinkenlights don't seem so "odd and even sequentially" to me.
U7 (ROM - Removed): Not sure about pins 35-37; others fine
U11: Fine
U13: Fine
U14: Pins 3 and 13 don't blink the indicator
U10: Fine

(b) Second Test:
All fine, I think

(c) Third Test:
U20: Fine
U30: Fine
U31: Doesn't match pattern of 5, 9, 12, 16 on while 2, 6, 15, 29 are off
U36 (RAM): Fine except for Pin 27 (doesn't blink)

(d) Fourth Test:
U37: Pin 19 doesn't blink; others fine

(e) Fifth Test:

With controller: Complete failure; but, is my controller even correct? The controller on the parts list is no longer available (at least, not from the included link), so I didn't get one. I do have a 9-pin Famicom controller that came with a modern Famicom work-alike clone, though, so I tried that, hoping it had the expected pinout. However, I do not know this for sure.
Trying with Pluggy McPlugface: No response.

(f) Next tests:
Not sure they did anything? Testing instructions, but no feedback except on LD, and it didn't make much sense.

(9) I went over the whole board with my multimeter in connectivity mode, looking for shorts between adjacent pins, but I found none.

SUMMARY: I have tested everything in every way I can think of or find online, and I cannot find any reason that this build will not work; yet it stubbornly refuses to do so! I've successfully built about twenty other hobbyist computer kits (some complete kits; others a board design an Bill of Materials), so I'm not completely new to soldering or even to complex soldering projects. I say that not to brag, but just to make it clear that I "should" know what I'm doing, BUT I'm fully willing to believe that I've screwed up in some way here; I just can't find it!

What should I test or otherwise do next?

Thank you in advance to anyone who can help me find the problem(s) with my Gigatron build!

-Derek

[bmwtcu]

Good job listing all the debug you've done. A couple of things jumped out at me. Can you confirm:-
1) when you say the clock ticks at the right freq, are you measuring both CLK1 and CLK2 with an oscilloscope?
2) can you check (again) if there might be a short between U3-10 and U3-11?
3) do you have another SRAM you can try?
4) what speed is your EPROM?

[River-of-Dust]

Good job listing all the debug you've done. A couple of things jumped out at me. Can you confirm:-
1) when you say the clock ticks at the right freq, are you measuring both CLK1 and CLK2 with an oscilloscope?
2) can you check (again) if there might be a short between U3-10 and U3-11?
3) do you have another SRAM you can try?
4) what speed is your EPROM?

Thank you for your suggestions!

1. I checked with my multimeter (and re-checked just now), and it reports that both CLK1 and CLK2 are oscillating at 6.249Mhz.
2. I just re-checked U3-10 and U3-11 and found no short between them.
3. I do have extra memory chips of this type, so I just now switched the chip in U36 with another chip that was already tested in another (working) computer, but it made no change. The Blinkenlights come on and stay on.
4. I have a one-time writable AT27C1024 at 45ns (from Microchip) installed right now (it was in the BOM), and I have also tried UV-erasable AM27C1024's at 120ns (from AMD). They both had the same results.

[bmwtcu]

1) You're going to want to look at the clock visually on an oscilloscope to make sure it has the right voltage levels and a monotonic rising edge. Do you have access to one?

2) If you're measuring 5V at U3-11, I was hoping that meant PC3 was stuck high. It's not clear to me if your Gigatron is just loading PC3 HIGH all the time as a result of a garbage instruction, but shorting to 5V seemed at least a plausibility to rule out. Again looking with a scope to see what is being loaded from the BUS is instructive. Better yet, if you have one of those cheap logic analyzers, you could look at the whole PC and step through it against the ROM listing. https://raw.githubusercontent.com/kervi ... ROMv5a.lst

4) I assume the same part already passed a Verify on the PROM programmer?

[River-of-Dust]

1) You're going to want to look at the clock visually on an oscilloscope to make sure it has the right voltage levels and a monotonic rising edge. Do you have access to one?

2) If you're measuring 5V at U3-11, I was hoping that meant PC3 was stuck high. It's not clear to me if your Gigatron is just loading PC3 HIGH all the time as a result of a garbage instruction, but shorting to 5V seemed at least a plausibility to rule out. Again looking with a scope to see what is being loaded from the BUS is instructive. Better yet, if you have one of those cheap logic analyzers, you could look at the whole PC and step through it against the ROM listing. https://raw.githubusercontent.com/kervi ... ROMv5a.lst

4) I assume the same part already passed a Verify on the PROM programmer?

Thanks!

1) I recently bought an inexpensive (relatively) Hantek handheld oscilloscope, but I'm very new at using one. So, let me know if I'm not doing it right. I got it out tonight and made some measurements on U3-U6. I don't have a logic analyzer, though.
2) So, on U3 and U4, I found that pins 11-14 (So, Q3-Q0) were all toggling between about 0V and 5V, with varying frequencies. On U5 and U6, I found that pins 11-14 were all LOW, except for U5 pin 13, which was stuck HIGH. Is not suggestive of anything? Sometimes, for reasons I wasn't sure of, the lights would change to a different pattern (perhaps with one or two on instead of all four, but still static), and then the measurements on these pins would also change. I'm not sure if I shorted something briefly while probing, or if the computer proceeded very briefly without my intervention. Unplugging and re-plugging in the computer brought it back to the same measurements for these pins (and with all four Blinkenlights lit).
4) Yes, all four of the EPROM chips I burned passed verification by the programmer multiple times. A bad EPROM program was my initial thought, but if all four chips pass muster (and two models of 27C1024 at that), I'm not sure what else I can do there.

Here are a couple photos of testing.

Thanks in advance for any further assistance!

-Derek

[bmwtcu]

Need to head out so I'll keep this short. Refer to page 3 of the Gigatron schematic. Are you comfortable pulling U1 and connecting CLK1 (output)/RST_B (input)/PL_B (input)/PH_B (input)/PC[15:0] (input) to your Arduino and single step through the entire PC incrementing per https://raw.githubusercontent.com/kervi ... ROMv5a.lst ? Out of RST_B (U5-1 should go LOW to HIGH), all the outputs on U3/U4/U5/U6 should be LOW (PC[15:0] = 0). If you're still seeing U5-13 HIGH, then either U5-13 is stuck HIGH or U5-4 is stuck HIGH and you're loading the PC with that stuck bit when you toggle CLK1 from LOW to HIGH. If PH_B is LOW, then a PC load is occuring on PC[15:8].

Also, what signal is that last scope capture of?

[River-of-Dust]

Need to head out so I'll keep this short. Refer to page 3 of the Gigatron schematic. Are you comfortable pulling U1 and connecting CLK1 (output)/RST_B (input)/PL_B (input)/PH_B (input)/PC[15:0] (input) to your Arduino and single step through the entire PC incrementing per https://raw.githubusercontent.com/kervi ... ROMv5a.lst ? Out of RST_B (U5-1 should go LOW to HIGH), all the outputs on U3/U4/U5/U6 should be LOW (PC[15:0] = 0). If you're still seeing U5-13 HIGH, then either U5-13 is stuck HIGH or U5-4 is stuck HIGH and you're loading the PC with that stuck bit when you toggle CLK1 from LOW to HIGH. If PH_B is LOW, then a PC load is occuring on PC[15:8].

Also, what signal is that last scope capture of?

Hi!

Well, I've only used Arduino very little so far (I did do a fair bit of PIC32 microcontroller programming for a lower-division computer organization class a few years ago, though, which is similar), but I can probably do that. I do have to spend some time studying the schematic to figure out why U1 is the IC to remove and replace with the Arduino, though. So, I guess you could say that I'm cautiously optimistic that I can do that, after I study up on the schematic and spend a little time writing a "sketch" to handle that. I'm having trouble picturing what you're describing at the moment, but maybe in a couple days I'll have time to figure it out and give it a try.

Thanks!

-Derek

[River-of-Dust]

Oh, and that last scope capture was of U3 pin 11, I believe. Looks like my camera caught it just as the signal was jumping a bit. It was mostly stable, but it did jump around a little bit, as if the signal was changing in some way. Staying on a 1 or a 0 longer, I guess.

-Derek

Need to head out so I'll keep this short. Refer to page 3 of the Gigatron schematic. Are you comfortable pulling U1 and connecting CLK1 (output)/RST_B (input)/PL_B (input)/PH_B (input)/PC[15:0] (input) to your Arduino and single step through the entire PC incrementing per https://raw.githubusercontent.com/kervi ... ROMv5a.lst ? Out of RST_B (U5-1 should go LOW to HIGH), all the outputs on U3/U4/U5/U6 should be LOW (PC[15:0] = 0). If you're still seeing U5-13 HIGH, then either U5-13 is stuck HIGH or U5-4 is stuck HIGH and you're loading the PC with that stuck bit when you toggle CLK1 from LOW to HIGH. If PH_B is LOW, then a PC load is occuring on PC[15:8].

Also, what signal is that last scope capture of?

[bmwtcu]

1) capture CLK1 on U3-2 and CLK2 on U37-11 on the same screen on your scope. Basically you need to ensure that you have a reliable clock at the furthest destination from the Pierce oscillator before you can do any debug. You're looking for a periodic square wave like Marcel's from viewtopic.php?p=384#p384 (although I think he did that with no load). Measure the frequency and max voltage swing of both channels. Really the clock is the first step to prove out before step 2 below.

2) Sorry, I was in a rush and didn't really explain. U1A is part of the Pierce oscillator circuit. Since you don't have access to a logic analyzer, my intent was to have you disconnect the on-board oscillator and just drive CLK1 directly from your Arduino so that you could toggle it manually. The goal is to monitor the state of the program counter (and the other signals) one rising edge clock pulse at a time through the ROMv5a listing from line 498 onwards to see what U5 was doing since you suspected that one bit was stuck high. The program counter can be reset, incremented and loaded, so if you can prove all 3 happen correctly, you can move on to verifying that the EPROM data is being loaded correctly to the I and D registers. If you have enough pins on your Arduino (eg Arduino Mega) you could monitor the outputs of U8 and U9 at the same time since that's what you'll need to verify next. When the Gigatron is first powered up, it will come out of reset with the program counter zeroed out. If you're not seeing that, that means you have a bit stuck somewhere. If U5-9 goes LOW, the contents of the Y register will be loaded into U5/U6 on the next rising CLK1 edge (this happens during a branch instruction), otherwise the PC should increment by 1 each clock pulse.

ROMv5a.jpeg (245.68 KiB) Viewed 805 times

[bmwtcu]

5) Also check the value of R3/6/7/10/19 . They don't look right and will affect PL_B/PH_B/Audio DAC operation. While you're at it, check R1/2 as well. I can't really read the colors from your photos but they will affect clock oscillation.