Not functional; Blinkenlights static

[River-of-Dust]

Thanks! Here's what I've found time for so far:

1) I ordered another oscilloscope probe and finally got some time to try it out. I captured the attached pictures when the probes and scope were all set to 10x. (I'm still new to using an oscilloscope, and I'm still puzzled why the ground wires of nearly all probes are alligator clips, which only seem useful on a board with an exposed ground plane. So, I made do.) What I saw when checking U3-2 and U37-11 was less square than I was hoping, but perhaps good enough, especially assuming I'm introducing some noise with that ground lead extension I used. Is it good enough for both clocks?

2) Okay, I *think* I follow that, but I'll have to find more time to try it out.

5) I was pretty careful about selecting the resistors, but I'll grant that the rings on some of them are less clear than I'd like. To really check them, I'd need to desolder them from the board, wouldn't I? (I do have a desoldering iron, so it's not as much of a big deal as it might be, but I'd still like to avoid desoldering anything if I can avoid it; just to be safe.)

-Derek

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

[bmwtcu]

5) All 7 resistors can be measured in system without desoldering (with 5V power disconnected).
R3/6/7/10/19 = 2.2k
R1 = 1M / R2 = 1k (that said your clock waveforms in #1 look OK, so measuring R1/2 is purely an academic exercise)

[River-of-Dust]

5) Okay, I found time to test the resistors, and I measured the following (all okay, basically):

R1 = 0.997M
R2 = 1.004K
R3 = 2.218K
R6 = 2.216K
R7 = 2.218K
R10 = 2.195K
R19 = 2.211K

Now, I'll need to find the time to write a sketch for my Arduino Mega (well, Keyestudio Mega Plus, but same thing) to try to slowly walk through that code. Apparently, the key bit there is to use 1A (so, U1 pin 2, I assume) to issue a LOW-HIGH-LOW signal as one "clock cycle", I think? Then, just monitor the pins of the PC, instruction, and decode registers.

-Derek

5) All 7 resistors can be measured in system without desoldering (with 5V power disconnected).
R3/6/7/10/19 = 2.2k
R1 = 1M / R2 = 1k (that said your clock waveforms in #1 look OK, so measuring R1/2 is purely an academic exercise)

[River-of-Dust]

Okay, I ended up thinking that rolling my own logic analyzer with an Arduino might be more than I have time for right now, and why re-invent the wheel. So, I googled around and was shocked to find that cheap logic analyzers are actually around $10-15! If I had known that, I would've gotten one earlier.

So, I hooked it up to each of the PC IC's in turn and took some samples. It's clearly doing... something, but I'm not seeing much activity on U5 and U6 at all, and the clock, at least when captured at 16MHz (this little logic analyzer maxes out at 24MHz sampling rate), it seems uneven. But, perhaps that's an artifact of being a *cheap* logic analyzer? Anyway, here are some screenshots of the samples I took. Other than surprising me that U5 and U6 don't seem to have any work to do (or are being held low by something?), there does seem to be a lot of pin toggling going on.

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

[bmwtcu]

The goal is to monitor PC[15:0] as a whole and see if it is correctly:
1) resetting
2) loading
3) incrementing
by comparing PC[15:0] to the address column of the ROMv5a listing. Doing this will shed light on when you first see a problem and allow you to zoom in on what needs debugging. Remember that it's a 16-bit counter, so most of the activity will be in the lower byte since for the most part you are starting from zero and incrementing PC once per clock until you BRA/BNE/BGE/BEQ somewhere else, so if you don't have enough pins, you can just monitor the lower sequential bits for now, but if you have enough pins you should be looking at RST_B, PC[15:0], CLK1, PL_B and PH_B. I'm not familiar with your particular tool, but you should be able to group the PC pins as a single hex value to make it easier to read.

