Atari 2600+ Hardware

[Blinky]

On 12/4/2023 at 11:27 PM, Bitsized said:

Does this information give us hope that the touchpad may one day be supported by the 2600+

It is possible to auto detect which controller is connected when the controller is actively used (not idle).

 

 

 

 

 

 

[Spanner]

On my model it has a problem communicating with USB, from the USB connector on the main board and the USB-C power connector so I have to take out the main board(CPU board) out of the Cart/DB9 Port board for it to work properly, U-Boot can not read the USB on the board properly(can not read partition table, and it does not connect to the PC properly too from the power USB-C or the Mini-USB connector), this model too has no transistor on it cart/DB9 Port board too so could be why, would like to know why some models have the resistor, what is it a 1K ohm?, there is a reason why they added it, UK models have smaller numbers because the Atari2600+ was made in the UK and built in China like THEC64 mini was, my Atari2600+ number is 00002279 my friend who live in the Netherlands has the serial number 00021959 and has no resistor too and has the same problem with the USB as me so maybe why they added the resistor.

And mine does not read every cart, it has a problem with Miss Pacman, Star Fox, Berserk and Activision games, it does uses the Retroarch 1.7.4 binary and its cores, prosystem_libetro.so(7800) and stella_libetro.so(2600), it can not use a new version of Retroarch, it would need 512 mb ram, like THEA500 Mini, it binary is to big to be loaded, I have the same problem in PCUAE on THEC64, it can only load RA 1.7.0 via command line, I got the Amiga and Atari ST cores working, I did try RA 1.9.6 and it ran out of ram while loading Retroarch binary into its ram so just killed it, I do have the RA 1.7.0 cores, they probably work on this.
Retroarch 1.7.4 does uses SDL2.0 too.

[tradyblix]

Everyone knows that PAL games have problems. Or they should by now, it's all over the internet. 

[+karri]

I had some time today to dump the small games in the 2600+ carts. And my galaga as well. The point was to find out the checksum algorithm.

 

Here is the preliminary Python code to calculate the parity.

import sys

class checksum:
    def __init__(self, fname):
        self.fname = fname
        with open(fname, 'rb') as f:
            self.data = f.read()
        self.cmd = self.data[:5]
        self.rom = self.data[5:-5]
        self.tail = self.data[-5:]

    def printtype(self):
        print(hex(self.cmd[2]))

    def xor256(self, start):
        x = 0
        for i in range(256):
            x = x ^ self.rom[start + i]
        return x

    def parity(self, val):
        x = 0
        while val:
            x ^= val & 1
            val >>= 1
        return x

    def xorlist(self):
        for i in range(0, len(self.rom), 256):
            val = self.xor256(i)
            print(hex(val), self.parity(val))

    def printcs(self):
        print(hex(self.tail[2]))

fname = sys.argv[1]
print(fname)
p = checksum(fname)
p.printtype()
print()
p.xorlist()
print()
p.printcs()

 

And the results:

Checksums.ods

 

It would be nice if someone could find a way to match the xor results of the data processing with the checksum in the data dump. Example:

0x26   - carttype

0xd2 0
0x1d 0
0x2a 1
0xc3 0
0x1c 1
0x20 1
0xa0 0
0x6f 0
0xd2 0
0x1d 0
0x2a 1
0xc3 0
0x1c 1
0x20 1
0xa0 0
0x6f 0

0x24   - checksum

 

Perhaps there is an algorithm where you can feed in the parity bits as you get them from the blocks. Like 0,0,1,0,1,1,0,0,0,0,1,0,1,1,0,0 -> 0x24.

[Thomas Jentzsch]

We are still guessing that the checksum results from the 256-bytes block's parity bits, right?

 

And have you checked that a checksum bits are checked?

Edited December 9, 2023 by Thomas Jentzsch

[+karri]

30 minutes ago, Thomas Jentzsch said:

We are still guessing that the checksum results from the 256-bytes block's parity bits, right?

 

And have you checked that a checksum bits are checked?

I believe that @Blinky already confirmed:

"I just discovered you can swap bytes, nibbles and bits of a rom and it still loads fine (with the same working crc) so it is something to do with parity and/or bit counting."

 

