Search the Community
Showing results for tags 'ivory tower'.
Found 5 results
-
Though I've posted about my channel and videos before, I figured keeping a central place in one thread would make more since. While I have done more videos than I will likely ever post in here, I thought it would be good to start off with my 40th official video for my channel and to start off April right. I present my unboxing and game play review for the Neo Games home-brew release of the limited boxed edition of Spies in the Night for the Atari 2600! Enjoy and thank you for watching!- 57 replies
-
- 1
-
-
- itc
- ivory tower
- (and 8 more)
-
5200 with very odd keypad / fire button issues
-^CrossBow^- posted a blog entry in Stories from the -: ITC :-
I've done a video on something similar to this but here is a rundown on what I was encountering: A 5200 sent in for services had a note stating that top fire button wouldn't work on the console. This is an issue I've run into before and in fact have created a video on it. It can be due to the controller having a broken trace of course on the flex circuit inside it. But... it can also very well be due to a faulty 4052 MUX chip inside the console located at U13 or A13 depending on the age of when your 5200 was made. Well, that was indeed the same issue with this 5200. But after replacing that and confirming the top fire button was now functional again, I then used my port loopback tester board with the diagnostics and was surprised when a slew of other errors came across indicating issues with the keypad. I then used a different program for just testing the controllers and sure enough, whenever you put a controller into port 2 and pressed the pause button, it would call the entire aux buttons to register all at once on both controller 2 and port 1 even though a controller wasn't plugged into port 1?! So that meant Start, Pause, and Reset were all registering at the same time. I later found out that when pressing the 4,5, or 6 buttons that it would also register ever single keypad button in that same column to also register. Obviously that wasn't going to do! In testing the other ports, I found out that port 4 suffered similar issues but only the keypad section was messed up in that pressing 1,2, or 3 would cause all the keys on those columns to register at once. Very odd. Diagnostics told me it was a keypad issue so that was good. I then went to the service manual proceeded to follow the flowcharts for what might be the issue. My 'hunch' was that one more of the other 4052s was having issues. However, the flowchart kept pointing me to either a faulty GTIA (Which does handle some of the keypad controls), bad GTIA socket, or a bad 7400 chip near the RAM section. So I tried replacement GTIAs and 74ls00 chips with no change. The flowcharts have you using an O'scope to check for activity on the various triggers lines and such. Well, I was seeing activity or pulses indicating polling that the console is doing to check for buttons being pressed, but I was seeing something else odd as well. I was seeing what would appear to be ghost pulses between the normal square wave I should be seeing. I proceeded to then use my multi-meter and checked all of the connection points from the GTIA to the passive components to the MUX chips to the controller ports looking for any shorts or broken traces. Everything was checking out... After hours of checking everything the flowcharts and schematics were telling me and nothing else to go on, I decided to do something I should have done in the first place. Guess what that was? I removed each of the 4052 MUX chips (Kinda a PITA since these were all soldered to the board and not in sockets). And checked each one of them in my Bitback chip tester pro. Sure enough, I found another failed 4052 at position U12 about middle of the board just ahead of the controller ports. After installing all new sockets and putting in the original 4052s that passed and replacing U12. Finally the controllers were working properly again and the controller loop board was passing the diagnostics! The moral here is that people are SO quick to blame the controllers on the 5200 for their woes. The reality, is that the 4052 MUX chips are very prone to ESD failure and fail they do...often. Especially the RCA branded ones. Next time you have controller issues with your 5200, don't assume that controller is a POS and blanket blame it. Have the console checked out to be sure it isn't something internal causing an issue. The pic below shows the two 4052 MUX chips I had to replace to get this fully working again. They have little silver dots on them to indicate I replaced them and to mark where pin 1 is. Again, they are highly prone to failure so if you own a 5200, best to have a full set of these on hand just in case. They are cheap ICs so it is good insurance to have on hand. In this case I have small stash of OEM RCA ones that have tested good that I've pulled from other dead 5200s over the years. I suspect in the past that U10's 4052 was changed out in the past as it was already in a socket and had a different lot number on it from the others. View the full article -
So these arrived in the mail yesterday and so I was super stoked to build one up and try installing it onto my test bed stock 7800 I use in the lab. If you saw my earlier blog post, you might have already figured it out, but yes... I designed some mount PCBs for slight ease on installing UAVs into 7800s. These mount boards have the chroma fix already on them in addition to the extra resistors and cap for audio mixing to external RCA jacks etc. However, this is a dual mono audio solution and not stereo... just something to keep in mind. Not sure I will make these available to the public yet as the time to hand assemble and test them isn't something I can do large scale. But for my client installs going forward, this is likely how my UAV installs will pretty much look like. This first board I put together is using single pin sockets so I could easily pop the UAV on/off the board as needed for testing etc. Actual installs will have the UAV soldered permanently onto the mount board and as a result the UAV will sit lower onto the mount board than you see here. The mount board is designed with board headers so that you solder it down near the resistor legs that the video signals are tapped from. I also have vias for power and ground that line up with the GND and +5 from the RF modulator pins. In this example install, I use a 90 right angle pin header that solders to the top of the pin headers from the RF modulator board and then can be soldered through the vias. But this isn't required as you could just solder wires to these vias instead if you wanted. Additionally, once the UAV is attached, you could also just run +5 and GND to the UAV pads and it would feed everything as well. I also have included 2 more board headers that allow me to solder to the R5 and R6 resistors to get the audio signals we need for the POKEY and TIA. These are then mixed on the mount board and an audio out pad provided to simplify the audio portion of installs. Here is the example setup I did last night. Again I used single pin sockets on this so I could remove the UAV easily but actual installs would have the UAV soldered onto header pins directly. As a result, the actual combo won't sit this tall on actual installs as the UAV will only at half the height you see here. Here are two more boards I soldered up ready to go. These are using the through hole pin headers. To align these, I actually set them into place and then set a UAV on top. So actual assembly is basically to solder on the SMD components first, then set the header pins for the UAV into place, place the UAV onto the pins to align everything up, flip the board over and solder the header pins for the UAV on the bottom of the PCB. Then I solder in the larger and thicker header pins for the mount boards resistor leg mounting. I then line it up and solder the mount board into place. I'm then able to do some initial testing without the UAV by power on the console to make sure I have power and ground connections where needed. I can also verify that some of the video signals (Especially chroma) are coming through using my o'scope. Everything else just needs continuity tested to be sure I have connections. I can then place the UAV onto the pins and power on again without soldering it to initially test that the UAV is working. Granted it is just sitting on the header pins at this point, but they make a good enough connection for these initial tests. Once confirmed everything is a go, I can then solder the UAV permanently into place and run my output wires where needed. Because of the orientation of the UAV (It was really the only way to keep it all self contained in this one spot), it does require running your AV out wires ahead of time or header pins etc.. as you won't be able to solder it into place very easily once the UAV is in place given how close the video outputs will be to the RF modulator's interconnect board.
-
More 2600 Technical Fun - Player 2 shoots constantly
-^CrossBow^- posted a blog entry in Stories from the -: ITC :-
Here is an issue that I've seen before in one form or another and I thought I would talk about it here while working on a earlier era 2600 heavy sixer last night. The system was sent in for refurbishment. In this case that is all the original electrolytic capacitors being replaced out, new DC power jack, new voltage regulator etc. But a problem was reported and confirmed during testing of the console. What was the issue? In this case it was an issue with the player 2 controls. Specifically, player 2's fire button was always registering as being pressed. Easiest game to demonstrate this was Air-Sea Battle as when you reset the game to start, player 2 is constantly shooting the entire time even without a controller plugged in. Part of the refurbishment process is changing some components near the joystick port per an Atari service bulletin from back in the day for ESD protection. It is the last part in regards to the ESD protection that needs focus, because it was found that static electricity from players hands when inserting and unplugging the joysticks, would cause static discharge to the joystick pins. Luckily for most this is pretty harmless but one component in particular on the heavy sixers is very sensitive to this and prompted Atari to create the service bulletin to address it. The specific component to be checked is labeled as A203 on the main board. While the original IC chip has an Atari PN labeled on it, the chip is a bog standard 4050 IC that was common on the 8-bit line, 5200, some 2600s and lots of other devices. So common in fact, that the 4050s are still made today. However, on the heavy sixers, the trigger lines (Fire button) goes through the 4050 chip and in turn relayed back to the TIA. The most basic way it works is that +5v is always present on pin 6 of the joystick port which is the trigger line for each controller. When you press the fire button, you ground this connection causing the +5 to drop to near 0. This is what is referred to as going from Hi to Lo and is how the system knows when controller inputs are being used. In the case of this 2600, pin 6 from joystick port 2 was not showing any voltage from it and as a result, this was being interpreted by the logic in the system as if the fire button was already being pressed down. The basic troubleshoot process here is to verify the traces from pin 6 back to pin 7 on the 4050 IC chip and ensure there are no broken traces. If that checks out, then the culprit is down to two component at that point being The 4050 IC or the TIA itself. Anyway, per the service manual flow charts and because I found no issues with the traces on the board, I removed the original 4050 IC chip, installed a socket and new 4050. Let it burn in test for several hours last night and verified that player 2 is now behaving properly and not so short tempered. So in this case it was an easy fix but also a warning on why ESD was and still is an issue to this day. In this case, an errant spark from someones hand in the past damaged something internally in the 4050 IC causing it to no longer function properly in regards to the player 2 fire button. Here is the replaced 4050 and socket. Although this 4050 in the pic did have to swapped out with a new Ti branded one as this one would cause graphical issues once the system was warmed up. Here is the soldering on the bottom where the socket was installed. Finally here is one of the capacitor/diode combos that the service bulletin has you install to help with ESD from the controller ports. This is the one installed at C237 for port 2. There is another combo like this installed at C236 for port 1 on the opposite side of the board. View the full article -
Made possible by fellow long-time AtariAge user Jesse Hardesty! Salute!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord