alex_79

2600 words uses the savekey/atarivox eeprom to save data. Stella emulates the eeprom with a file and its location depends on which OS you're using. See here: https://stella-emu.github.io/docs/index.html#AtariVox

The Wico trackball for the O2 only differes from the one for Atari for the pinout of the plug, and the fact that it has an external power supply, since the O2 doesn't provide power to the controller ports. That trackball only works in "joystick emulation" mode, that is it sends pulses to the pins for the joystick directions whose frequency depends on how fast you're spinning the ball. Above a certain speed the pulses become a continuous signal. This has the advantage to work with any existing game that supports a joystick, but you don't get the feeling and precision that you can only obtain with a real trackball mode. The O2 Wico trackball is designed to work with an O2 with detachable joysticks. If you want to use it with a console with wired controllers, you simply have to install two DE-9 ports following the O2 pinout. Anyway, if you're already modding the console, it's just best to use the Atari pinout and, as long as you provide +5V to pin 7 (either by soldering a wire to the motherboard, or by using an external adapter), you can also use the various trackballs made for the Atari. The Wico trackball exists (and is more common) for the Atari, and then there are the Atari branded CX22 and CX80. Most of CX22 and all CX80 trackballs have a switch to select between "Joystick mode" (like the Wico) or true "trackball mode". The latter requires games to be specifically coded to use it, but provides the true trackball experience. Yes driving controller would work just fine (and they don't need power). Just like "true" trackball, they require games to be specifically coded to use them. Amiga mice and trackballs as well as Atari ST ones could be used too with Atari compatible ports that include power on pin 7

The 5 pins used for the Odyssey2 joysticks are digital input-only signals. BTW, On Atari consoles and computers, paddle inputs are digital too: the position of the knob is determined based on the recharge time of a RC circuit formed by the varaible resistor in the paddle itself and a capacitor inside the console, which gets periodically discharged through a transistor. In any case, the Odyssey2 doesn't have paddle caps and discharging transistors, or any alternative circuitry to support paddles.

The unused holes you see on the top of the board are made at the factory, as that's where the original contact switches were soldered. On the other hand, the additional holes to fit the microswitches (circled in red) are quite obviously made by hand and definitely not very precise. For the fire button, a second set of additional holes was made, probably as the result of a mistake, and this is even easier to see there (yellow arrows) as there's no solder covering them. As I said, I believe the caps on the spring are cut from the original cx10 plastic plate: they are a perfect fit because the springs are supposed to go in there even on an unmodified controller. Considering also the jumpers, the solderjob on the bottom of the PCB, and the metal disc used to actuate the switches, it definitely looks homemade to me.

I don't think that's original, but rather a custom modification done by a previous owner. The PCB is the one used in the early CX10 with the rectangular contacts (like the one in this thread), and your pictures show that it has been drilled and jumpers have been added to it on the solder side to fit the microswitches. The black round pads under the springs seem to be cut from the plastic piece that sits over the contacts in the original. I attach here the relevant pictures from the linked thread for comparison:

I got the same error yesterday, but it seems to be fixed now.

With a bit of wiring, you can use any non-reprogrammable 8048 by disabling the internal rom and use a separate eprom for the bios: https://videopac.nl/forum/index.php?PHPSESSID=e1fb83d72e18a5707a57a80d2dbf9074&topic=1797.0 That thread is about a videopac+ g7400, but it should apply to the g7000 and Odyssey 2 as well.

There's a dedicated Atari 2600 Hacks subforum where you can share your hack, and it would surely be more visible there than on the hack page of the main site. That page probably hasn't seen any update in almost 20 years. I think It's there since the early days of AtariAge when the scene was still small and was still manageable to keep track of all the hacks.

Indirect indexed writes (e.g. "sta (pointer),y", where "pointer" is a zero page address), when there's no carry in adding the Y index, perform an "extra" read access (the value read is discarded) to the destination address one CPU cycle before the actual write. If, instead, adding the index results in a carry (page crossing), that extra read is done to a different address, after adding the Y index to the LSB, but before incrementing the MSB. The next cycle after that, the write is performed to the correct address, with the carry added to the MSB. In case of cartridge ram in a 2600 game (that uses an address bit instead of the R/W signal from the CPU to differentiate a read from a write operation, since that signal is not available on the cart port), a read operation can cause a write if the address is in the "write port" area. The value written is undetermined, since neither the CPU nor the RAM chip are driving the data bus in that case. So, if you write to cartridge ram using indirect indexed addressing mode, and there's no page crossing, there are no consequences: the extra read will indeed corrupt the byte at the destination address, but on the next cycle the correct value will be written. If instead, there is page crossing, and the address with the same LSB but in the previous page is a "write" address for the cartridge ram, then it will be corrupted. Stella has an option to break on such "reads from write port" in the "developer" menu. That option is enabled by default if you enable "developer mode", while it is normally disabled in "player mode". In this example you see Stella reacting to one of such cases: circled in green is the message indicating what caused the break: "RWP[@ $1500]: $18e7", that is read from write port at address $1500 casued by instruction at $18e7 ("sta (ram_82),y"). The pointer at ram_82 is $15f6, and Y is $a. The resulting address is $1600, and because of the page crossing, there's an access to $1500 that corrupts that byte in ram.

breakif _scanEnd!=#262 _scanEnd is the scanline count at the end of the last frame.

Maybe, but I'm more inclined to think that the 6507 went bad with age, since "Berzerk" is a quite popular game and I imagine we would have had more reports of this issue by now.

