Gigatron Hackers

Hi all,

I've built a Gigatron, and the video and audio seems to be working fine:
But, when I attach a controller (cheapy knock-off SNES controller wired to a 9-pin plug), the Gigatron acts like it's receiving lots of random inputs. Nothing I press makes any difference.

I've put my oscilloscope on the clock, latch and data lines on the controller port while the controller is connected. I can see different serial bits when I press buttons (parts of the trace drop low in different areas for each button). This appears to be working correctly.

I'm concerned by pin 13 of U39. This is the output enable for the game controller shift register - on my Gigatron, it never goes low.

Removing U39 and tracing the /IE signal back to where it's generated at U11, this also never goes low. The other three signals here (/DE, /OE, /AE) show lots of activity on the scope, but /IE on pin 7 is just stuck high.

IR0 and IR1 on the input to this IC show lots of activity.

I've piggybacked another 74HCT139 on top of U11, but with pin 7 bent up and checked that on the scope (to isolate any problem on the board pulling pin 7 high), but that also remains high.

I'm a bit stumped here. It looks like A0 and A1 (the inputs to U11) are both showing activity, so this almost looks like a software problem (I'm using the v6 ROM).

Can anyone confirm that pin 7 on U39 should be going low to read the output of the controller shift register?

The other odd thing is that the Gigatron is seeing lots of random inputs, but /OE on the shift register is never low, so how on earth is it getting inputs?

Many thanks!

Signal /IE indeed must go low to read the serial register, but this only happens once per video frame, that is, for a single 160ns cycle every 17ms. Whether you would see it depends on the scope trigger capabilities. In addition, if the 74HCT139 U11 was broken, chances are that nothing would work because the other signals it generates are critical. So I would first suspect either the controller or the 74HC595 chip.

Also the 74HC595 wants CMOS levels. So if you use a 74LS139 instead of a 74HCT139, you might not have the right levels (but that would be the other way around, so not so sure).

That's great, thank you for the information.

It hadn't occurred to me that the scope might not be able to trigger! 160ns is a very short amount of time, and my scope is fairly old. I'll have another crack at it tonight and see if I can spot anything.

All the chips are HC or HCT, there's no 74LS anywhere on the board.

I have some more controllers on order, so I'll update when I've tried those.

Happy to report that it was the controller! Everything is working properly.

Yes, that was what I assumed as I was first reading. The controllers operate at different voltage levels and have some quality control issues.

As for where the inputs were coming from, I would guess it could be an improperly soldered connection in the controller. It is a serial device, so it would need some sort of chip to encode that. And CMOS logic tends not to like open lines. Even the shift register on the Gigatron could have been getting an open line from the controller. Shift registers are among the chips that don't take too kindly with open lines. So the inputs could be due to improper termination. That can lead to "random numbers" in unexpected places.

That is similar to grabbing a mic or touching the strings on an electric guitar and getting a hum. That would imply there is a broken connection related to the volume control, socket, or patch cord. So that would essentially be an open line that is producing noise.

Definitely agree.

This second controller started misbehaving as well. I ended up building a little buffer with a spare 74HCT32 (quad OR gate, tied each gate's inputs together to improvise a buffer).

I sent the clock and latch signals through that to the controller, and buffered the data line back the other way. This prevents the controller interfering with the Gigatron's signals, and it all works perfectly now.

I was getting random inputs when the controller was unplugged, but a pullup resistor on the data line fixed that (as you say, open lines are bad).