I can't tell for sure since it's so zoomed out and I'm not sure if you are showing the same load pin for all captures or just the load for that particular 161 (Is ^Pe in the U5 capture supposed to be the high byte PC load? It doesn't look right.), but PC9 looks like it starts off low from reset then gets loaded with a high later, so bit 1 in the Y register might be stuck high. If ^Pe is PH_B, you need to check the PH_B and PL_B circuitry in the control unit to make sure everything is soldered down right. PH_B/PL_B is high when PC is incrementing and low when loading. It could be PH_B/PL_B goes low due to poor soldering that causes a spurious load of the PC with unexpected data. Basically confirm you don't have cold solder joints on anywhere PH_B/PL_B is connected to/generated by, eg D3/D4/R7 (the wired AND), R5, U11, U12, U14, U16 and the inverter need to be checked. Check the diodes for the JMP instruction as well to make sure they are soldered in properly in the right orientation.

The "uneven"-ness is likely just a sampling artifact. From the logic analyzer point of view, the clock only transitions when you sample it every 62.5ns at 16MHz. If you sampled at integer multiples of 6.25MHz, it would look like a perfect periodic square wave (The Gigatron clock is actually asymmetric but you won't see that accurately until you significantly oversample). You need to sample at at least 12.5MHz to accurately capture what's going on in the PC (assuming no clock issues which seems to be the case as previously seen with your scope capture).

[River-of-Dust]

OK, here I realize just how much of a novice I am at electrical engineering. As a computer science graduate, I understand the concept of what you want me to check, but as a guy who also picked up a soldering iron, I'm having to learn a lot more to figure out how to suss out exactly where the fault is. I went and bought a 16-input logic probe for a bit more money (a Kingst LA1010, so still not an expensive one but moreso than the 8-line one I already had), and I did some more sampling of the program counter with CLK1, PL, and PH together with the high and low bytes of the program counter. I will attach two different samples from each.

If I understand what *should* be happening here (and I'm quite sure I'm still feeling my way around a bit), this isn't what's supposed to be happening. I also used my logic probe (simple TTL / CMOS probe) to probe the Y Register, and it looks like its outputs are held high or low while its inputs are toggling rapidly, and its output is never enabled. That also sounds intuitively wrong.

I already went back and re-checked the position of every component, including the direction of every diode, but I imagine I'll be re-rechecking that just for sanity's sake.

So, I think I'm going to have to try reflowing the solder on all the resisters, diodes, and IC's you mentioned that might affect that and hope for the best. BTW, is there, somewhere, a high-resolution one-page schematic of the entire computer with EVERY line connected? The way the official schematics break out various subsystems helps to understand how each part works, but I feel like a (zoom-able) high-level view of the entire thing, all as one, with all ground and VCC lines marked as well, might help me see the big picture.

I make this post just to show that, when I have time, I have been doing some more debugging, and to keep the thread alive. However, if anyone can look at this and say "Aha!", I welcome any and all additional tips and information. Thanks!

The goal is to monitor PC[15:0] as a whole and see if it is correctly:
1) resetting
2) loading
3) incrementing
by comparing PC[15:0] to the address column of the ROMv5a listing. Doing this will shed light on when you first see a problem and allow you to zoom in on what needs debugging. Remember that it's a 16-bit counter, so most of the activity will be in the lower byte since for the most part you are starting from zero and incrementing PC once per clock until you BRA/BNE/BGE/BEQ somewhere else, so if you don't have enough pins, you can just monitor the lower sequential bits for now, but if you have enough pins you should be looking at RST_B, PC[15:0], CLK1, PL_B and PH_B. I'm not familiar with your particular tool, but you should be able to group the PC pins as a single hex value to make it easier to read.

I can't tell for sure since it's so zoomed out and I'm not sure if you are showing the same load pin for all captures or just the load for that particular 161 (Is ^Pe in the U5 capture supposed to be the high byte PC load? It doesn't look right.), but PC9 looks like it starts off low from reset then gets loaded with a high later, so bit 1 in the Y register might be stuck high. If ^Pe is PH_B, you need to check the PH_B and PL_B circuitry in the control unit to make sure everything is soldered down right. PH_B/PL_B is high when PC is incrementing and low when loading. It could be PH_B/PL_B goes low due to poor soldering that causes a spurious load of the PC with unexpected data. Basically confirm you don't have cold solder joints on anywhere PH_B/PL_B is connected to/generated by, eg D3/D4/R7 (the wired AND), R5, U11, U12, U14, U16 and the inverter need to be checked. Check the diodes for the JMP instruction as well to make sure they are soldered in properly in the right orientation.