That's why this issue is so weird: a fault in any CPU register would normally cause almost all games to crash. Instead here it would pass mostly unnoticed. I think Activision's "Decathlon" would likely fail as well, as the bankswitching relies on the return address pushed onto the stack, and maybe an handful of other games too, but most of them would run just fine. Without knowing in advance what chip was the culprit, @DEBRO's findings would have led me to suspect the RIOT (bad bit in zeropage ram), but surely not the CPU.

Here is a simple one I put together: PC_test.zip It just displays two columns of 8 hex values each. The program jumps to an address with the high nybble (4 most significant bits) corresponding to a value in the left column, then calls a subroutine from there and reads those same bits of the return address pushed onto the stack (right column). On a working console, the two columns will always show identical values. @TissueLint, if in the future you'll be able to load roms on your console (e.g. using an Harmony cart, Unocart, Pluscart or a Supercharger), and you still have the faulty CPU around, please consider trying it. I'd be curious to see the results.

Thanks for the analysis. Very interesting. I've been very curious about this since this thread was posted. Maybe there's a bad ram cell inside that 6507, and in particular bit 13 of the program counter register is "stuck" low? Since the 6507 doesn't have an external A13 address pin, I imagine most games would still behave correctly when using a cpu with that specific fault, and the different value of that bit stored into the stack when jumping to subroutines wouldn't usually have any effect. Berzerk being evidently an exception. (EDIT: Activision's "FE" bankswitch would likely have issues as well) It should be easy to test this theory running a test rom with the offending 6507.

The hardware provides 2 extra buttons connected to the paddle lines (so, 3 in total), it's just that the game "Omega Race" assigns the same function to two different buttons (but it reads them separately, as they are independent and read on different TIA registers). The difference with the "joy2b+" mentioned above, is minimal: - The booster grip connects the paddle lines to Vcc (+5V) when you press the button (which will rapidly charge the paddle capacitors), and leaves them unconnected otherwise. The program needs to discharge the paddle capacitors once on each frame, and then will read a "1" on bit 7 of the paddle registers if the corresponding button is pressed, "0" otherwise. This is the opposite of what happens with the standard cx40 button. - The joy2b+ has pullup resistors always connected to the paddle lines (which recharge the paddle capacitors when the buttons are released) , and in addition it will tie them to ground when the buttons are pressed. The program reads a "0" on bit 7 of the paddle register if the corresponding button is pressed, "1" otherwise, just like the standard button. The genesis controller works in the same way, but only uses one of the paddle lines.

It is possible and has already been done:

No. Playing a NTSC rom on a PAL Atari results in a PAL-60 signal. A NTSC compatible TV is useless, since a PAL console will never output an NTSC video signal. The wrong colors are the result of the PAL TIA chip having a different palette compared to a NTSC one. There are a lot of PAL60 hacks here on AtariAge (e.g. in this thread) that you can use with a Harmony cart. Those will show correct colors on a PAL machine.

Or you could build an optical encoder, like in this (over 20 years old!) example: https://web.archive.org/web/20091027042913/http://es.geocities.com/gamemasterquilpue/indy500hack_e.htm Nowadays, most of the parts could be 3d printed.

All the "all-black" CX22 that I've seen over the past years are the joystick-mode only versions, and all the dual-color ones are the JS-TB switchable version. Anyway, there's always the possibility that the switchover between the two PCB versions didn't coincide with the changes in the outer shell and that a few switchable all-black or JS-only dual-color models might have been produced. The only way to be sure is to check for the presence of the switch on the bottom half of the shell. CX-80 models are always dual mode. FInally, consider that what said above applies to stock units. It was not uncommon for people to modify the Atari trackballs (both CX-22 and CX-80) to work with different computers (e.g. to behave lika an Atari ST mouse, or an Amiga one).

I'm not an expert by any stretch of the imagination, but I think that's normal for the /BLK (blanking) pin to not show any activity, being TIA outputs open-collector and given the fact that pin 6 is likely unused and therefore left unconnected on a SECAM machine. You'd need a pullup resistor to show something on a scope. That pin is only used on some NTSC revisions (6-switch and some later 4-switch models). PAL TIAs don't even have the pin at all, as blanking and black levels are the same for PAL.

SECAM VCS should output on channel UHF 36. Anyway, at least the two LCD TVs I tried cannot seem to find the signal from my SECAM console when doing an automatic scan. I have to manually set the channel and specify "system-L" and "SECAM" in the options.

Paddle inputs (I0 to I3) are digital and use the same Schmitt trigger circuit as the joystick button inputs (I4 and I5). You can't read a variable voltage from those: you will only read a digital "1" if the input is above a threshold value and a "0" otherwise. When reading paddles, there's a fixed +5v voltage applyed, and the program measures the time it takes for the input to switch to a digital "1". That time depends on the RC circuit formed by the capacitor inside the console and the variable resistor in the paddle itself. It doesn't seem to me that it can be of any use to sample an audio input.

You could try this replacement crystal, instead of scavenging it from a working console: https://console5.com/store/atari-2600-ntsc-color-crystal-oscillator-c015510-replaces-3-579575-mhz.html/ According to the description it is a slightly different value (3.579545 MHz instead of 3.579575 MHz), but it is said to work just fine.

Maybe it's an issue with a chip revision like happens for some CDFJ games, and the 2k4k driver needs to be updated as well? That feature works fine in my two (Standard, not Encore) Harmony carts. In the meanwhile, If the F8 driver works, you can double a 4k rom, that is concatenate two copies of the same bin, or "quadruple" a 2k one and load it with the F8 driver (you might need to manually specify it, as auto-detection might fail). In that way, even if your game hits the $1ff8/$1ff9 hotspots, it will switch to the other bank containing identical code, and so the program will just continue as if nothing happened.

Yes, it would be nice to properly archive those tapes as they won't last forever. Anyway, probably they can be reconstructed from the emulator code and the available samples.