alex_79

It's from the service manual. There are several different scans of it, and some might miss some pages. I don't remember exactly which one I took the schematic from, but the one on Atarimania has it (split on two pages).

More info here: https://www.robotworkshop.com/robotweb/?page_id=106 Apparently it used IR communication. There's a picture of the prototype "I/R pod" that plugged into the controller port on that site:

Seems like the game is sending data to pin 1 of the right controller port. So there should have been some piece of hardware that plugged there to control the robot.

CX2600A_rev_1-13_schematics.pdf

I doubt there's a comprehensive website that cover every console ever made. There are a couple of old ones that are a good start though: Pong Picture Page it hasn't been updated in ages, and it actually has been offline for a few years and only recently went back up again. It groups clones and software-compatible consoles together Old-computers.com has some good info too.

True, but the 2636 PVI has inputs for analog pots, and that's what code in the existing games use to read the controller. I find more likely that a console using that chipset would just use analog sticks. The number of sprites that can be displayed per line is an hardware limitation of the 2636 chip. No amount of ram or extra hardware in the cartridge can change that. AFAIK you can change the horizontal position of a sprite while is being drawn, but that would just offset the portion of it that hasn't still be drawn. WIthout flicker, you cannot display an image like the one in the ad using a 2636. And it looks like it's a real screenshot, not a mockup, since it shows distortions due to the curvature of the screen and reflections of the ambient light on it.

The 1292 APVS was my first guess by looking at the 4 switches on the console. While the joysticks look very similar to the Atari ones, the base of the stick is different, and could very well be analog, not digital, which supports the 1292 theory. There's at least one 1292 clone that came with single button joysticks: the Italian Cabel "Universal Game Computer". Separate keyboards were available too for games which required them. Anyway, looking closer at the screenshot, it doesn't appear like something coming from a Signetics 2636 to me. Too many high res objects on a single line to be possible with the available 4 sprites, unless flicker is used. It seems more like a bitmapped display, similar to the one from the Channel F.

If the editor you're using has a "block" mode (i.e. a way to select, copy and paste a rectangular region of text), then it's very easy to move the existing non-interlaced tables side by side like in the examples above.

I have a few different models 2600 (PAL), CRTs and LCD TVs and I'm available to test if you still need it. (I imagine you already got a lot of volunteers!) I really like the fact that it doesn't require removing any component. A couple of questions: - Does it fit under the bottom RF shielding of the Jr and 4-switch consoles? Or do you need to remove the shield? - Are composite and s-video mutually exclusive, or is it possible to have both connector installed and choose the needed one each time depending on what TV/monitor you're going to use? - Do you already have a price range in mind for the finished product?

That's exactly the reason why is such a bad idea relying on visual guides. ALWAYS refer to the schematics!

Forget the caps. As said, continuity to what's supposed to be video input to the A/V board with those TIA pins is definitely wrong. Pin 20 and 23 are Vcc (+5V), not the video signal. Form the picture you posted, you connected the 5 pins where the modulator was (*) to the A/V board like this: pin1 to GND pin3 to Video in pin 4 to Audio in Apart for GND, these connections don't make sense to me. This is the schematic of your board from the Service Manual: From this schematic you can see that pin 3 is connected to +5V through the inductor L205, while pin 4 is where the Video mixed with the Audio is fed to the modulator. So, if anything, pin 4 should go to the "Video in" of the AV board, while I'd probably pick the audio from cap C208, where it connects to R207, after having lifted one of the legs of the latter from the board, so to disconnect it from the video part of the signal (but wait for advice from someone with more expertise, I assume no responsability!😆) -------------------------------------------------- (*) BTW, why removing the RF modulator? Once you clip the 5 pins it's isolated from the board. Just leave it there, so if someone in the future wants to restore the console in its original state will be able to. There's plenty of space inside the case, so I don't see the necessity to desolder it.

