-^CrossBow^-

I would look at the 6502 and then the RIOT...

Well, that was quick. I found an old 4 switcher in my garage I picked up years ago as a parts unit. Still had all the chips in it and it actually does work but all the switches are shot. Anyway, more important is that it had a fully working TIA. Popped it into this other 4 switcher and I've got proper response on all paddle lines again. So yeah.. apparently this other TIA has something messed up internally that can't read the full analog values of paddle 3. It can only see a 0 or 1 or equivalent that reads all the way left or all the way right. Nothing in between.

Very clean looking NTSC console. Is it an A3? (Serial number sticker on the bottom of the case shell). Given the screen shot you've attached there are a few different things. If it were the CPU which, you were correct about its location. Then usually when they are bad you just get a black screen. But you are getting some life or what looks like it is trying to get some life. What game or games have your tried to start it up with? Have you verified that the power output into the voltage regulator is good? Should be about 10v - 12v on average and you should have +5v coming out of the regulator. You can easily check the output regulator voltage using a multimeter and placing the probes on the large center traces down the middle. The trace on the left side is the +5v and the trace on the right is the ground. If all of that checks out then as @bent_pin suggested, make sure you are on the right channel (I believe your pic has it in the channel 2 position currently). A good game to use for basic operation of at least some of the video section is the 2600 game Frogger as it will immediately start up playing music so you can hear if audio is working. Then again, you might not be getting any audio because the TV seems unable to sync to the signal. From there it can get a little trickier but my first hunch might be to try a replacement 7432 chip. It is the 14pin IC just above the largest one there on the left and has Korea marked on it. It handles much of the video signals from the system and passes them onto the RF modulator. It could also be the large IC as well, but that is why I asked which games you might have tried to help isolate that.

Yes I'm reaching out to see if anyone else has seen anything similar and to document what I'm finding on a strange issue I've got with the player 3 paddle control only a revision 12 4 switch I'm working on. Here is the actual issue that is taking place... I use @Paul Slocum's test cart to verify full paddle functions on both controller ports for all 4 players. I do this using a single set of paddles that I know work and swapping them between the ports during the testing. On this console, paddle 3 will stay all the way to the left, and then as a point is crossed, it is instantly on the right hand side. There is no jittery motion or any motion at all. It is like a digital reading vs analog? In looking at the schematics, there isn't much of anything between the controller port and the paddle read pins on the TIA. Just a single capacitor. I've verified continuity between pin 5 of the second controller port to C220 and from c220 back to pin 38 of the TIA. No breaks in that connection and resistance is never above 1Ω on average and I get the same for the other read lines, so the traces are good. Using the 2.6 diagnostics program set in controller matrix mode with the controller plugs in place, I see the pulse on pins 40,39, and 37. But pin 38 shows low at all times. I've pulled the TIA itself as it is a Signetics made one and it passes in my chip tester pro. So the TIA appears to be good. But in posting about it in the Backbit.io forums, @evietron did confirm that she is testing all of the control lines off the TIA but only digitally so it is possible that the TIA is bad in regards to the analog reads from pin 38 and would still pass the test given that it does show a change in the paddle but not until a certain point is reached as I stated above. So any others with EEs have any other ideas for me to try before I resort to trying a different TIA? I don't have ready access to them as I would like but I can remove them from working units in my collection to at least test or possibly from donors I have. Although there is a reason those consoles are donors and not working units being used by folks. And while I didn't test it outright, I did go ahead and pull the cap off c220 and put another in its place from a donor board. No change.

You could also call it the "IntelliControl"...

Interesting. So the traces top and bottom run perpendicular to each other? Or at least they mostly do. I wonder if there was an actual reason behind this? The NTSC boards have their traces running every which way like a maze as is common.

Totally off topic but in looking at the PAL board layout more closely, I have to wonder if the wire-wrapped 3600 prototype was used for the PAL console design? Are there are a bunch of traces on the bottom of the PCB like there is on the NTSC ones? Also those panel switches look mighty crusty!

In looking and thinking about this more, did you order the 7805 from Console5 along with the compound? The white stuff that is sometimes tossed in for free, I've never used as I find it much too runny and use a higher quality compound. Also I can see what I'm pretty sure is the heatsink in the lower right side of this picture? Did you remove the heatsink to take the pic of the regulator then?

Okay, looks like you are using one of the simple composite only output kits. I can see that you are using a prefabbed PCB by zooming in on the pic you posted. Also, I assume you still have the heatsink being attached to that regulator? Because if not, then the smoking is very likely the thermal compound smoking from the heat of the regulator as it is supposed to be bolted to the large heatsink but it seems yours is removed? Also, I think personally that you might have too much thermal paste on there as it looks like it is also gooped around the regulator legs a bit? Over time, I've see the oils separate out of the paste and become conductive overtime. It would also help to see those solder joints on the legs a bit better to make sure they aren't bridged with each other, or more importantly, bridging on a trace next to them as again, especially on the top, those traces are really close to each other.

