alex_79

The AtariVox will work just fine (the gate input are high impedance and do not affect the levels of the pins), but the pause mod can be triggered while the Atari communicates with the device. Whether this causes issues or not depends on the specific game. The fact that current games work fine doesn't exclude the possibility that future ones might have issues. The SNES2Atari adapter supported, for example, by "Attack of the PETSCII Robots" for the 7800, uses pins 1 and 2 to send the clock and latch signal to the SNES controller. The Savekey uses pins 3 and 4 for the I2C serial data and clock protocol. The "Compumate" for the 2600 uses pins 1-4 on both ports for the bankswitching of the Computer ROM. There are some roms that use the ports to communicate with a computer serial port, or to drive external devices, and it's possible, for example, to use them to connect two consoles and play multiplayer games that way... The 2600RGB mod uses a similar method of "impossible combination of inputs" to add an extra SWITCH on the controller to allow for remote RESET and SELECT switches, as well as an hardware PAUSE (it halts the CPU) and a PALETTE select function. That proved to be incompatible with the mentioned trackball games (which caused disappointment to the unaware customers), but also in other cases which are less obvious: e.g. "Track and Field" is unplayable (with a standard joystick, not only with the "Track and Field" controller that allows to press left and right simultaneously) if you have a RGB mod with the extra function wired to the controller port. And doesn't matter if you actually have the extra switch installed on the joystick. That's because, for whatever reason, the code in the game briefly pulses pins 1-4 LOW in both ports on each frame! My point is that the pins on the controller ports are general purpose Input/Output ones, and the game code has full control over them. Not only different controllers can pull up/down different combination of inputs, but the code itself can drive them directly, even when nothing is connected to the port, and the pause mod cannot tell the difference. The possibilities are infinite, and new games and controller/devices keeps being developed. That's why I suggest to have a switch to disable the function: if you ever encounter a game (or controller or device) that conflicts with it, you can just temporarily turn it off.

Nice mod and very clean job! A couple of notes: 1- You don't need to wire the second port, but you cannot just leave the inputs of a logic gate unconnected, else they'll show erratic behavior, electrical noise and increased power consumption (especially with HC/HCT family ICs like in this case). Simply tie "2U" and "2D" inputs on the mod board to +5V if you don't want the pause function for the second port. 2- Consider adding a switch to disable the mod (e.g. break the connection between the "PB" output of the board and RIOT pin 21). Else, some controllers such as driving controllers and trackballs will trigger the pause (or B&W switch in 2600 mode) function. This can also happen when a game uses the ports as outputs: for example, pins 1 and 2 ("up" and "down" in a joystick) are used to interface with an Atarivox, and the RIOT outputs can be set simultaneously LOW by the code while trying to communicate with the device, even if nothing is plugged in the port, and that again will trigger the pause/B&W switch. Given the number of different controllers and devices (and the new ones that the homebrew community keeps developing), and the great flexibility of the 2600/7800 controller ports I/O pins, there isn't a combination that is really "impossible". There will always be some game or device that will trigger it, so you need to be able to disable it if needed.

Stella is one of the most accurate 2600 emulator available and runs basically every known game. But it needs a rom. The issue here is the cart dumper: a cart dumper is just a cheap trick to give the illusion of playing real cartridges. But it's a trick. It works in a completely different way compared to a real console and it will never replace the real deal. As explained by @MaximumRD, the dip switches are an easy way to circumvent the limitations of a cart dumper. Dumping a multicart with a menu would complicate things a lot (and in case of flashcart using sd cards, you need real time access to the cart port, which is not how a dumper works). They could at least have used a rotary hex encoder: Instead of setting 4 tiny switches, you just rotate the shaft (with a nice knob installed on it, maybe) to select one of the 16 positions. Note that something like the above encoder would likely be a drop in replacement for the bank of 4 dip switches they put on the official cart (same size, and likely doesn't require any modification to the board to work), so it would be a quick DIY mod... I can't argue with that! 🤣