I suggest to give as many information as possible when searching for help, as there are tons of different video mods, and several different Atari models, made for different video standards and with different board revisions. What mod are you trying to install? Where is this guide you're referring to? Schematic? What Atari model? What board revision? Parts number (e.g. R222) without specifying what board they refer to aren't useful. I'm no expert, but that definitely doesn't seem right. By your post, it seems like you're using the simple 1 transistor amplifier mod. The TIA chip has no analog video output that can be fed directly into the amplifier. It has a few digital signals that are combined through a resistor ladder into a composite video that goes to the RF modulator. The signal should be taken after the resistor ladder and should not show continuity with any of the TIA pins. Also, TIA pin 20 is Vcc (+5V). My suggestion is to avoid like plague "visual guides" relying on pictures and wires color codes, unless a schematic is also provided showing exactly where the mod has to be connected in the console circuit, and what components need to be disconnected from it, so that you can check against your actual board (which might slightly differ from the one used in the guide!). Visual guides and color codes are a good recipe for disaster IMHO.

Try repeatedly toggling the joystick-trackball switch back and forth. If that fixes it, then the switch is oxidated and you can spray some contact cleaner inside it for a more permanent fix. Once you rule out the switch, the next most probable issue is the cable. Use a multimeter to check continuity in all the wires. If the cable is fine too, then it's probably one of the ICs. (they're common parts and can be found easily, but they're likely soldered in a CX80 board, so you need some experience to replace them). That's normal. CX80 and CX22 output the same signals. If you find a rom labeled "CX80", it's actually for the Atari ST mouse. That's because the first CX80 that was documented was modified to work like an ST mouse, which led to believe that they all were like that. New released roms are only labeled Atari Trackball or Atari Mouse, but you can find older ones with the wrong "CX80" labeling.

You can use whatever value is suitable to drive your led with 5V. The led is basically there just for show, and isn't necessary for the diagnostic cart to work.

Same thing. DE-9 is the correct name, but DB-9 is very often (mistakenly) used to indicate them instead. The metal ones work just fine and are easier to find and cheaper than the plastic "IDC" connector shown in the linked post. They're fine.

In my programming attempts, I usually put the switches to build different versions inside an IFNCONST statement. In that way you can pass their value from the command line (using the -D option) without editing the source each time, and if you omit it, the one defined inside the statement will be used as default. By using a script/batch file, you can build different versions at once. e.g., if in your source you have IFNCONST PAL PAL = 0 ;0=NTSC 1=PAL ENDIF You'll build the NTSC version by default, and the PAL version if you use the "-DPAL=1" option from the command line (or in a script).

You can get a reproduction of the diagnostic cart from the AA store, or build one yourself if you have access to an eprom programmer. A flashcart costs a bit more, but it's also much more useful, as it can loads basically any rom ever made. So it depends on your needs. I'd really avoid using the STC cartridge. It stresses the chips when in use as it continuously cause bus contention in the entire address space. There's the risk of damaging the console you're trying to fix by using it. (see this post). It's supposed to help finding issues with the address and data lines (shorts or broken traces), but you can do that safely by inspecting the board using a multimeter and/or the scope. Anyway, as you notes, it's just a bunch of resistor, therefore if you really want one, the cheapest and easiest way is to build it (see the schematic here). Only the 8 data pins plus ground and +5v are used, so any game cartridge can be used as a donor for the board. The same applies to the shorting plugs to be used with the diagnostic cart: you only need 2 DE-9 plugs and a few discrete components. The schematic is here. You can skip the led and related current limiting resistor. It's just there to show that pins 7 and 8 of the controller port are connected to GND and +5V respectively, which you can test using a multimeter instead.

The first rom shows very minor jitter on the CRT I use. The screen jumps up and down 1 scanline about once per second in the title screen, and about twice as fast during gameplay, but without showing color loss. The second rom is stable.

VSYNC timing is off. You should enable/disable it at the very beginning of a scanline (that is, right after a "sta WSYNC"), so to have three full scanlines with VSYNC on. Instead, you're enabling it at cycle 31 on line 259, and disabling it at cycle 5 on line 262/0. Rearrange the code to strobe WSYNC right before VSYNC, or just use the "VERTICAL_SYNC" macro that's in "macro.h"

