Not functional; Blinkenlights static

Information about getting support on Gigatron builds
River-of-Dust
Posts: 9
Joined: 10 Jun 2022, 10:57

Re: Not functional; Blinkenlights static

Post by 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

bmwtcu wrote: 15 Jun 2022, 11:19 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
Attachments
IMG_7028.jpeg
IMG_7028.jpeg (1.02 MiB) Viewed 348 times
IMG_7029.jpeg
IMG_7029.jpeg (1.17 MiB) Viewed 348 times
bmwtcu
Posts: 126
Joined: 01 Nov 2018, 12:02

Re: Not functional; Blinkenlights static

Post by 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
Posts: 9
Joined: 10 Jun 2022, 10:57

Re: Not functional; Blinkenlights static

Post by 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
bmwtcu wrote: 23 Jun 2022, 22:30 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
Posts: 9
Joined: 10 Jun 2022, 10:57

Re: Not functional; Blinkenlights static

Post by 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.


bmwtcu wrote: 15 Jun 2022, 11:19 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
Attachments
U6_PC12-15.PNG
U6_PC12-15.PNG (37.42 KiB) Viewed 206 times
U5_PC8-11 Run3.PNG
U5_PC8-11 Run3.PNG (39.19 KiB) Viewed 206 times
U5_PC8-11 Run2.PNG
U5_PC8-11 Run2.PNG (39.92 KiB) Viewed 206 times
U4_PC4-7.PNG
U4_PC4-7.PNG (45.67 KiB) Viewed 206 times
U4_PC4-7 Run3 Zoom.PNG
U4_PC4-7 Run3 Zoom.PNG (70.04 KiB) Viewed 206 times
U4_PC4-7 Run2.PNG
U4_PC4-7 Run2.PNG (96.64 KiB) Viewed 206 times
U3_PC0-3.PNG
U3_PC0-3.PNG (88.8 KiB) Viewed 206 times
U3_PC0-3 Run3.PNG
U3_PC0-3 Run3.PNG (90.45 KiB) Viewed 206 times
U3_PC0-3 Run2.PNG
U3_PC0-3 Run2.PNG (89.08 KiB) Viewed 206 times
CLK1 Zoom.PNG
CLK1 Zoom.PNG (38.54 KiB) Viewed 206 times
bmwtcu
Posts: 126
Joined: 01 Nov 2018, 12:02

Re: Not functional; Blinkenlights static

Post by 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
Posts: 9
Joined: 10 Jun 2022, 10:57

Re: Not functional; Blinkenlights static

Post by 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!
bmwtcu wrote: 14 Jul 2022, 06:55 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).
Attachments
PC8-15, CLK1, PH, PL.PNG
PC8-15, CLK1, PH, PL.PNG (66.75 KiB) Viewed 81 times
PC8-15, CLK1, PH, PL 2.PNG
PC8-15, CLK1, PH, PL 2.PNG (64.83 KiB) Viewed 81 times
PC0-7, CLK1, PH, PL.PNG
PC0-7, CLK1, PH, PL.PNG (93.04 KiB) Viewed 81 times
PC0-7, CLK1, PH, PL 2.PNG
PC0-7, CLK1, PH, PL 2.PNG (93.58 KiB) Viewed 81 times
bmwtcu
Posts: 126
Joined: 01 Nov 2018, 12:02

Re: Not functional; Blinkenlights static

Post by 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.
Post Reply