Blinky

That's what it looks to me in the images. Solder(silver) color.

Th finish is called HASL and it's cheaper than the gold looking ENIG finish.

I did a tear down of Mr. Run and Jump here but it's great to see the internals of the 4-in-1 cart 👍 I'm surprised to see they added an actual 74LS04 and not one of the modern single gate chips. I guess it was cheaper. Yes but WE# is not connected to VCC but pulled up to VCC with resistor R1 so it's possible to reprogram the chip without desoldering it or lifting the WE# pin. 3.3V can interface with TTL but on noisy systems a cart may not work as reliably.

It's definitely parity related as the rom still passes when setting or clearing an even number of bits.

I just discovered you can swap bytes, nibbles and bits of a rom and it still loads fine (with the same working crc) so it is something to do with parity and/or bit counting.

256 download attemts is a long time. Would be cool if we can crack it. sofar I got two 4k and 16K rom pairs that produce the same crc (but have totally different regular checksums) Figured out the last two bytes (rom type) are not included in the crc calculation and the rom seems to load fine if these two bytes have random values.

Yes, I've also included the 5 byte header but didn't find any similarities (yet). I've modded my 2600+ now so I can stream the dumped roms but I need to figure out the crc now so I can load other roms too Yes tested a few. integrity check. Just to make sure the dump is received correctly over the serial link. The dumper only sends the dump once after the dumper has done all it's magic internally.

No those controller don't use electronics. Those controllers are made of a 4 by 3 key matrix. What they do is configure one of the up/down/left/right pins as active low output (to simulate a connection to GND) to select a row of 3 keys and read in those keys using the fire button and paddle inputs to determine which button was pressed. Here's a small diagram to help understand how it works. the blue lines indicate that that direction pin is configured as an active low output (GND). The blue symbols represent a low input at the fire / paddle pin when the corresponding key is pressed (unpressed keys are read as high input).

because it doesn't add up I don't agree with the random values bit of hot spots but that' doens't matter the dumper transmits the dump that it read, creates some crc and transmits that in the end of rom dump part. Also dumping the same cart multiple times with or without power cycle returns the same dump and crc When I change that crc value of a dumped rom, it won't be accepted. The dump only gets accepted when it has the same value as when it was dumped.

The SMS controller is a controller without electronics. The Genesis/Mega drive controller uses a (multiplex) chip that requires power.

there's a crc byte in the end of rom dump: 0x55, 0xAA, crc, romtype MSB, romtype LSB When the crc byte hasn't the correct value, the rom dump is ignored. It's not a simple checksum. Not sure what the algorithm is. BTW: I was able to stream a dumped rom back to the 2600+ with cart inserted (and dumper Tx disconnected)

The 0x99 ?? there isn't just a random value but some crc check to validate the dump.

I just figured this out too. It uses the CAR_TEST signal to tell the mainboard a cart is inserted (high for cart) if this pin is not high it chokes on the streamed ROM. So this pin needs to be disconnected as well. It can probably be controlled by the RTS pin of the USB serial cable.

Discovered the function of the CAR_TEST (CARD_TEST on the main board) pin. This pin is controlled by the dumper MCU to signal the mainboard that a cart is inserted in the slot. When there is no cart in the cart slot this pin is low. When a cart is inserted it is set to high and remains high until the cart is removed or a dip switch on the cart is changed. In case a dip switch is changed the pin goes momentary low and then high again (probably as soon as it detected the new game rom)

Alternatively you can heat up the solder joints of the two Tx pins on the header and push down those pins on the side of a table or something. That way if you ever want to restore the header pins, you can heat them up again and push them back.

sligtly confused as I wasn't talking about the kernal but about the Micro Controllers of which one handles the (joystick) controller ports and the other the cart dumper. Their programs are stored in internal flash memory and not in the mainboards nand chip.

Using a 2-In-1 Type-C Otg Adapter shouldn't be a problem if the power supply also works with the 2600+ Good to know. Maybe it works cause it only has a single power profile (5V/3A) or it's just a 5V/3A power supply with a USB-C plug. Anyway if a smartphone (fast) charger or a power supply with a USB-C connector or cable doesn't work and you wonder why it doesn't. It's because the USB-C on the 2600+ isn't fully compliant with the USB-C standard. Interesting. My serial is 21399. I also spotted the resistor in Ben's framed 2600+ image.

Note that the Atari 2600+ does not have USB-C it has a USB-C connector that is wired (incompletely) for USB 2.0. The incompletely part is that the USB-C standard requires 5.1K pull down resistors on the CC1 and CC2 pins to supply 5V. So if a genuine USB-C charger/adapter is used it will not supply any power. When you connect something to the micro usb port on the mainboard. The mainboard should not be connected to the I/O board otherwise there will be a collision with the 'USB-C' port of the I/O board.

The 2600+ functions as a USB controller when connected to a PC when the 'Stella Adapter' mode is triggered. I do not know if you can hook a USB controller to the 2600+ (have not tested this) for which you probably need a OTG cable.

Good to know that but what about the GNU GPL 2.0 Licence that says that source needs to be disclosed ?

I hope at that point the code is released and the community can carry on.

I'd say see what fixes can be implemented for an christmas update and spread the more complex / time consuming fixes at a later moment.

Same with 2600+ only the joystick ports are available over USB. The Select, Reset and difficulty switches seem to be only available to the rock chip. However if you wish to hook the 2600+ to the MiSTer then you could remove the main board and hook al the IO to the MiSTer. Don't know about MiSTer scripts but the Python code is easy modifyable. If the MiSTer script contents can be passed as a command line then you don't even need to modify the script.

Lol, Today. I discovered that when the 2600+ is put into 'Stella adapter' mode, the rom dumper also works ! Updated my Python dumper script to optionally launch the Stella emulator on each rom dump. You can now have the 2600+ experience but by using the Stella emulator on your computer

I have to correct myself on this. My testing was incorrect before. Connecting the 2600+ with a USB-C cable to your PC, putting the B-W / Color switch in the B-W position, pressing down game reset while powering on will put the 2600+ into 'Stella Adapter mode'. So you can use original controllers hooked to the 2600+ as a USB controller to play games with Stella on your PC (Joystick port 2 must be configured in Stella to work)