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.

That is not possible with USB-C because the direction of power is no longer fixed (Also cables have the same connector at each end so a cable could be connected either way). One could (unintentionally) connect two adapters/chargers together (a phone in charger mode connected to a charger for example).

yes but the device must indicate which power profile it wants. The 2600+ doesn't do this so the 'better' adapter / cable will not supply any power when it's not requested.

FYI if a cart is inserted the dumper doesn't sent data until the mainboard opens the serial port (opening the /dev/ttyS0 port sends a single byte 0x95 over Rx to which the dumper responds) so if your theory is correct USB mass storage would work if a cart was inserted into the 2600+ but I think the reason is how all the USB signals switched on the I/O board. I drew a diagram on how it's basically wired: you can see that the Micro USB is in parallel to USB1 that goes to the analog switch chip U6. in normal operation the USB-C port is connected to USB1 so it will cause interference with the micro USB port. From the firmware update info and other discoveries we know the following switching combos: TV TYPE LEVER MODE B-W GAME SELECT DUMPER B-W GAME RESET INPUT CONTROLLER COLOR GAME RESET MAINBOARD MASKROM MODE The TV Type switch is hardwired to Analog switch chip U6. When put in B-W position, only the dumper or input controller can be selected. The connection to USB1 should then be open and there shouldn't be any interference on the micro USB port. so I'm curious. If you have the mainboard connected to the I/O board with the TV type switch in B-W does Mass storage work for you? If it doesn't will inserting a cart make it work stable ? (dmenu.bin should not be running as it sends serial data to the dumper every ~5 seconds)

Yes. Power and a USB drive must be connected at the same time. a frankenstein USB-C OTG with power (Y) cable is needed as USB-C compliant versions will probably not work. The micro USB on the mainboard is connected to the USB-C connector of the Atari 2600+. It can only be used when the mainboard is not connected to the I/O board of the 2600+

One side of the Y cable has probably only power wires (no data lines). What if you supply power using the USB-A to USB-C cable to the female USB-C part of the Y cable and connect the USB controller to the USB-A connector? Also is the TV-Type switch in the COLOR position?

Basically what I was saying is that there is no officially supported method to hook power and a USB drive to a 2600+ that could be advised for updating the firmware using a USB drive without voiding waranty. The end user can ofcourse make any form of contraption that allows hooking up a USB drive and feed power into the 2600+ at the same time at their own risk. Best method for platform independant updates would be for the 2600+ to function as a mass storage device so a firmware file can be copied onto the 2600+ but it would need an update first to support this so we have a catch 22 situation. Probably the cheapest chinese variants are the ones that will work. If I would purchase such a cable I would probably get a micro USB OTG cable and use a micro USB female to USB-C male adapter so I would know for sure there is no USB-C smart stuff going on. That micro USB female to USB-C male adapter is also great to reuse with old Android phone chargers. Problem with USB-C is that it is invisibly more complicated then before. Pre USB-C each end of the cable had a different connector (not counting cursed cables) so you could only connect one host (PC) that delivers power to one device (or hub). With USB-C each device has the same connector. So there is no difference anymore which side of the cable goes where and what is hooked up. You could hook up two hosts at the same time. Because of this power needs to be negotiated before it is supplied on the USB-C cable. For this reason USB-C compliant power adapters and hubs and cables may not work with the 2600+ as a matter of fact (according to line 131 of the S50launcher script) OTG mode is already activated. You could try hooking up a USB game controller to it and see if it works.

Hardware wise OTG can not be selected. Mini and Micro USB have an ID pin to select OTG mode with USB-C there is no ID pin to select OTG a different method is used. Unfortunately the USB-C port on the 2600+ is just a USB 2.0 port using a USB-C connector. OTG is a means to turn a USB device into a USB host. That can be done trough software in our case the rockchip but the bigger issue is that power must also supplied and that can't be done as the 2600+ also needs to be powered through it's USB-C port. Power can only be supplied by using frankenstein solutions. Like one could use a USB-A male to USB-A female 'power only' USB cable (ie no data lines) or a USB-A power adapter with a so called USB condom inserted into it and then connect a USB-A to USB-A extension cable to that and insert a USB drive with both a USB-A and USB-C connector. Basically putting the USB drive in series with the USB power supply.

I wonder if people realize that the 2600+ hardware is (mainly) developed by chinese companies and it must be developed fast and costs must be kept low so they use their knowledge and tools they have available to do so. When a manufacturer of some chinese MCU only offers Windows tools they'll just have to use those. Being able to update the 2600+ is a feature of the chips used in the 2600+ and they rely on the tools supplied by the Manufacturers. There is no luxury of creating new tools for other OSes for a niche product because it would cost too much. One thing they could do though is to open more up and make use of communities expertise. There are all kinds of experts here (not saying I'm an expert).

I loaded the Galaga 7800 PAL rom onto my 2600+ 1.1 and the stuttering I experience is the same issue as with 2600 PAL games. I killed all but one alien so I could just fool around with the ship moving left and right and watch the animations. Animation is smooth for a while and then stutters for several seconds and returns to normal for a while and repeats. I wonder if it's a GPU (rendering) issue especially since I discovered I can configure my PC's graphic card for 50HZ and play PAL 50 Games smooth on my TV using PC Stella.

The CPU can have trouble keeping up. In the Bang! PAL50 demo part 7, the greetings part. emulation slows down considerably once the UFO launches and the colorful background animations appear. you can watch it here.