Atari 2600+ Hardware

[Ben from Plaion]

Guys, I wrote an OSS list before launch with links and I have a zip for DL. They should be up online. I'll check this tomorrow and report back.

 

I didn't include an application folder and the raw dumper source as I was advised it was proprietary. 

[+karri]

Well... The reason why I am interested is rapid homebrew testing. That is why the communication API details are interesting.

 

Actually I don't need it as I can do the same thing on a real 7800 with Dragonfly. But the 2600+ is a new thing and I would like my small games to be playable on that one as well.

 

Currently I cannot run my jam games on the 2600+. I was kind of hoping to test it before the jam ends a week from now... This is just a snapshot after a week of coding so the game is very much work-in-progress.

 

 

rainbow.a78

[Blinky]

1 hour ago, jj_0 said:

The check is done in dmenu.bin

Good to know. So another option would be reversing dmenu.bin

 

1 hour ago, jj_0 said:

[root@rk312x:/oem]# hexdump -Cv /dev/ttyS0 &
[root@rk312x:/oem]# echo -n -e '\x95' >/dev/ttyS0

Nice. did you figure out the password for root?

1 hour ago, jj_0 said:

what I think is

Yep that's a rom dump EE is a byte send by the dumper every few seconds telling a cart is inserted and EA a byte send every few seconds that no cart is inserted. AA 55 26 00 04 is the header of a 4K 2600 rom

 

[Blinky]

1 hour ago, Ben from Plaion said:

I wrote an OSS list before launch with links and I have a zip for DL

Looking forward to it.

1 hour ago, Ben from Plaion said:

I didn't include an application folder and the raw dumper source as I was advised it was proprietary.

I was afraid that may be so. I do hope community enhancements will be possible in the near future though.

 

[Spanner]

2 hours ago, Blinky said:

Good to know. So another option would be reversing dmenu.bin

 

Nice. did you figure out the password for root?

Yep that's a rom dump EE is a byte send by the dumper every few seconds telling a cart is inserted and EA a byte send every few seconds that no cart is inserted. AA 55 26 00 04 is the header of a 4K 2600 rom

 

I did a test yesterday with a USB Stick in it as it booted normally and it was showing errors about it not reading sda1, the USB stick(it reads the USB Stick fine if the CPU Board is not plugged into the DB9/Cart board), then I noticed its was doing it every 3 minutes or so and coming up with the same errors ever 3 minutes over and over like something was setting it off, you do not usually see that when a USB Stick is in Linux even if there's a error so only shows the error once so I thinking the dumper is connected to USB some how and missing up the USB stick, I just do not know why, I do not see it been the Joysticks, Maybe I am been paranoid...  
Here is a video of it, see what you think...?

Edited December 10, 2023 by Spanner

[+karri]

I wonder about the cart connector. Does a 2600 game require the cart to have the narrower physical connector? Does the hw sense the difference between narrow or wide carts?

 

For some reason I can load 7800 games from a raspberry pico connected to a 7800 wide connector. But loading 2600 games fails. It may be something wrong in my code also...

[jj_0]

11 hours ago, Blinky said:

Nice. did you figure out the password for root?

No, I gained entry via the UART on the main PCB as follows:

1. Interrupt uboot with CTRL-C
2. Make the kernel run /bin/sh instead of the usual init and login prompt startup:

   fdt set /chosen bootargs "loglevel=9 init=/bin/sh earlycon=uart8250,mmio32,0x20064000 console=ttyFIQ0 rw root=PARTUUID=614e0000-0000 rootwait";boot
   

3. Once you're in you can copy the nand from /dev/rkflash* to a USB drive
4. rkflash0p6 is the rootfs, a squashfs filesystem
5. Unsquashfs it, chroot into it and change the password (I used chuckpeddle) and squash it again
6. Overwrite /dev/rkflash0p6 with the new squashfs

You can also copy the nand in uboot itself (this is probably safer) by reading the nand sections into memory and writing them to the USB drive, or if you connect the micro USB port to your PC you can run (in uboot):

ums 0 rknand 0

Then the entire nand will appear as an USB drive on your PC so you can read and write to the various partitions

 

Or to only export the squashed rootfs:

ums 0 rknand 0:6

 

All this works best with the main PCB disconnected from the dumper/joystick PCB's.

 

And everything done is at your own risk of course 😅

 

Quote

Yep that's a rom dump EE is a byte send by the dumper every few seconds telling a cart is inserted and EA a byte send every few seconds that no cart is inserted. AA 55 26 00 04 is the header of a 4K 2600 rom

Okay. I don't see any EE or EA bytes on /dev/ttyS0 but I'll check again.

[Blinky]

10 hours ago, karri said:

Does the hw sense the difference between narrow or wide carts?

Looking at the 7800 schematic there is no physical detect. You should ignore address lines a13 to a15 though or mirror the rom every 4K

 

5 hours ago, jj_0 said:

I gained entry via the UART on the main PCB as follows:

Nice!

5 hours ago, jj_0 said:

I don't see any EE or EA bytes on /dev/ttyS0

They were in your hex dump in your previous dump. Those bytw don't seem to be trivial as the loader seems only to react to the card test pin.

[jj_0]

43 minutes ago, Blinky said:

Looking at the 7800 schematic there is no physical detect. You should ignore address lines a13 to a15 though or mirror the rom every 4K

 

Nice!

They were in your hex dump in your previous dump. Those bytw don't seem to be trivial as the loader seems only to react to the card test pin.

Ah right. What I mean is I don't see EE's or EA's every few seconds, only once after I send 95.

[Blinky]

5 hours ago, jj_0 said:

What I mean is I don't see EE's or EA's every few seconds

interesting. When I had my logic analyzer hooked to the tx line I noticed the dumper sends EA every 3-4 seconds when there is no cart and when there is a cart it sends EE in about the same interval as long as the cart is inserted.

 

 

[Blinky]

Thanks to @Spanner and @jj_0 I was able to snatch dmenu.bin and reverse it. The checksum algorithm is pretty simple once you know it.

 

The checksum is calculated over all the bytes between 0xAA 0x55 and 0x55 0xAA (rom size + 3 bytes) using the folowing algorithm :

 

checksum = 0xA5
for byte in romdata:
  checksum ^= byte
  if (checksum & 1) == 0: checksum >>= 1
  

 

 

[Thomas Jentzsch]

Hm, how does that fit to that you can swap bytes and nibbles?

 

Wait a moment, the shift without feedback seems to eliminate most of the early bytes/bits. Mainly it is only counting if the number of bits is even or odd. This is no good check-summing! And this could explain broken dumps.

 

E.g. 0xA5 = 0b10100101, the number of bits set is even. You can change 0xA5 e.g. to 0, 3, 5, 6, 9... and the result will still be the same. And this is true for all but the last few bytes (16 on average). This weakness might explain failing dumps.

@Ben from Plaion You should let your developers fix that. Also, a 16 or 32-bit CRC checksum would be much more reliable.

Edited December 11, 2023 by Thomas Jentzsch

[+karri]

59 minutes ago, Blinky said:

Thanks to @Spanner and @jj_0 I was able to snatch dmenu.bin and reverse it. The checksum algorithm is pretty simple once you know it.

 

The checksum is calculated over all the bytes between 0xAA 0x55 and 0x55 0xAA (rom size + 3 bytes) using the folowing algorithm :

 

checksum = 0xA5
for byte in romdata:
  checksum ^= byte
  if (checksum & 1) == 0: checksum >>= 1
  

 

 

Nice! I can confirm that it works on all my material.

[Ben from Plaion]

57 minutes ago, Thomas Jentzsch said:

Hm, how does that fit to that you can swap bytes and nibbles?

 

Wait a moment, the shift without feedback seems to eliminate most of the early bytes/bits. Mainly it is only counting if the number of bits is even or odd. This is no good check-summing! And this could explain broken dumps.

 

E.g. 0xA5 = 0b10100101, the number of bits set is even. You can change 0xA5 e.g. to 0, 3, 5, 6, 9... and the result will still be the same. And this is true for all but the last few bytes (16 on average). This weakness might explain failing dumps.

@Ben from Plaion You should let your developers fix that. Also, a 16 or 32-bit CRC checksum would be much more reliable.

Tbh when I instruct the developer he says yeah I already read it on Atari Age.

[Blinky]

1 hour ago, Thomas Jentzsch said:

This is no good check-summing

I agree.

 