My test run was to see if it could be just parity. Perhaps I write another test with bit counting.

Swapping nibbles or bits rule out almost all crc, sum and row/column checks. So we are left with parity and bit counting.

 

It could also be that you feed the parity stuff in some form into a crc hash algorithm like:

Online CRC-8 CRC-16 CRC-32 Calculator (crccalc.com)

[Thomas Jentzsch]

Sorry, I missed some chars in my question: Are all checksum bits relevant?

[+karri]

3 hours ago, Thomas Jentzsch said:

Sorry, I missed some chars in my question: Are all checksum bits relevant?

 

All 8 bits of the checksum are changing for different carts. So my guess is that they are relevant. I also implemented crc8 and tried to feed the parity bits in different ways. But no matches. Well I did get some matches but they were just by chance.

0x26

0xe3 1
0x62 1
0xd4 0
0x26 1
0xe4 0
0x76 1
0x07 1
0xe0 1
0x3f 0
0x1b 0
0x87 0
0x54 1
0x4f 1
0xb2 0
0x8c 1
0x72 0

parity bits could be 0xeb 0x58 or if fed from top 0xd7 0x1a

0x5b crc

0x5b - checksum

Before there is a loader that accepts md5 sums that are not in the database it is hard to make tests. The only way to test this would be to feed the cart to the CPU using the serial cable and modify bytes in order to see when the cpu rejects the download.

 

Latest checksum.py included with added crc calculations and bitcount. So far no luck in finding the algorithm.

checksum.py

 

 

PS. my dumps include the 5 bytes in front of the rom and the 5 bytes after the rom. So if you want to dump them in the same way you need to use a little modified dumper. Here is what I use on Linux.

python3 dump2600p.py /dev/ttyUSB0

In order to be able to use it without sudo I have added my user to the "dialout" group in /etc/group.

 

dump2600p.py

[Blinky]

21 hours ago, Thomas Jentzsch said:

Are all checksum bits relevant?

Yes they are. I took a rom and uploaded it with all 256 values. Only one loaded.

 

 

 

[Blinky]

I'm now using a different approach: flash a rom on a cart with a single byte change and dump it to get the check value. Looks like bit shifting and xoring is involved.

 

I use the Palette demo PAL version for testing. (check value = 0xfb)

 

by changing just the last byte of the rom I was able to calculate a correct check value using:

val = 0x47
for b in dump:
  if b & 1: val ^= b >> 1
  else:     val ^= b ^ 0xe

unfortunately this only works when changing the last byte

[Thomas Jentzsch]

53 minutes ago, Blinky said:

I'm now using a different approach: flash a rom on a cart with a single byte change and dump it to get the check value. Looks like bit shifting and xoring is involved.

Good idea.

53 minutes ago, Blinky said:

I use the Palette demo PAL version for testing. (check value = 0xfb)

 

by changing just the last byte of the rom I was able to calculate a correct check value using:

val = 0x47
for b in dump:
  if b & 1: val ^= b >> 1
  else:     val ^= b ^ 0xe

unfortunately this only works when changing the last byte

Maybe do the next step and also change the last but one byte.

 

BTW: Bit 7 can never be set in your code. And if the number of bit 0 set is even, then the 2nd XOR value becomes irrelevant. So bit 7 of the checksum could be the parity of bit 0 of the data (using 0x8e in this case).

Edited December 10, 2023 by Thomas Jentzsch

[+karri]

shift + xor sounds so much like a crc algorithm. My guess is that they just use some stock library for getting the checksum.

[Thomas Jentzsch]

@Albert Could you fix the topic title, please?

[Blinky]

1 hour ago, Thomas Jentzsch said:

Bit 7 can never be set in your code

bit 7 is changed by the xored data byte when bit 0 is clear

1 hour ago, karri said:

My guess is that they just use some stock library for getting the checksum

That was my first thought when I started but I didn't get any satisfying result earlier but with the new dumps I made I'll will look into it again.

 

I made about 136 rom dumps 😅 with single byte changes. If you want to have a crack at them:

 

romdumps.zip

[Thomas Jentzsch]

36 minutes ago, Blinky said:

