Blinky

Retroarch is executed with the switch -c /tmp/retroarch.cfg so /tmp is where it is. The S50laucher script copies the config file there from /oem/retroarch/retroarch.cfg

my PAL dig dug and Fatal play fine too (not counting the 50/60 Hz issues). I dumped both roms on the 2600+ and noticed something interesting. on Fatal run the RAM sections all read FFs except the section at offset 0x6000 that one reads as all 00s. Dig dug is even more interesting. All ram sections are different but the 128 byte write section contains the same contents as the 128 byte read section. With @Thomas Jentzsch knowledge that SC RAM is slow. I'd say the dumper reads out the data stored in ROM that is normally not accessible but since the dumper is faster than than RAM. it reads the rom before the ram data is enabled/output. The data read is probably junk that was in memory when the source code of the game was assembled. two sections that cointain mostly ASCII: Offset 0x1000: Offset 0x2000:

So I looked through my USB stuff and made a cursed contraption to power the 2600+ through the USB-C connector and hook-up a keyboard (or other USB device): Found out the following keys: ESC exit game F1 menu F2 save game state F4 load game state F9 toggle sound on/off O exit game P pause game on/off H reset K pause on only L faster speed while pressed ASZ + cursors for joystick 1 SPACE - toggle max speed on/off When exiting the emulator with ESC or O, the loading screen (from dmenu.bin) will appear again but ends up in loading failed as the dumper doesn't (re)send the dump. The cart has to be pulled and reinserted or the 2600+ needs to be power cycled.

Is the TV-type switch in B-W position? The Maze and collectibles are hidden in that case. A game reset with TV-type in color position will normally show the maze again.

when dmenu.bin receives a rom it creates a file "/tmp/.next" which is executed by the S50launcer script. the contents of the file will depend on the rom type. for a 2600 rom : cd /oem/vendor/bin/ ./retroarch -c /tmp/retroarch.cfg -L /oem/retroarch/cores/stella_libretro.so /tmp/atari2600.bin for a 7800 rom : cd /oem/vendor/bin/ ./retroarch -c /tmp/retroarch.cfg -L /oem/retroarch/cores/prosystem_libretro.so /tmp/atari7800.bin

admin rights are needed to install the rockchip driver.

I doubt it. I think the circuitry has more to do with (the power input of) the micro USB connector. Since it is not used they decided to remove those parts and save on costs.

I guess I didn't read that thoroughly. I remember reading something about you receiving more bytes in your dump. Yes I was puzzled why my loader couldn't return to cart mode and used the TXLED of my pro micro to monitor CAR_TEST. I then noticed that the dumper wouldn't activate CAR_TEST after I inserted a new cart (while I had a rom loaded over USB serial and my pro micro kept the mainboards CARD_TEST active high) only when I released the mainboards CARD_TEST, the dumper activated CAR_TEST. At that point I knew the mainboard must sent something to the dumper. Connecting the power LEDs cathode leg to the RX pin (this is safe to do as the current limiting resistor is at the LEDs anode side) showed it lit up about every 5 seconds. Hooking up Rx to my logic analyzer showed the mainboard sends 0x95. I Don't know if the value is important though as in theory just the low start bit could trigger an interrupt on the dumper MCU. Does the dumper responds if you send a different value?

Production week 37 of 2023 vs production week 30. so somewhere between that time they decided to not need the parts below the 5V GND area and bypass it by the 0 ohm resistor.

Interesting, I spotted your mainboard has a little mod. There's a 0 ohm resistor (inside the red circle) where on mine and other boards there's a transistor (on your board there are also some parts missing). I don't think it has any effect on speed but I do wonder if that's the reason why the power LED lights up on some Atari 2600+ when a HDMI cable is connnected while power is off.

Earlier I mentioned that the I/O board Rx serial line wasn't used and I thought I had confirmed this when I reversed dmenu.bin as it seams to open the serial for for read only and also doesn't write anything but opening the serial port actually sends a single byte 0x95 and the dumper happens to wait for this before it sends the romdump. Not sure how I missed this before! 🤦‍♂️ but this opens up new possibilities for my rom loader project like load a default rom when no cart is inserted on power up and being able to play a cart again after a has been loaded over serial

Interesting, looking at S50launcher I don't see anything that restores dmenu.bin. Must be some other process that does that. An unlucky cart / pcb that collected dirt at the bottom of a crate, accidently dropped somewhere during the production line collected dirt or some greasy fingers. Nice! it can fool the emu that there is a cart inserted. I wonder if the emu uses the same method to read the game select and game reset buttons. If it does then only games that don't depend on those buttons work. I wonder which process creates the original value now.

I haven't tested paddles yet, need to look for my original ones. I'm not sure how the paddles are handled I would think joysticks and paddles could be supported simultaneously as they use different inputs. I think I read somewhere there is some detection involved (can't remember or find where though) There hasn't been an update for the input controller MCU yet so it's still joysticks and paddles.

I'd say that's exactly whats missing

Yes. USB-A is a connector type. The 2600+ is USB 2.0 but just uses a USB-C connector.