The "uneven"-ness is likely just a sampling artifact. From the logic analyzer point of view, the clock only transitions when you sample it every 62.5ns at 16MHz. If you sampled at integer multiples of 6.25MHz, it would look like a perfect periodic square wave (The Gigatron clock is actually asymmetric but you won't see that accurately until you significantly oversample). You need to sample at at least 12.5MHz to accurately capture what's going on in the PC (assuming no clock issues which seems to be the case as previously seen with your scope capture).

[bmwtcu]

Since you only have 16 bits, configure the LA to sample RST_B, PC[11:0], CLK1, PL_B and PH_B. Group the PC[11:0] pins as a single hex value to make it easier to read. The parallel decoder is useful, but you need to compare the lower 12 bits of the PC against PL_B and PH_B. PC9 should not always be high, but you need to find out if it's stuck high out of reset or is loaded from Y1 at some point. Trigger on rising edge of reset before applying power to the Gigatron and verify that PC[11:0] is stepping through ROMv5a correctly from PC[11:0] = 000. Look at PC9 separately and determine if it's stuck high coming out of reset or only when PH_B is asserted. I don't think it is based on your previous captures, but if PC9 is stuck high out of reset, swap the U5 and U4 161 chips to see if the problem follows the 161. Otherwise if PC9 goes high only when PH_B is asserted (goes low), determine from the instruction being executed when PH_B goes low [look at the value of PC when PH_B goes low and the ROM listing to look up the instruction] if it's a legitimate PC load or is spurious. If it's a legitimate PC load [like one of the branch instructions], check if the Y register value is expected, or whether Y1 is stuck high out of reset. If it's spurious, check PL_B/PH_B circuitry as previously stated. Use the LA/scope, not a logic probe.

[River-of-Dust]

Hi!

Thank you for the additional information! Today, I ran some more tests with the logic analyzer probes connected as you suggested, and I found three interesting things:
(1) The program counter does NOT seem to be following the 5a ROM code properly, as far as I can tell. It does for a bit, then jumps in places that don't make sense to me (granted, it's in a custom assembly code, but I think I follow it okay).
(2) PC9 is not stuck high the whole time, but it goes high early in the sample (with 0x200 being the value of PC[11:0] right at that moment), then just stays there no matter how long the sample I capture is.
(3) While PL repeatedly toggles, HL almost never asserts. It is almost always high. In some tests, it does assert, but just once, then returns to high (see attached screenshots).

Judging by your instructions, I think I'm going to have to do further troubleshooting on the PH_B circuitry.

-Derek

[bmwtcu]

Where does it start to deviate? Where the PC starts deviating from the ROM listing and whether it's consistently the same deviation will tell you what is wrong with your hardware. Are you saying that you see PH_B go low and then PC9 goes high the next clock cycle? When PC[11:0]=0x200, PC9 is high and everything other bit is low. What I'm asking you is what instruction is being executed when PH_B goes low, which should happen just before PC9 goes high.

[River-of-Dust]

Hi!

Interesting! Well, the odd thing is that it's not as consistent as I thought. The blinkenlights always freeze, and they usually freeze with all four illuminated, but sometimes with only two, and (rarely) with none of them illuminated. Further, I have just discovered that even when the same lights are illuminated as during a previous test, the values of the PC are not always the same! Values that I see immediately prior to PC[11:0] 0x200 are 0x1DF, 0x1DE, 0x1F6, 0x1F7, 0x1F9, and 0x1DD. Also, in almost NONE of these instances does PH_B go low.

For instance: