Blinky

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? 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?

I had this issue too when my Atari 2600+ was connected to my laptops USB port. Updating went fine but the Atari2600+ seemed to be in a boot loop. It was actually caused by the laptops USB port. If you connect the Atari 2600+ to your regular power method it will boot normally.

The majority of computer users use a Windows PC and I don't think that will change anytime soon, especially since you can buy a Windows mini PC for normal use that is even cheaper then a 2600+

For people who do not have have a Windows PC but have a intel based computer, they can use Hiren’s BootCD This is kind of like a Live CD for Windows that doesn't require installation. It can be booted from USB. After creating the media follow the below steps to update the 2600+: extract DriverAssitant_v5.12.zip from the extracted folder, copy the contents of the Driver folder to the CustomDrivers folder of the HBCD drive. create a folder atari in the root of the HBCD drive and extract the contents of the RKDevTool_Release_v2.74.zip there. copy the AtariDumper executable there copy the update image there. connect the Atari2600+ to the update computer using the supplied USB-A tro USB-C cable boot your computer from the HBCD drive while the computer is still booting, power the 2600+ on while holding down Game Reset with the TV type in Color position (this will ensure the driver is automatically installed) After booting is complete, browse to the HBCD drive into the atari folder and run the RkDevTool.exe click on the Update firmware tab and then click on the Firmware button. browse again to the HBCD drive into the atari folder and select the .img image file click the update button and watch the right panel for the update to complete. close the RKDevtool, browse back to the atari folder and run the AtariDumper.exe power off the 2600+, put the TV type switch in B-W position and power on while holding down the Game Select switch. When the tools status changes from Undetected to Detected, press the download button. If the status doesn't change repeat the above step. Click OK and wait for the update to complete and click on OK again.

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.

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

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)

Thanks. I'm on windows so the drive doesn't get reconized but I'll try connect the 2600+ to my raspberri pi later. 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?

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:

Nice! what's the easiest way to get the script on the 2600+ ? Is the PC running linux? anything to do with modem manager?

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

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.

The problem is caused by the dumper and not the emulator. Did you successfully update the dumper firmware using AtariDumper1.1.0.2.exe ? To check this you can run the tool again and repeat the 1st instructions for detection and check the device version:

Updated my 2600+ and tested several PAL games. Color brightness is much better. I also experience the missing sprites issue. Looks like at some point the frames get out of sync and the same frame is displayed twice while the one that should have been displayed is skipped. The effect can be very good observed while playing dodge 'em game 3 (2 player vs mode) at round/heat 3 (when 2 computer cars are displayed) and moving the player car to an inside lane so it doesn't crash. At first it's super smooth 50Hz sprites (so awesome to watch), then one computer car dissapears and the player starts stuttering. after a while it returns to smooth again and the process repeats.

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.

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)

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

The module you linked too seems to use a mini usb connector.

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.

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)

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.

Make sure you use the supplied USB-A to USB-C cable and not a USB-C to USB-C cable Make sure you pull down the GAME SELECT lever and not the GAME RESET

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.

I was thinking a custom UI where a user can select custom (configuration) settings that are passed on to the relevant emulator (through arguments or config file) and not the emulators UI

Haven't fully catched up to this thread and maybe it has been mentioned before but I think a good way to access a 'hidden' UI would be when no cart inserted and the Loading Game failed message is displayed. A press of the fire button and/or select switch could then trigger the UI.