Blinky Posted December 7, 2023 Author Share Posted December 7, 2023 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). 1 Quote Link to comment Share on other sites More sharing options...
Spanner Posted December 9, 2023 Share Posted December 9, 2023 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. Quote Link to comment Share on other sites More sharing options...
tradyblix Posted December 9, 2023 Share Posted December 9, 2023 Everyone knows that PAL games have problems. Or they should by now, it's all over the internet. Quote Link to comment Share on other sites More sharing options...
+karri Posted December 9, 2023 Share Posted December 9, 2023 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 9, 2023 Share Posted December 9, 2023 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+karri Posted December 9, 2023 Share Posted December 9, 2023 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) Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 9, 2023 Share Posted December 9, 2023 Sorry, I missed some chars in my question: Are all checksum bits relevant? Quote Link to comment Share on other sites More sharing options...
+karri Posted December 9, 2023 Share Posted December 9, 2023 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 Quote Link to comment Share on other sites More sharing options...
Blinky Posted December 10, 2023 Author Share Posted December 10, 2023 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. Quote Link to comment Share on other sites More sharing options...
Blinky Posted December 10, 2023 Author Share Posted December 10, 2023 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 1 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 10, 2023 Share Posted December 10, 2023 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+karri Posted December 10, 2023 Share Posted December 10, 2023 shift + xor sounds so much like a crc algorithm. My guess is that they just use some stock library for getting the checksum. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 10, 2023 Share Posted December 10, 2023 @Albert Could you fix the topic title, please? 1 Quote Link to comment Share on other sites More sharing options...
Blinky Posted December 10, 2023 Author Share Posted December 10, 2023 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 10, 2023 Share Posted December 10, 2023 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... Quote Link to comment Share on other sites More sharing options...
Albert Posted December 10, 2023 Share Posted December 10, 2023 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 1 Quote Link to comment Share on other sites More sharing options...
Blinky Posted December 10, 2023 Author Share Posted December 10, 2023 13 minutes ago, Thomas Jentzsch said: Maybe... Don't you have access to the source and can figure this out quite easily? 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 10, 2023 Share Posted December 10, 2023 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... 1 Quote Link to comment Share on other sites More sharing options...
Blinky Posted December 10, 2023 Author Share Posted December 10, 2023 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. 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted December 10, 2023 Share Posted December 10, 2023 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. Quote Link to comment Share on other sites More sharing options...
John Stamos Mullet Posted December 10, 2023 Share Posted December 10, 2023 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)? Quote Link to comment Share on other sites More sharing options...
jj_0 Posted December 10, 2023 Share Posted December 10, 2023 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? Quote Link to comment Share on other sites More sharing options...
Blinky Posted December 10, 2023 Author Share Posted December 10, 2023 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) Quote Link to comment Share on other sites More sharing options...
+karri Posted December 10, 2023 Share Posted December 10, 2023 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. Quote Link to comment Share on other sites More sharing options...
jj_0 Posted December 10, 2023 Share Posted December 10, 2023 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
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.