You installed a new regulator, can you give the link to where you bought it and show the solder work on it? My initial guess here is a short on the pins where it was soldered or perhaps on he bottom/top where some of the solder might have crept over and is shorting against one of the other traces as they are so close to each other that it is possible to do.

This is awesome Mike! Excellent work. I've had this on loop for quite some time just listening to it in the background. Seems to work quite well from the BackBit Pro as well...

Yes those glyphs, but now they show the glyphs needed to reach the planets you have found in your Wonders section that was introduced about a year back. But in the past, it would only show the planet name and the stats on it. Now, it actually shows a small section of the glyphs needed to get to that planet you have added to your wonders and I'm pretty darn sure that is new since singularity or even possibly the Echos update itself?

So I'm late in finding this. But when did they add in the portal glyphs for the planet discoveries?! I just found this out the other night while playing and had not recalled seeing those listed before? This was a huge thing to me because over a year ago I apparently had found a 99.5% hospitable planet and didn't realize it at the time as I was just going through the systems trying to get to some specific star color system. And then when the discoveries were added I saw that I had this awesome paradise planet that I never even explored. But all it would show is what system it was part of but I had NO Clue on how to go about finding exactly where it was. Now that the portal glyphs have been added I was able to go straight to that planet that I'd been searching on/off for the better part of the last few months! So yeah... that's pretty awesome and I hadn't really noticed it mentioned anywhere?

This isn't a new idea, as even Atari themselves played with this idea but for some reason didn't go along with it. I also tried this on another controller a few years back and while it worked great where I had applied this on that one, I had never done the controller completely. What was that change/modification you ask? This... this... and this... So yes, those are in fact snap dome switches that I've used kapton tape to hold in place securely to activate as new tactile contacts onto the mylar. However, it is a little tricky to do this. First is that these aren't the usual 10mm snap domes that our Atari CX-40s and CX-24s came equipped with. These are smaller snap domes and they took way longer to arrive from Aliexpress than I would have liked. However, while this size is idea to cover the area of the contact sections on the mylar, it is also a problem. That is because, you have to align them just right so that you don't have the corners of the snap domes touching both halves of the contact section at the same time or else the buttons are always registering all the time. So, this does require that some of them be offset a tad, and in the case of the fire buttons and a few other locations, I actually use two small strips of kapton to mask the contact traces on the mylar where the corners of the snap domes sit. This was especially important for the side fire buttons where room isn't at a premium. How does it work? Great! Everything registers with a nice tactile click you can feel and hear when pressing all of the buttons now. And I didn't have to modify the rubber buttons at all. Even with their carbon contact pads still in place, there is room for them to sit ontop of these snap domes and actuate and don't feel much different to use other than feeling the click of them. Is this better than the foil dot method? Yes... by a large margin as these snap domes are actually gold plated and I used a brand new rev9 mylar when I did this controller. But is better than other solutions with gold plated contacts etc? Well, I don't know? I like the tactile feel I get using these controllers and I don't think the kapton tape and snap domes are going to wear out anytime too soon. But time will tell. I will also state that the time needed to line these little buggers up and tape it all down to look nice without being too much is way way longer than it takes to just purchase a ready made kit would or cutting and applying the foil dots. And the snap domes weren't as cheap as I would have expected cost wise. I purchased about 20 snap domes initially so that I could have enough to do two controllers and after the shipping and wait time and amount of time it took to do it. The other kits are about on par cost and labor time wise LOL! But I'm happy I've done this and so far these are only my test lab controllers that I use when working on 5200 consoles. But I might swap them out with my main ones in the near future to see how they hold up over time that way. But for now, they are getting more use in the lab here at the ITC!

That's odd because the DF is able to run PAL versions of the ROMs without issue and as far as I know, they don't have the encryption in them? Now I'm running a modified BIOS in my 7800 that doesn't require the encryption so I'm able to run both PAL and NTSC games and demos from my DF cart?

I've heard others report about RIOTs being problematic on NTSC 7800s, but that hasn't been my experience and I've held a lot of NTSC 7800 consoles. But given the description of what was happening it seemed to be the culprit. For the record, I've only had one Maria that I know was bad that I had to swap out (Was missing some of the lum signals as the colors were just wrong). I've had to replace about a half dozen TIAs in 7800s, and 3 6502 CPUs at this point. I can't recall a RIOT being an issue in a 7800 I've serviced so for me, they appear to be pretty robust compared to the TIA and CPUs. Glad you got it going again!

The sequel helps address a lot of this as I recall just basically buying up everything I wanted vs actually crafting most of it. Also they improved where the climbing in a number of ways in that there is a LOT more verticality required in places now and to help the player know where they can and cannot climb, you can enable a mode where sections of the rock and structures will highlight in yellow so you know it is something you can grapple onto and climb.