Yes, absolutely. My post was just meant as an explanation of why you got that specific behavior with the Test Cart, but the diagnosis still stands: the TIA is toasted.😄 I don't think it is possible. It's not only that you need to watch the CPU address and data bus to see when the program writes to the TIA register used to turn those transistors ON and OFF (not impossible, but surely complicates things a bit), as that "DUMP" signal is not available outside the TIA, but the fact that you'd need to remove the bad transistor from the circuit for this to work!

I think the issue is that the "dumping" transistor (in red in the attached excerpt from the TIA schematics) for that paddle line is bad (shorted). Each paddle line has one of those and they are activated (all 4 at the same time) by the "DUMP" signal shown in the diagram, which is under software control (the program writes to a TIA register to enable or disable it). The purpose is to discharge the capacitors attached to the paddle lines. After doing so the program disables the transistors again and then keeps checking the paddle lines and measures the time it takes for them to switch to a digital "1". That time is determined by the RC circuit formed by the (fixed) capacitor in the console and the (variable) resistor in the paddle controller itself, and it's therefore proportional to the position of the pot. That's how 2600 games read the paddles. The bad transistor is the reason why you don't see the pulses on the scope. Note that the TIA paddle inputs are strictly DIGITAL (they only read "1" or "0"), and apart for those additional transistors, they're identical to the joystick triggers ones. The "shorted" transistor results in a low resistance between the paddle input and GND. When you have a paddle controller plugged in, you add another variable resistor between the line and +5V, obtaining a simple voltage divider. And so depending on the position of the pot you either get a logical "1" (voltage above a threshold value) or "0" (below that value). The cap is never discharged and just keeps that same voltage determined by the divider. So there's no charging time to be measured. That's why the paddle just sits either on one or the other side of the screen in the Testcart.

I'm pretty sure that anything using extra ram on cartridge (e.g. SARA RAM) is on an Aria board. And probably things using some less common bankswicthing scheme (something different from Atari F8, F6 and F4). But I don't think there's a list of games using it, and as you said, the board has been mentioned a few times by Al, but there's not much info about it apart the fact that it uses a less powerful arm chip compared to the Melody. Yes, absolutely. I mentioned that just to explain that the presence of the arm chip on the board doesn't always prevent the cart for being dumped. I 100% agree. Just to add another example: "Custer's Revenge" (lots of 2600 "porn" games in that list!) is listed twice! The second time referred as "Swedish Erotica: Custer's Revenge". One is marked as "pass", the other as "untested"....😄

A couple of corrections: Melody and Aria board can in theory work, but only if they're just emulating one of the standard bankswitching schemes and the arm is not used as coprocessor for the game. There might be some issues with the timing: if the dumper accesses the cart too fast, the arm inside might not be able to respond in time, as those boards have been designed to work at the speed a real 2600 has. Eprom/roms might be more tolerant to differences in timing. I think that Melody boards are used for the arm enhanced games, but Aria ones are mostly used for some uncommon (but conventional) bankswitching schemes and for ram on cart, which is difficult to implement otherwise due to the 2600 lacking some timing signals on the cart port. In the past I used an Harmony cart to test a 2600 cart dumper with standard bankswitching schemes for which I didn't own any real cartridge, by flashing it with the usb cable in "single game" mode, that is overwriting the standard bios. In that case it basically becomes a Melody board, and I could dump it just fine. (My dumper was just a software running on a standard 2600 console, so the timing was exactly what the Harmony/Melody was designed for.) Extra ram is typically not an issue: you can dump a cart with it and it is Stella that will then detect that the game uses it and emulate the ram as needed. I think that Pitfall II can be be dumped as well (and Stella emulates the chip), but it might be tricky to detect and probably not worth complicating the dumper software just for one game. Of course it all depends on how good the dumper hardware and software is when the 2600+ finally ships, and how easy will be to update it after the fact (and if someone will work to add more cart types to it). The initial compatibility list that was published on the official site only listed as working a few standard cart types.