Spanner Posted December 31, 2023 Share Posted December 31, 2023 21 hours ago, Blinky said: Got my rom loader working. Can load 2600 and 7800 roms over a USB serial cable. Some mods to the 2600+ are required though. Project is on my GitHub Here's a YouTube video of loading some 2600 and 7800 roms. Sorry for the poor quality beforehand. The Dumper works like the ARMGA Floppy Disk Drive does, the Drive is connected to the Cubieboard2 USB Serial or UART and is a PC drive and grabs the disk track by track but it can only copy cracked disks or ADF disks, not originals, they are protected so it can not copy them and not every disk works, if the disk has errors on it will not copy it. It a shame you can't do this thought the mini usb port on the CPU board usb-c but do under stand why you can't.. You need to show a diagram or where you solder the USB Serial on to what pins, it does not use its UART dose it, its the GND, TX, RX on jumper pins thats connects to the CPU Board and the Dumper/DB9 I/O board, is it the TX,RX pins...? Would be good to get this it work from a USB Stick then would not need a PC to do it... so it copies a rom.bin from a USB Stick and then runs it in the emulator. Quote Link to comment Share on other sites More sharing options...
doug0909 Posted December 31, 2023 Share Posted December 31, 2023 Is Keystone Koppers (7800) working? Quote Link to comment Share on other sites More sharing options...
Blinky Posted December 31, 2023 Author Share Posted December 31, 2023 9 minutes ago, Spanner said: You need to show a diagram or where you solder the USB Serial on to what pins I agree the documentation can be better but the mod-v1 folder contains images with wireing discriptions. If not using the switch The USB TX, RTS and GND can be soldered directly to the mainboard. If the USB serial cable has a header you could also solder jumper cables to the mainboard instead. Quote Link to comment Share on other sites More sharing options...
Blinky Posted December 31, 2023 Author Share Posted December 31, 2023 24 minutes ago, doug0909 said: Is Keystone Koppers (7800) working? I just loaded the demo rom from this post successfully over serial and can play the game. I did update my 2600+ with the beta 1.1 update a few hours ago so I'm not sure if thatdoes make a difference. (I was able to load games like that failing boxing game on the 1.0 firmware before though) 1 Quote Link to comment Share on other sites More sharing options...
Spanner Posted January 1 Share Posted January 1 (edited) Does the Rom Loader have to use a TTL-232-RV5, I have a CP2102 USB to TTL USB Serial, but it only has Rx and Tx on it..? You could put the FTDI Serial Adapter FT232RL inside the Atari2600+ so all you do is plug in the USB into it to use it so it like a extra cable plugged into the Atari2600+, just have to glue it into the right position inside the Atari2600+. I did use the FT232RL with my Atari800XL to load Disks images from my PC... Edited January 1 by Spanner Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 1 Author Share Posted January 1 2 hours ago, Spanner said: Does the Rom Loader have to use a TTL-232-RV5, I have a CP2102 USB to TTL USB Serial, but it only has Rx and Tx on it..? currently yes because we need to control the CARD_TEST input of the mainboard too. RTS or DTR can be used to control that. 2 hours ago, Spanner said: You could put the FTDI Serial Adapter FT232RL inside the Atari2600+ Yes ( i call it module instead of adapter). I'm currently using a cable cause that's what I have. One idea is to mount a small USB-C Serial module in the top right corner of the top cover and replace the switch with an 74HC4053 analog switch chip to auto switch between normal and loader mode. another idea is use an Arduino Pro Micro with USB-C connector or a Seeeduino Xiao these can act as a USB Serial I also got a USB serial cable with 2.5mm jack that also got only rx and tx (bought it before I knew the CARD_TEST signal is required for loading roms 😂 ) could probably add a small MCU to make that usable. need to think about it a bit more whats works best and easiest to build. 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted January 1 Share Posted January 1 I just ordered a module from ebay: FT232RL 3.3V 5V Adapter Serial Converter Mini USB zu TTL FTDI Module kompatibel | eBay The switch is already mounted to the top cover. With a little 3D printing magic I believe I have a nice micro-usb slot next to the switch. Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 1 Author Share Posted January 1 1 hour ago, karri said: a nice micro-usb slot The module you linked too seems to use a mini usb connector. 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted January 1 Share Posted January 1 It's ok. I have plenty of usb cables. Quote Link to comment Share on other sites More sharing options...
Spanner Posted January 1 Share Posted January 1 (edited) 11 hours ago, Blinky said: currently yes because we need to control the CARD_TEST input of the mainboard too. RTS or DTR can be used to control that. Yes ( i call it module instead of adapter). I'm currently using a cable cause that's what I have. One idea is to mount a small USB-C Serial module in the top right corner of the top cover and replace the switch with an 74HC4053 analog switch chip to auto switch between normal and loader mode. another idea is use an Arduino Pro Micro with USB-C connector or a Seeeduino Xiao these can act as a USB Serial I also got a USB serial cable with 2.5mm jack that also got only rx and tx (bought it before I knew the CARD_TEST signal is required for loading roms 😂 ) could probably add a small MCU to make that usable. need to think about it a bit more whats works best and easiest to build. 2.5mm jack, what a headphone jack...?, the Amstrad Emailer had one for its UART, the Amstrad Emailer was a Emailer landline phone but inside it it had a Arm chip , it was like the Atari2600+ its the same idea, it had a nand Toshiba and NOR flash, it had a emulator on it to so you could play ZX Spectrum games it download them, but you could only rent them so could buy them for a week then it deleted them, it was only ever made for the UK market, Amstrad would change users to use it because it had its own 56k modem so had it own internet connection so no need to sign up to one, it came out in 2000 Amstrad made 3 Models - E1, E2 Plus and E3, E3 had a Colour Screen The E3 was made in 2004 so before FB or YouTube, 20 years ago, and could do video calling, they closed its service down in 2011, the first of its kind, it was the first device that could run a emulator on it own, without needing a PC to do it, then the same idea was then used on Mini Consoles after the RPI came out, the Snes Mini, but the SNES was not the first Mini Console, it was the Amsted Emailer, even if it looked like a landline phone with 480p screen, it even had the ZX Speccy rubber keyboard that came out from under the headset. The E3 as well run Linux in the background MountVista Linux and was hackable to run a Linux shell on it 2.6.18. I know alot about them because I have all 3 models and wrote about them on Wikipedia and made a support forum for them, I want users to know that after 3 months(or sooner depending on how long the machine has been on for) they deactivate themselves and stop functioning, until its reactivated by the Amserve Service but it does not exist anymore so all the ones on ebay are crap, Amstrad never really supported it at the end and only allows users 2 weeks to get the configuration change that stops the device from deactivating, not long enough time. People are still selling them for £35 to £40 when they are worth nothing at all without the Configuration Change and none of them do. But it has worked now and stopped people buy them, when they are deactivated all the works is the clock on the home screen, you can't even make a call or receive one on it, its a shame, it was made to make Amstrad money, that all, and why its tech is now wasted. I am trying to hack the e3 firmware now to get it to work again but they have put all its data across the nand in Q;Q Blocks, it uses a cramfs file system but some of its files are scattered across the nand in the Q;Q Blocks, it to stop someone hacking it and getting passed the Daily Charge of 20p a day and stopping it. Edited January 1 by Spanner Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 1 Author Share Posted January 1 Nice, didn't know about that Amstrad emailer and it played speccy games? too bad it's so locked down. Back on topic. I updated my 2600+ with the beta 1.1 update and also reversed dmenu.bin again to see the changes. Nice thing is that Atari 2600 rom sizes are not so restricted anymore. It's supports rom sizes that are a multiple of 1K. I Updated my USB serial loader to support the new rom sizes. It loads Pitfall II now too 7 Quote Link to comment Share on other sites More sharing options...
Ben from Plaion Posted January 1 Share Posted January 1 3 hours ago, Blinky said: Nice, didn't know about that Amstrad emailer and it played speccy games? too bad it's so locked down. Back on topic. I updated my 2600+ with the beta 1.1 update and also reversed dmenu.bin again to see the changes. Nice thing is that Atari 2600 rom sizes are not so restricted anymore. It's supports rom sizes that are a multiple of 1K. I Updated my USB serial loader to support the new rom sizes. It loads Pitfall II now too Fascinating as always, but this method is not transferable to stock 2600+ hardware and software is it? Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 1 Author Share Posted January 1 (edited) A software solution is possible if the rockchip mainboard could configure its USB controller as a USB CDC device (virtual com port) (just like ums can configure the USB port as a mass storage device) in that case the 2600+ can be connected (and powered) by a PC and the PC would detect the 2600+ as a com port. When the above is achieved the dmenu.bin program would need to modified to detect and listen to this virtual com port so it can receive the rom dump. Also it would be good for dmenu.bin to support rom sizes in bytes (The BCD rom size in the serial 'header' limits rom size to multiples of 1K) my suggestion would be to use the most significant bit of the MSB of rom size as a flag to indicate BCD or binary size format. When set to '1' the rom size is in bytes and in binary format instead of the BCD format (by using this flag the dumper doesn't need to be updated / older dumper versions are supported) Edited January 1 by Blinky add romsize info Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 1 Author Share Posted January 1 Thinking more about it. having the USB port configured as mass storage device may be easier. the user can just copy a rom file over and doesn't need a PC client to transfer the rom. Quote Link to comment Share on other sites More sharing options...
jj_0 Posted January 2 Share Posted January 2 12 hours ago, Blinky said: A software solution is possible if the rockchip mainboard could configure its USB controller as a USB CDC device (virtual com port) (just like ums can configure the USB port as a mass storage device) in that case the 2600+ can be connected (and powered) by a PC and the PC would detect the 2600+ as a com port. When the above is achieved the dmenu.bin program would need to modified to detect and listen to this virtual com port so it can receive the rom dump. Also it would be good for dmenu.bin to support rom sizes in bytes (The BCD rom size in the serial 'header' limits rom size to multiples of 1K) my suggestion would be to use the most significant bit of the MSB of rom size as a flag to indicate BCD or binary size format. When set to '1' the rom size is in bytes and in binary format instead of the BCD format (by using this flag the dumper doesn't need to be updated / older dumper versions are supported) Possibly the easiest way to achieve this would be to copy /oem/vendor/bin/dmenu.bin to /oem/vendor/bin/dmenu-orig.bin and create the following /oem/vendor/bin/dmenu.bin shell script: #!/bin/sh X=$(cat /tmp/config/usb_gadget/g1/UDC) if [ "x$X" = "x" ] then exec 4>&2 5>&1 # backup the filedescr of 1 and 2 exec >/dev/ttyFIQ0 2>&1 printf "\nActivating serial port\n" WD=$(pwd) mkdir /tmp/config mount -t configfs none /tmp/config mkdir /tmp/config/usb_gadget/g1 cd /tmp/config/usb_gadget/g1 echo "0x04D8" > idVendor echo "0x1234" > idProduct mkdir strings/0x409 echo "jj0" > strings/0x409/serialnumber echo "jj0" > strings/0x409/manufacturer echo "Atari 2600+ serial or mass storage gadget" > strings/0x409/product # Config for serial port gadget if true; then mkdir functions/acm.usb0 mkdir -p configs/c.1 ln -s functions/acm.usb0 configs/c.1 fi # Config for mass storage gadget if false; then mkdir -p functions/mass_storage.0/lun.0 mkdir -p configs/c.2 echo 120 > configs/c.2/MaxPower echo /dev/rkflash0 > functions/mass_storage.0/lun.0/file ln -s functions/mass_storage.0 configs/c.2 fi echo "10180000.usb" > UDC echo peripheral > /sys/devices/platform/20008000.syscon/20008000.syscon:usb2-phy@17c/otg_mode exec 2>&4 >&5 4>&- 5>&- # restore stdout and stderr # Uncomment for shell on serial gadget # cd / # while true; do sleep 3; PS1='\u@A2600+ \w #' setsid getty -n -l /bin/sh 115200 /dev/ttyGS0; done & # Change serial gadget to /dev/ttyS0 for cartirdge upload rm /dev/ttyS0 mknod -m 777 /dev/ttyS0 c 242 0 cd $WD fi printf "\nStarting dmenu-orig.bin\n" >/dev/ttyFIQ0 /oem/vendor/bin/dmenu-orig.bin 12 hours ago, Blinky said: Thinking more about it. having the USB port configured as mass storage device may be easier. the user can just copy a rom file over and doesn't need a PC client to transfer the rom. But how would dmenu.bin detect this ROM or a change to a different ROM? 2 Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 2 Author Share Posted January 2 That's an impressive script. Is it concept or has this been tested? So it's very doable there is only an issue with a missing CAR_TEST signal but for the dmenu.bin developer it shouldn't be to much of an issue to test the ACM RTS/DTR linestate for a serial cart detect. Hope they see the value of it to implement this. It would be a great tool to improve emulation as dumper issues are ruled out when loading a rom over USB 9 hours ago, jj_0 said: But how would dmenu.bin detect this ROM or a change to a different ROM? Yeah thinking more about it, using a mass storage device isn't such a good idea. Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 2 Author Share Posted January 2 More hardware info. From exploring the dumper update tool 1.1.0.2 with a hex editor, I found out that the dumper MCU (and most likely the game controller MCU too) is a YSM3151 from YSTek Technology Taiwan. This is a 8052 based MCU with 45 GPIO, full speed usb support, 32K of (re)programable flash memory, 256 bytes ram (+ 1K external ram shared with USB controller) and runs (most likely) on 12MHz. The 32K firmware image can be found at the tools file offset 0x2ce300 Datasheet can be found here 1 Quote Link to comment Share on other sites More sharing options...
jj_0 Posted January 2 Share Posted January 2 54 minutes ago, Blinky said: That's an impressive script. Is it concept or has this been tested? So it's very doable there is only an issue with a missing CAR_TEST signal but for the dmenu.bin developer it shouldn't be to much of an issue to test the ACM RTS/DTR linestate for a serial cart detect. Hope they see the value of it to implement this. It would be a great tool to improve emulation as dumper issues are ruled out when loading a rom over USB Yeah thinking more about it, using a mass storage device isn't such a good idea. 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. 2 Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 3 Author Share Posted January 3 1 hour ago, jj_0 said: I have tested it and it works for me Nice! what's the easiest way to get the script on the 2600+ ? 2 hours ago, jj_0 said: I have spurious 0x95's being sent at the start by my PC Is the PC running linux? anything to do with modem manager? Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 3 Author Share Posted January 3 Oops! I just discovered that I drew the serial debug header pinouts for the mainboard on the wrong PCB image! in my earlier post. 🧐 Here's the correct order when facing the bottom of the mainboard PCB: Quote Link to comment Share on other sites More sharing options...
jj_0 Posted January 3 Share Posted January 3 (edited) 10 hours ago, Blinky said: Nice! what's the easiest way to get the script on the 2600+ ? Right now the easiest way would be to interrupt u-boot (CTRL-C) and export the nand oem partition via USB (connected to a PC) with the ums command: ums 0 rknand 0:7 Then you will have a new drive on your PC with the dmenu.bin in the vendor/bin directory. 10 hours ago, Blinky said: Is the PC running linux? anything to do with modem manager? PC is running Linux, with the modem manager removed altogether. <edit> Now tried with @Blinky's Python loader. It works after a few tries. Starting dmenu-orig.bin arm_release_ver of this libMali is r7p0-00rel0, rk_so_ver is '2', built at '15:17:56', on 'Jul 16 2020'. [init_my_display] formatName= SDL_PIXELFORMAT_ARGB8888 init_my_display: init success! ----- init_my_system ---ok --read_uart_stream--: cnt > 10 kk(0) <: --read_uart_stream--: cnt > 10 kk(0) <: --read_uart_stream--: cnt > 10 kk(0) <: --read_uart_stream--: cnt > 10 kk(4119) >: 00 00 F0 00 F0 00 F0 55 AA FD 00 00 EA AA 55 26 00 04 4C EF 00 00 00 00 00 00 00 00 00 00 F0 00 F0 00 F0 55 AA FD 00 00 +++++ a2600_7800=0,data_size = 0 +++++ --read_uart_stream--: cnt > 10 kk(0) <: --read_uart_stream--: cnt > 10 kk(0) <: --read_uart_stream--: cnt > 10 kk(4107) >: EA AA 55 26 00 04 4C EF F2 78 D8 4C 06 F3 85 2B A5 86 A2 00 00 00 00 00 00 00 00 00 00 00 F0 00 F0 00 F0 55 AA FD 00 00 +++++ a2600_7800=0,data_size = 4096 +++++ crc8 = 0xfd,crcori = 0xfd ++++ get card data ok++++ --deint_joystick_key 267 --deint_joystick_key 286 --uninit_my_display 155 --uninit_my_display 163 --uninit_my_display 170 --uninit_my_display 179 Note, I made a change to my original script, redirecting the dmenu.bin output to the UART: #!/bin/sh X=$(cat /tmp/config/usb_gadget/g1/UDC) if [ "x$X" = "x" ] then exec 4>&2 5>&1 # backup the filedescr of 1 and 2 exec >/dev/ttyFIQ0 2>&1 printf "\nActivating serial port\n" WD=$(pwd) mkdir /tmp/config mount -t configfs none /tmp/config mkdir /tmp/config/usb_gadget/g1 cd /tmp/config/usb_gadget/g1 echo "0x04D8" > idVendor echo "0x1234" > idProduct mkdir strings/0x409 echo "jj0" > strings/0x409/serialnumber echo "jj0" > strings/0x409/manufacturer echo "Atari 2600+ serial or mass storage gadget" > strings/0x409/product # Config for serial port gadget if true; then mkdir functions/acm.usb0 mkdir -p configs/c.1 ln -s functions/acm.usb0 configs/c.1 fi # Config for mass storage gadget if false; then mkdir -p functions/mass_storage.0/lun.0 mkdir -p configs/c.2 echo 120 > configs/c.2/MaxPower echo /dev/rkflash0 > functions/mass_storage.0/lun.0/file ln -s functions/mass_storage.0 configs/c.2 fi echo "10180000.usb" > UDC echo peripheral > /sys/devices/platform/20008000.syscon/20008000.syscon:usb2-phy@17c/otg_mode exec 2>&4 >&5 4>&- 5>&- # restore stdout and stderr # Uncomment for shell on serial gadget # cd / # while true; do sleep 3; PS1='\u@A2600+ \w #' setsid getty -n -l /bin/sh 115200 /dev/ttyGS0; done & # Change serial gadget to /dev/ttyS0 for cartirdge upload rm /dev/ttyS0 mknod -m 777 /dev/ttyS0 c 242 0 cd $WD fi printf "\nStarting dmenu-orig.bin\n" >/dev/ttyFIQ0 /oem/vendor/bin/dmenu-orig.bin >/dev/ttyFIQ0 Edited January 3 by jj_0 Typo + more info 2 Quote Link to comment Share on other sites More sharing options...
+karri Posted January 3 Share Posted January 3 That is a really nice and modular script. As I am also interested in how the dumper finds my carts I will keep my current serial hack between the dumper and the Rockchip. But I really hope they add this serial gateway to the main USB port. Dumping from the PC directly would be cool! 1 Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 3 Author Share Posted January 3 3 hours ago, jj_0 said: Right now the easiest way would be to interrupt u-boot (CTRL-C) and export the nand oem partition via USB (connected to a PC) with the ums command: ums 0 rknand 0:7 Then you will have a new drive on your PC with the dmenu.bin in the vendor/bin directory. Thanks. I'm on windows so the drive doesn't get reconized but I'll try connect the 2600+ to my raspberri pi later. 3 hours ago, jj_0 said: It works after a few tries. I was experimenting before I read your last post and managed to transfer a rom successfully too on each attempt. doesn't launch the emulator though as I have CAR_TEST disconnected atm (it loads the rom regardless of CAR_TEST pin). [root@rk312x:/]# oem/vendor/bin/dmenu.bin arm_release_ver of this libMali is r7p0-00rel0, rk_so_ver is '2', built at '15:17:56', on 'Jul 16 2020'. [init_my_display] formatName= SDL_PIXELFORMAT_ARGB8888 init_my_display: init success! ----- init_my_system ---ok --read_uart_stream--: cnt > 10 kk(0) <: --read_uart_stream--: cnt > 10 kk(4107) >: EA AA 55 26 00 04 4C CA F0 18 69 36 48 4A 4A 4A 4A A8 68 29 00 00 00 00 00 00 00 00 00 00 00 00 F0 00 00 55 AA AB 00 00 +++++ a2600_7800=0,data_size = 4096 +++++ crc8 = 0xab,crcori = 0xab ++++ get card data ok++++ ---------- find a2600 game ---------- --deint_joystick_key 267 --deint_joystick_key 286 --uninit_my_display 155 --uninit_my_display 163 --uninit_my_display 170 --uninit_my_display 179 Note that I've installed the 1.1 beta firmware and dmenu.bin logging is different. I noticed dmenu.bin is launched from the S50launcher script in rootfs etc/init.d/ Maybe we could create the port and the redirect there? Quote Link to comment Share on other sites More sharing options...
jj_0 Posted January 3 Share Posted January 3 33 minutes ago, Blinky said: Thanks. I'm on windows so the drive doesn't get reconized but I'll try connect the 2600+ to my raspberri pi later. Ah yes, the filesystem is ext2 so Windows doesn't recognise it. You could install something like ext2read to be able to use it. 35 minutes ago, Blinky said: I was experimenting before I read your last post and managed to transfer a rom successfully too on each attempt. doesn't launch the emulator though as I have CAR_TEST disconnected atm (it loads the rom regardless of CAR_TEST pin). With me it doesn't load every time and if it loads also doesn't stay in the game (retorarch quits), this is probably related to the state of the CAR_TEST, I haven't modified the hardware. 42 minutes ago, Blinky said: I noticed dmenu.bin is launched from the S50launcher script in rootfs etc/init.d/ Maybe we could create the port and the redirect there? That is possible, but S50launcher is on the read-only cramfs filesystem partition (nand partition 6) so you would need to uncompress that, make the changes, compress it again and write it back to the nand. I did that at first to change the root password but it is a bit laborious if you want to experiment. The oem partition (nand partition 7) is writable by default so much easier to work with. I made another update to the script, it now also removes the password for the root user so you can login with an empty password. So there's no need to change the cramfs at all anymore. #!/bin/sh X=$(cat /tmp/config/usb_gadget/g1/UDC) if [ "x$X" = "x" ] then exec 4>&2 5>&1 # backup the filedescr of 1 and 2 exec >/dev/ttyFIQ0 2>&1 printf "\nOvermounting shadow file\n" cat /etc/shadow | awk -F":" 'BEGIN{OFS=":"}{if($1 == "root"){$2="";print}else{print}}' >/tmp/shadow mount --bind /tmp/shadow /etc/shadow printf "\nActivating serial port\n" WD=$(pwd) mkdir /tmp/config mount -t configfs none /tmp/config mkdir /tmp/config/usb_gadget/g1 cd /tmp/config/usb_gadget/g1 echo "0x04D8" > idVendor echo "0x1234" > idProduct mkdir strings/0x409 echo "jj0" > strings/0x409/serialnumber echo "jj0" > strings/0x409/manufacturer echo "Atari 2600+ serial or mass storage gadget" > strings/0x409/product # Config for serial port gadget if true; then mkdir functions/acm.usb0 mkdir -p configs/c.1 ln -s functions/acm.usb0 configs/c.1 fi # Config for mass storage gadget if false; then mkdir -p functions/mass_storage.0/lun.0 mkdir -p configs/c.2 echo 120 > configs/c.2/MaxPower echo /dev/rkflash0 > functions/mass_storage.0/lun.0/file ln -s functions/mass_storage.0 configs/c.2 fi echo "10180000.usb" > UDC echo peripheral > /sys/devices/platform/20008000.syscon/20008000.syscon:usb2-phy@17c/otg_mode exec 2>&4 >&5 4>&- 5>&- # restore stdout and stderr # Uncomment for shell on serial gadget # cd / # while true; do sleep 3; PS1='\u@A2600+ \w #' setsid getty -n -l /bin/sh 115200 /dev/ttyGS0; done & # Change serial gadget to /dev/ttyS0 for cartridge upload rm /dev/ttyS0 mknod -m 777 /dev/ttyS1 c 64 0 mknod -m 777 /dev/ttyS0 c 242 0 cd $WD fi echo -n -e '\x95' >/dev/ttyS1 printf "\nStarting dmenu-orig.bin\n" >/dev/ttyFIQ0 /oem/vendor/bin/dmenu-orig.bin >/dev/ttyFIQ0 1 Quote Link to comment Share on other sites More sharing options...
Blinky Posted January 3 Author Share Posted January 3 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) 2 1 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.