I really don't have any words for this. I'm hoping that the case shell was so utterly scratched with gouges and the like and that the trim plate was so horrible, that this was seen as an improvement.

To add to this, the recent emails sent to Atari subscribers for the new XP Outlaw limited edition release, even mentions at the bottom that it will play on the upcoming 2600+. So this in part exists to help promote additional physical cartridge sales and drum up interest in future releases as well. It is that last part that interests me the most as while I'm not really in the market for another copy of Outlaw, I was on board for buying games they released that I didn't already have a physical cartridge of. And curious to see what comes in the future from this new Atari for additional cartridge releases.

I'm running an additional wire off the composite output of the UAV to the composite pin on my 9-pin that I have installed to provide me with c-sync for those cables that need it. But I'm also running sync itself to its dedicated pin from the Sync off the UAV which, I believe is just the sync off the 4050 it is attached to.

Not this exact issue no, but the 4013s are a common failure point with something similar in the 5200s so it isn't a bad place to start and is a cheap enough part to replace. This might even qualify to piggy back another 4013 on top to see if the behavior changes to give you a better idea.

Pretty sure the ones that C5 is selling these days are also switching based. But I've used their 5200, Genesis, and Intelly 2 replacements and haven't experienced any noise related issues. So they seem to be pretty well filtered for that.

Well Forbidden west is more of the same of course but just new regions and environments to explore. Most of the machines are still the same as they were in the first game and of course the new mount you can get later is basically an end game mechanic. I understand why that is given it would have made the game over with way to quick otherwise. But yeah, even on the aging PS4 hardware, Forbidden West has the best graphics I've seen on a PS4. The new God of War games are also equally impressive and I actually ended up liking Ragnarok more than the first game. But yes, once you have the skills in place and the right weapons in hand, the Horizon games can start to feel like it lingers on a bit towards the end. Still, the way they handled the environments and diversity of it in the first game I still feel was done better than the sequel.

There is also the issue that current Atari wouldn't want to deal with support calls from customers when their homebrews they purchased outside of Atari, don't work. I noticed an email from Atari today, for the new Outlaw XP release and it states at the bottom that it will work in the upcoming Atari 2600+ console. So again, they are going to want a way to monitor and control what games will and won't work on something like this.

Well, I didn't quite outline the exact steps I had to take so for any others that similar to me, just aren't versed in using an Atari computer beyond simply loading games. I have a 130xe that I installed my VBXE into and used my FujiNet 1.5 to get it done. This is what I had to do: - First was finding a SpartaDOS ATR image that would work. The 3.2 image from Brewing Academy's TNFS worked for me. But I had to copy it to my SDcard and then load that to a drive slot. - I also had to go into my FuniNet's configuration via HTML webpage and set the SIO speed to the slowest setting of 55kb. Anything faster and SpartaDOS would refuse to load properly. - I downloaded @Piotr D. Kaczorowski ATR that has the FC.com and needed XBF file and placed that into a different slot on my Fujinet. Slot 3 in this case for drive 3 emulation. - Held down OPTION to have the fujiNet boot up using the SpartaDOS ATR in slot1 - In SpartaDOS I just had to type 'D3:' to switch to drive 3 (Slot 3 on the fujinet). That allows me to access the ATR files that Piotr provided. - Type FC.COM - From here the program comes up and shows me what is currently in the banks of my VBXE. I had the original FX 126 PAL installed into the first 2 banks and the GTIA 106 in banks 3 and 4. - Made sure that bank1 was selected (It is by default), and had to press the 'L' key to load up a different XBF. It will come up with a list of the XBF files found. - Use the cursor keys on the keyboard to navigate and select the XBF you want. If you use the ATR from Piotr, there will be just the one. I did add in the Rambo NTSC to the ATR using Altirra so I could select it also. - Press enter on the XBF you want and at that point, it should begin to flash program the VBXE. This will take a few min given the slow speed of the SIO in this mode. - Once that is done, it will then go through the Verification process which, looks the same as the programming. This should complete with no errors...although I still had some issues... - You will be back at the main FC program screen and you can press the B key on the first bank or whichever bank you installed the XBF core file to, so that is the core that the VBXE boots with when it comes up from then on. - Press Esc to exit and...you're done. For some reason, the MyDos ATR had issues in that my VBXE was never being 'seen' properly by the program and it would only work properly using the SpartaDOS image. Even then I still had 2 instances where the verification process would just stop and give an error. Once was after the first verification, and the second time it happened was about midway through. On the 3rd attempt it seemed to pass without issue. I also got and still get verification issues when trying to load up the RAM expanded NTSC core. However, while it does or seems to fail verification, it still appears to be loaded and working regardless. So that was the process I went through on my 130xe to get this going using my Fujinet.