with one rom test I changed the first 3.75K of the 4K where I moved all the 1 bits to the most significant bits and all the 0 bits to the least significant bits and the rom still loaded.

 

1 hour ago, Thomas Jentzsch said:

this could explain broken dumps.

The serial speed is just ~115200 bps and it's over a short distance from I/O board to to mainboard so reliable enough IMO. I think broken dumps  are more the result of the dumper not being able to read the cart correctly. dirty contacts poor inserts, etc.

 

That said I'm surprised they didn't use synchronous serial, I2C or SPI for faster rom loading speed.

 

41 minutes ago, Ben from Plaion said:

when I instruct the developer he says yeah I already read it on Atari Age.

Nice to know they are on Atari Age as well   Hello developer

Edited December 11, 2023 by Blinky
add rom test detail

[JetSetIlly]

On 12/10/2023 at 6:11 PM, John Stamos Mullet said:

I thought about this. 
 

I wonder, does disclosure of GPL for the emulator a device is using become a moot point when the original hardware that is being emulated is a patent owned by the company using the emulator (of ostensibly their own hardware)?

No. They need to supply buildable source code, with the GPL licence intact, when it is asked for by somebody to whom they've distributed the binary.

[Ben from Plaion]

4 minutes ago, Blinky said:

I agree.

 

with one rom test I changed the first 3.75K of the 4K where I moved all the 1 bits to the most significant bits and all the 0 bits to the least significant bits and the rom still loaded.

 

The serial speed is just ~115200 bps and it's over a short distance from I/O board to to mainboard so reliable enough IMO. I think broken dumps  are more the result of the dumper not being able to read the cart correctly. dirty contacts poor inserts, etc.

 

That said I'm surprised they didn't use synchronous serial, I2C or SPI for faster rom loading speed.

 

Nice to know they are on Atari Age as well   Hello developer

Yeah as soon as Mr Blinky posted files on GitHub we were downloading.

[Blinky]

With the checksum algorithm now known, a rom loader will be added soon

[Thomas Jentzsch]

1 hour ago, Blinky said:

The serial speed is just ~115200 bps and it's over a short distance from I/O board to to mainboard so reliable enough IMO. I think broken dumps  are more the result of the dumper not being able to read the cart correctly. dirty contacts poor inserts, etc.

Yes, but a good checksum would detect bad dumps e.g. due to dirty contacts much more reliably, no?

[+karri]

9 hours ago, Thomas Jentzsch said:

Yes, but a good checksum would detect bad dumps e.g. due to dirty contacts much more reliably, no?

Not really. The checksum needs to be in the cart to detect bad contacts.

[Blinky]

9 hours ago, Thomas Jentzsch said:

but a good checksum would detect bad dumps e.g. due to dirty contacts much more reliably, no?

No a good checksum would only tell that the dump was transfered succesfully to the mainboard. It doesn't tell anything about the dump it self.

 

Carts don't have a checksum/crc so the dumper can not validate a dump (2600 carts, don't know about 7800 carts). The best it can do is validate the reset vector points to valid 6502 code (I think it does something like this because when I messed with the reset vector a few times caused loading failed)

 

The dumper is not using a md5 hash database to validate roms. If it would then it wouldn't be possible to dump new / custom roms which is possible (I also doubt the MCU would have enough program memory to store such a database).

 

[Spanner]

Here are all my 2600 carts I have, let me know if you want me to test one, Skiing, Freeway and Berserk do not work, its a shame Atari cases were not made with plastic cause they would of still existed, cause they are made from carboard they don't.

[+karri]

45 minutes ago, Blinky said:

Carts don't have a checksum/crc so the dumper can not validate a dump (2600 carts, don't know about 7800 carts).

The NTSC 7800 carts have a signature from the start address to the end of the cart. But I usually put the start address very close to the top of the rom so the signature check is faster. It does not check the cart below the start address. The PAL 7800 carts have no checksums or signatures.

[ChrisKewl]

Will any USB-C OTG cable work? I saw this one on Amazon and I am thinking about grabbing it:
https://www.amazon.com/Adapter-Charger-Mac-Book-Samsung-Surface/dp/B09Z2KGLSK/

[Thomas Jentzsch]

8 hours ago, Blinky said:

No a good checksum would only tell that the dump was transfered succesfully to the mainboard. It doesn't tell anything about the dump it self.

One could dump twice and compare.