jj_0 Posted January 4 Share Posted January 4 13 hours ago, Blinky said: been doing a bit more reversing on dmenu and found out that the CAR_TEST and switch inputs are read out by reading: /sys/devices/platform/gpio-keys-polled/keys The returned value will be: + 1 game select lever pulled down + 2 game reset lever pulled down + 4 TV type switch in B-W position + 8 player 1 difficulty switch in A position (according to rear panel label) +16 player 2 difficulty switch in A position (according to rear panel label) +32 4:3/16:9 switch in 16:9 position +64 CAR_TEST high (cart detected) That's interesting. They are also mentioned in the kernel log: [ 1.168134] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys-polled/key-sel[0]' - status (0) [ 1.168223] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys-polled/key-rest[0]' - status (0) [ 1.168284] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys-polled/key-bw-color[0]' - status (0) [ 1.168342] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys-polled/key-1PAB[0]' - status (0) [ 1.168401] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys-polled/key-2PAB[0]' - status (0) [ 1.168458] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys-polled/key-169-43[0]' - status (0) [ 1.168515] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys-polled/key-card-det[0]' - status (0) [ 1.169082] input: Deeplay-keys as /devices/platform/gpio-keys-polled/input/input0 Game Reset and Game Select are mapped to BTN_Z and BTN_WEST of the '/dev/input/event0: Deeplay-keys' device: [root@rk312x:~]# evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: Deeplay-keys /dev/input/event1: adc-keys /dev/input/event2: Retro Games LTD USBController Select the device event number [0-2]: 0 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "Deeplay-keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 304 (BTN_SOUTH) Event code 305 (BTN_EAST) Event code 306 (BTN_C) Event code 307 (BTN_NORTH) Event code 308 (BTN_WEST) Event code 309 (BTN_Z) Event code 310 (BTN_TL) Properties: Testing ... (interrupt to exit) Event: time 395.650274, type 1 (EV_KEY), code 309 (BTN_Z), value 1 Event: time 395.650274, -------------- SYN_REPORT ------------ Event: time 395.850086, type 1 (EV_KEY), code 309 (BTN_Z), value 0 Event: time 395.850086, -------------- SYN_REPORT ------------ Event: time 397.750285, type 1 (EV_KEY), code 308 (BTN_WEST), value 1 Event: time 397.750285, -------------- SYN_REPORT ------------ Event: time 397.950072, type 1 (EV_KEY), code 308 (BTN_WEST), value 0 Event: time 397.950072, -------------- SYN_REPORT ------------ Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 4 Author Share Posted January 4 nice to see references in to the gpio in the kernel log. So we now have 'key-card-det' CAR_TEST and CARD_TEST naming for the cart detection pin now that we're able to read out the cart detect pin. Your script could be adapted to check if a there is a cart is inserted on power up and decide whether USB or serial should be used. I've been reversing dmenu a bit more and I could patch it to make it think a cart is inserted but that would only work for the loading and not the emulators as they also read the state from /sys/devices/platform/gpio-keys-polled/keys. not sure if they can be patched as easy as they will likely use all of the gpio states. I don't see a way yet to how we can use the virtual USB RTS or DTR signals as a cart detect in software but for now we can insert and pull a dummy cart to load roms over USB Serial. something else I found out about dmenu.bin is how the test feature is triggered. I (re)created a test rom to trigger it (see attachment) The test mode can also be started manually from the terminal using below code. Note that a cart must be inserted otherwise the GUI test will terminate immediately. killall -9 S50launcher killall -9 dmenu.bin cd /oem/vendor/bin/ ./gui_test.bin "Hello Atari World" atari2600plus-testrom.zip 1 Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 5 Author Share Posted January 5 Loading roms with just software is possible but not as convenient as I want so I'm back to my hardware solution and working on mod-v2. This variant uses an 'Arduino' Pro Micro board that can be programmed as an USB to serial adapter with a few lines of code but with some more coding it can do more. Like flashing the power LED when loading a rom and auto switch between cart or usb loader mode Using an Pro Micro from another project for now until my Pro micro USB-C version arrives. So far I got the USB loading part working and it flashes the power LED when receiving a rom Note My Atari 2600+ uses the 1.1 beta update. In this version The Loading message on screen lags a lot. 3 Quote Link to comment Share on other sites More sharing options...
+karri Posted January 5 Share Posted January 5 Nice effect with flashing the led 😁. Quote Link to comment Share on other sites More sharing options...
Spanner Posted January 8 Share Posted January 8 (edited) On 1/2/2024 at 9:39 PM, jj_0 said: Thanks, it's based on the standard way of enabling USB composite gadget mode(s) via the configfs. It does seem that the A2600+ kernel only supports a single mode at a time though, normally the serial and mass storage modes work simultaneously. But I have tested it and it works for me. Your mileage may vary of course 😉 I haven't tried it with your Python script yet. I have tried to replay a dump from the the cartridge dumper, but I have spurious 0x95's being sent at the start by my PC that I haven't yet figured out where they come from, so the dump is not recognised correctly. All this with a cartridge in the cartridge slot so CAR_TEST would be set. I think you just found the problem with the USB Mass Storage:~ Quote kernel only supports a single mode at a time though, normally the serial and mass storage modes work simultaneously I guessed it was to do with the dumper not the Joysticks because it uses the same code thats from THEA500 Mini for its joysticks, you have to disable the dumper for USB Mass Storage to work. Edited January 8 by Spanner Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 9 Author Share Posted January 9 On 1/8/2024 at 5:46 PM, Spanner said: I think you just found the problem with the USB Mass Storage:~ I fail to see the link. The extra bytes where send/received over debug serial and the mass storage is connected to the USB port? On 1/8/2024 at 5:46 PM, Spanner said: you have to disable the dumper for USB Mass Storage to work. does the dumper chip actually use USB? I had the impression the dumper chip only uses USB for it's bootloader or did you mean the input controller chip? Quote Link to comment Share on other sites More sharing options...
Spanner Posted January 13 Share Posted January 13 (edited) USB Mass Storage does not work unless you disconnect the dumper from the serial, the kernel can only do one thing at a time, so if mass storage works when its disconnected(if you connect it to a switch to turn it off say) you could then put the roms on a USB Stick and then make a program or script the Atari2600+ runs so it loads the roms from the USB Stick instead of using a PC to do it. Quote kernel only supports a single mode at a time though, normally the serial and mass storage modes work simultaneously That means they only work one at a time, the kernel do not allow them to work together so one has to be disconnected for the other to work, I removed the I/O board from mine and USB Mass Storage works fine, as soon as I plugged in the I/O board it stopped working, and has a problem mounting the USB Stick. Then its portable... Edited January 13 by Spanner Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 14 Author Share Posted January 14 (edited) 10 hours ago, Spanner said: USB Mass Storage does not work unless you disconnect the dumper from the serial 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) Edited January 14 by Blinky 1 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted January 15 Share Posted January 15 In case anyone is interested, the root password can be bruteforced from /etc/shadow 😏 The root partition can be extracted from a firmware update. The password is "deeplay". 4 1 Quote Link to comment Share on other sites More sharing options...
Spanner Posted January 15 Share Posted January 15 (edited) On 1/14/2024 at 2:11 AM, Blinky said: 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 you are right having the switch on B/W it reads the USB Stick ok... no need to put in a cartridge. [root@rk312x:/]# cd /media [root@rk312x:/media]# ls usb0 usb1 usb2 usb3 usb4 usb5 usb6 usb7 [root@rk312x:/media]# cd /media/usb0 [root@rk312x:/media/usb0]# ls 'System Volume Information' 'rootfs-new-pw=chuckpeddle.img' rootfs-new.img [root@rk312x:/media/usb0]# Edited January 15 by Spanner 1 Quote Link to comment Share on other sites More sharing options...
T.A.P. Posted January 15 Share Posted January 15 Just a heads up, clean any games you put in the 2600+, even new ones! I was surprised and annoyed to discover that the copy of the new Enhanced Berzerk wouldn't work at all. I thought it might have gotten or something, then I cleaned it and discovered the contacts were filthy! It was only the third game I had played in the system, the other two were Mr Run and Jump and the 10 in 1 cart. I then had to spend 20 minutes cleaning the carts and system to get anything to play again. I'm just surprised is all. 1 Quote Link to comment Share on other sites More sharing options...
Spanner Posted January 16 Share Posted January 16 (edited) Now the the USB Drive works, you could now load games from it but they would be in Black and White so would need to find a way round that, you might be able to make a script to copy a game from the USB Drive to the /tmp folder where the game is created from the cartridge dumper, its called atari2600.bin I think. when you turn the machine on, what is the first binary its loads, is it the dmenu.bin or is it Retroarch, what binary is loading the Atari Logo ...? Edited January 16 by Spanner Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted January 16 Share Posted January 16 6 hours ago, Spanner said: Now the the USB Drive works, you could now load games from it but they would be in Black and White so would need to find a way round that, you might be able to make a script to copy a game from the USB Drive to the /tmp folder where the game is created from the cartridge dumper, its called atari2600.bin I think. Interestingly I can read the USB stick from the RGUI in normal boot, you just can't load new rom content without starting the dumper cycle. 3 Quote Link to comment Share on other sites More sharing options...
Spanner Posted January 18 Share Posted January 18 (edited) just doing some other tests and I tried to delete the dmenu.bin file and it rebuilt it on startup and I tried to swap it with a script with the same name and it still changed it back, so something is going on inside the S50Launcher script thats probably doing it. If you kill retroarch it restarts it again where it says `Loading Game...` On 1/16/2024 at 6:24 PM, remowilliams said: Interestingly I can read the USB stick from the RGUI in normal boot, you just can't load new rom content without starting the dumper cycle. How did you bring up the GUI, with a keyboard...? Edited January 18 by Spanner Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted January 18 Share Posted January 18 24 minutes ago, Spanner said: How did you bring up the GUI, with a keyboard...? Yes. Short summary: - you need a USB C to USB mini adapter and a USB mini OTG cable - connect USB mini power in and keyboard to the OTG, connect to the 2600+ - Use standard RGUI keys to navigate, F1, Z, X, backspace, etc I have a USB 2.0 hub connected to the OTG, and my wireless keyboard and USB stick connected to it. Quote Link to comment Share on other sites More sharing options...
Glorkbot Posted January 18 Share Posted January 18 On 1/15/2024 at 4:48 PM, T.A.P. said: Just a heads up, clean any games you put in the 2600+, even new ones! I was surprised and annoyed to discover that the copy of the new Enhanced Berzerk wouldn't work at all. I thought it might have gotten or something, then I cleaned it and discovered the contacts were filthy! It was only the third game I had played in the system, the other two were Mr Run and Jump and the 10 in 1 cart. I then had to spend 20 minutes cleaning the carts and system to get anything to play again. I'm just surprised is all. how could the contacts be dirty on a brand new game?! Quote Link to comment Share on other sites More sharing options...
T.A.P. Posted January 18 Share Posted January 18 (edited) That's what I would love to know. I bought it straight from Atari, and the contacts were so filthy the game wouldn't even load until I cleaned it for several minutes. Edited January 18 by T.A.P. 1 Quote Link to comment Share on other sites More sharing options...
jj_0 Posted January 19 Share Posted January 19 On 1/3/2024 at 11:49 PM, Blinky said: been doing a bit more reversing on dmenu and found out that the CAR_TEST and switch inputs are read out by reading: /sys/devices/platform/gpio-keys-polled/keys The returned value will be: + 1 game select lever pulled down + 2 game reset lever pulled down + 4 TV type switch in B-W position + 8 player 1 difficulty switch in A position (according to rear panel label) +16 player 2 difficulty switch in A position (according to rear panel label) +32 4:3/16:9 switch in 16:9 position +64 CAR_TEST high (cart detected) Interesting that the value in /sys/devices/platform/gpio-keys-polled/keys is actually a string representing the number instead of an 8-bit value. You can play around with it without changing the switches by overmounting it with a file you control: # echo 96 >/tmp/keys # mount --bind /tmp/keys /sys/devices/platform/gpio-keys-polled/keys 2 Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 19 Author Share Posted January 19 17 hours ago, Spanner said: just doing some other tests and I tried to delete the dmenu.bin file and it rebuilt it on startup Interesting, looking at S50launcher I don't see anything that restores dmenu.bin. Must be some other process that does that. 16 hours ago, Glorkbot said: how could the contacts be dirty on a brand new game?! 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. 1 hour ago, jj_0 said: You can play around with it without changing the switches by overmounting it 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. Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 19 Author Share Posted January 19 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 Quote Link to comment Share on other sites More sharing options...
jj_0 Posted January 19 Share Posted January 19 31 minutes ago, Blinky said: 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 Ah yes, I mentioned this a couple of times 😁. In my experiments I received a dump after sending 0x95. I also think (but I'm not sure) that the dumper only sets CAR_TEST high AFTER it receives the 0x95, do you see that as well? Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 19 Author Share Posted January 19 (edited) 35 minutes ago, jj_0 said: Ah yes, I mentioned this a couple of times 😁 I guess I didn't read that thoroughly. I remember reading something about you receiving more bytes in your dump. 35 minutes ago, jj_0 said: I also think (but I'm not sure) that the dumper only sets CAR_TEST high AFTER it receives the 0x95, do you see that as well? 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? Edited January 19 by Blinky Quote Link to comment Share on other sites More sharing options...
Spanner Posted January 19 Share Posted January 19 3 hours ago, Blinky said: 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. It was me, I forgot to type `sync` after copying over the dmenu.bin file. Quote Link to comment Share on other sites More sharing options...
Spanner Posted January 19 Share Posted January 19 (edited) Managed to run a game, Pole Position as a bin file, from the USB drive in Retroarch(Its built RA that loads carts) in the Atari2600+... and it in colour and the switch is on B/W... Next have to work out how to load 7800 bin files, this took me all-day on and off, and I have the flu... It runs a script instead of the dmenu.bin file, it see the dmenu.bin file, it replaces it just using a script you run from inside media/usb0 so it copies all it needs. Edited January 19 by Spanner 3 Quote Link to comment Share on other sites More sharing options...
ChrisKewl Posted January 19 Share Posted January 19 With the Atari 2600+ now rooted, will it require having a USB drive to play games or do you feel the storage onboard is adequate for that? Or do you think a homebrew launcher would take up the free space on the unit and USB would have to be put in place? I am curious because the Retron 77 can hold the entire Atari 2600 collection with the homebrew launcher. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.