bit 7 is changed by the xored data byte when bit 0 is clear

Oops, yes you are right.

36 minutes ago, Blinky said:

That was my first thought when I started but I didn't get any satisfying result earlier but with the new dumps I made I'll will look into it again.

 

I made about 136 rom dumps 😅 with single byte changes. If you want to have a crack at them:

romdumps.zip 100.01 kB · 1 download

Maybe...  

[Albert]

1 hour ago, Thomas Jentzsch said:

@Albert Could you fix the topic title, please?

Done, can't believe it was like that for nearly a month!  

 

 ..Al

[Blinky]

13 minutes ago, Thomas Jentzsch said:

Maybe...  

Don't you have access to the source and can figure this out quite easily?

[Thomas Jentzsch]

3 minutes ago, Blinky said:

Don't you have access to the source and can figure this out quite easily?

Theoretically yes, but the source code we got cannot match the current release. Maybe I should ask for it again...

[Blinky]

7 minutes ago, Thomas Jentzsch said:

but the source code we got cannot match the current release

I don't think the dump check code would have changed unless there was something wrong with it.

 

8 minutes ago, Thomas Jentzsch said:

Maybe I should ask for it again...

If Atari would honour the GPL v2 licence you shouldn't need to ask for it. They don't seem to be keen on disclosing that the 2600+ is using open source. No where on the packaging, product or documentation is that information found.

[+karri]

That sounds like a much better alternative than kicking up reveng_3.0.5 and spending hours trying to feed known patterns to find the exact sequence.

[John Stamos Mullet]

56 minutes ago, Blinky said:

 

 

If Atari would honour the GPL v2 licence you shouldn't need to ask for it. They don't seem to be keen on disclosing that the 2600+ is using open source. No where on the packaging, product or documentation is that information found.

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

[jj_0]

57 minutes ago, Blinky said:

I don't think the dump check code would have changed unless there was something wrong with it.

 

If Atari would honour the GPL v2 licence you shouldn't need to ask for it. They don't seem to be keen on disclosing that the 2600+ is using open source. No where on the packaging, product or documentation is that information found.

Would the dump check code not be in dmenu.bin which is a standalone program for which Atari isn't required to provide the source? 

[Blinky]

24 minutes ago, jj_0 said:

Would the dump check code not be in dmenu.bin which is a standalone program

I don't know where the check is done but Yeah they don't need to disclose the source code that is not part of the emulator like a launcher (unless that is also is tied to a open source licence that requires disclosure of source code)

[+karri]

10 minutes ago, Blinky said:

I don't know where the check is done but Yeah they don't need to disclose the source code that is not part of the emulator like a launcher (unless that is also is tied to a open source licence that requires disclosure of source code)

Unless... the launcher happens to rely on the database that is copied from the emulator to figure out the md5 sums and parameters that are sent to the CPU.

[jj_0]

57 minutes ago, Blinky said:

I don't know where the check is done but Yeah they don't need to disclose the source code that is not part of the emulator like a launcher (unless that is also is tied to a open source licence that requires disclosure of source code)

The check is done in dmenu.bin - this receives the cartridge dump from /dev/ttyS0 and then creates a /tmp/atari2600.bin file and runs retroarch with it.

If I disable dmenu.bin I and reinsert the cartridge (or change the dipswitch) and then after a few seconds do:

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

 

I get (what I think is)  a dump of the cartridge including the extra bytes at the beginning:

00000000  ee ea aa 55 26 00 04 78  d8 a2 ff 9a a9 00 95 02  |...U&..x........|
00000010  ca d0 fb 20 67 fb a9 ff  85 b8 85 ba 20 67 fb 20  |... g....... g. |
00000020  49 fb 20 73 fa 20 6c f0  20 91 f0 20 1a f1 20 5e  |I. s. l. .. .. ^|
00000030  f1 20 63 f2 20 c3 f2 20  5e f3 20 9c f4 20 28 f5  |. c. .. ^. .. (.|
<snip>
00000ff0  55 55 55 d9 55 55 99 00  00 00 00 00 00 00 00 00  |UUU.UU..........|  

 

 

Edited December 10, 2023 by jj_0
Typos