Sorry for the late reply, I missed that question. It's just this short paragraph on a single page. I think it was part of scans of one of the various versions of the Stella programmers guide, but I usually split / clean / ocr those scans when I get them, so I don't remember where I downloaded it from. Sara_Programming_Instructions.pdf

Color bleed and other artifacts might happen on digital TV too. In fact they can even look worse than on a CRT, due to the poor analog to digital video conversion done by the TV. A screenshot would help figuring out what's happening. Also, what are you using to load the rom on your 7800? You said that you encounter glitches with other 2600 games on that console, and that's definitely not normal. Are you using a Concerto cart? If so, ensure to flash the latest firmware, as earlier versions had a bug that caused issues with 2600 games.

There's no point focusing on the "TV TYPE" switch for this issue. That switch is completely unrelated to the video circuit, as you can see from the schematic. It just connects to an I/O pin of the 6532 "RIOT" chip, just like the other 4 switches (other than "POWER") do. The console switches are just inputs that can be read by the game program (in the same way as the joysticks) and it's the program itself that determines if and how to react to them. Demon Attack and E.T don't check the TV TYPE switch position at all. Before powering the soldering iron or thinking about replacing chips and components, have you tried to adjust the color pot?

Those games work fine with the simplified protocol, but they actually store values with D0 set to the hotspots, and since this involves using a little bit of extra rom and cycles, it suggests that the real CBS scheme works as indicated in the patent. So the original games work with the simplified method, but new games written for the simplified scheme wouldn't have worked in an original CBS chip. I agree that there's not much point in implementing this now (and it might break homebrews, hacks and demos that use the simplified method), but maybe it could be documented and/or generate a warning. The same could be done with the code executed from SARA ram. The difference is that while you can actually build a cartridge with original SARA ram, by scavenging the old chips form original carts, or if you find some new old-stock ones, you cannot realistically reuse the original CBS bankswitching circuitry, as it was built-in a single chip together with the mask rom. Even in case of SARA, though, it doesn't make much sense to go that route when modern implementations such as "Melody" and "Aria" boards are available. There are a couple of "Wings" prototypes. You can find them on Atarimania. I don't know. For SARA, there's a scan of a page from original Atari internal documents that describes this behavior, but I'm not aware of similar docs from the other companies.

There are other cases where modern implementations have less restrictions. E.g., according to US patent 4,485,457, CBS scheme requires data bus D0 = 1 when accessing the hotspot: So bankswitching should only happen when you write to the hotspot address a value with bit 0 set (not sure if bits 1-7 are relevant). IIRC, modern flashcarts and emulators implementations only check if the hotspot is accessed and ignore the data bus, thus allowing bankswitching also on read operations. In case of CBS carts, the ram, rom and bankswitching logic are integrated into a single chip, so reusing that for an homebrew game would require some extra address decoding to select the chip only in the ram area, and separate eprom and bankswitnching logic. If the goal is only to test if code can be run from the cbs ram, you can copy the test code into riot ram and then swap cartridges before it gets copied into cart ram and the actual test starts, similar to how some cartridge dumpers work. As a side note, I played with the Magicard a bit in the past, and I actually like it a lot. Inputting code with it is not that bad, IMO. I concur that the keypads aren't the best for fast typing, but they're usable nonetheless, and I find the keys layout more intuitive than the one e.g. in the Kim-1 (which in its basic configuration shares quite a few similarities with the Magicard). The audio "beeps" compensate for the lack of tactile feedback of the keys. The "hex dump" and especially the disassembly function help to check the typed code for errors. In my past attempts I couldn't make the cassette interface described in the manual to work, but I plan to give it another shot some day. You only have about 750 bytes for code, as part of the ram is used by the monitor program, but I think that it is a great learning tool. Having to assemble your code by hand with paper and pencil (at least you don't need to calculate relative addressing for branch instructions, as the monitor has a built-in function that calculates those on-the-fly! 😄) gives a better understanding on how an assembler works, which might be useful.