sanni
Atari - Some games dumping incorrectly [Updated with better info]
I don't feel like there's much traction on Atari but I'm trying to go there haha, and could use help if any is out there. Note that I've updated this with MUCH more useful details than it had before after further investigation showed some repeatable patterns. I'll add any useful info as I encounter it.
-
16kb games - a couple examples are Midnight Magic and Summer Games, seems to be with any 16kb (every one I've encountered used the F6 mapper, E7 is also 16kb but I haven't run into any carts using it to test) - if you split the dump into 4kb pieces, the last 8 bytes of each 4k piece piece comes from the last 4kb bank, so all four 4k segments get the same last 8 bytes. So you end up with three incorrect 8-byte segments, at the end of each of the first three 4kb segments. For some reason it is writing the last 8 bytes of the entire dump as the last 8 bytes of every 4kb peice. To be clear, this has happened with every 16kb game I've tried, in this case it is a licensed and non-licensed I used for examples. Crossbow is another. Every 16kb cart. It does match up until the last 8 bytes of each 4kb, and the last 4kb is correct since they all use its ending 8 bytes. Crystal Castles actually dumps fine because the last 8 bytes of every 4kb piece IS the same, so even though it encounters the flaw, the resulting file matches known dumps. There's likely others like this that could cause a red herring making it appear to work fine.
-
Realsports Baseball / Ms. Pac-Man (and likely other 8kb games) - Most 8kb games dump fine, however these two (and likely others) also have issues with those last 8 bytes. Realsports Baseball has 1 incorrect byte in the last 8 bytes of the whole dump. Ms. Pac-Man has 1 wrong byte in the last 8 bytes of the first 4k, and another incorrect byte in the last 8 bytes of the last 4k. In both cases, the first byte of the last 8 bytes of the whole rom is incorrect. For Ms. Pac-Man's first 4k, it is the second byte in the last 8 that is wrong. The dumps are consistently the same, even from different copies of the same cart though, so it is easy to reproduce. The working ones could be a case of just being lucky and writing a 00 where there already was one or something like that, like the Crystal Castles example above. Hard to say.
-
Pitfall 2 - dumps to the wrong size. It chooses 10k as the size which is correct. However, I get a consistent, but different result compared to the no-intro verified dump. the ROM is about 99% the same with a few small differences in the dump, however, and I think this may be on the Sanni, the dump listed on No-intro is 10,495 bytes, while what I get is 10,240 bytes. I believe the initial selection dictates the size, so is the Sanni underdumping? I believe Pitfall 2 uses its own mapper specific to it, so maybe this one isn't reading right. There are other differences in the dump aside from the size as well though, but the size being wrong stands out as something being wrong for sure, even if my rom was corrupt or something (though I've played this cart without issue plenty).
-
Grand Prix - Just an issue in the ataricart.txt file - it dumps it as 16kb, but it is 4kb. If you manually choose 4kb, you get the proper dump.
Worth noting these sanni dumps work in emulators, but I guess I just haven't hit the part of the code that would be affected by these differences as I'm not testing for long periods.
I ordered another system for dumping these for comparison, but I'm positive the above are valid issues. There seems to be issues popping up in the last 8 bytes of 4k banks primarily. And Pitfall II seems a little broken overall (even if something is up with my cart, as it has several chunks that don't match known dumps, I'd expect it to make a file of the right size). My Pitfall II cart plays fine on a console.
You might have a better chance asking skaman in the Arduino forum thread since those issues need a deeper understanding of the Atari code and I'm not sure if someone else here has worked with Atari yet.
I reached out to skaman and pointed them here. I'm talking with them and providing some info to help look into it. Definitely seems to be an issue though, feel it would be useful to keep it here for others to be aware of until it is resolved.
I can confirm that there currently is an issue with the F6 code. The bank switch register area needs some additional code like what was done for the F8 carts. I have a working code fix but I'm waiting to test an F4 cart to see if that mapper also needs a similar fix.
I cannot duplicate the reported errors with F8 carts Ms. Pac-Man and RealSports Baseball. Both test carts that I picked up dump properly and match the known dumps.
Dumps of Pitfall II will not match the known dump. The register area at 0x1000 is random on boot. I chose to output 0xFFs in this area as each read will produce a different output. The "missing" 255 bytes tacked on the end of the known dump is some RNG data generated by the DPC chip. The RNG aka "poly" bytes do not exist in the ROM so they are not included in the dump.
I included this in a message to Skaman, but just to note my findings here (and if anyone else wants to share theirs). I have 2 copies of RealSports Baseball, and two OSCR HW5 dumpers (vselect being the only difference), running the latest 12.6. They always get this error, in the same place, on either cart, in either OSCR. I also have a Maxflash dumper from AtariMax and RealSports Baseball as well as Ms. Pac-Man dump fine from it. Only the OSCR gives me the issue with these 3 carts.
My Ms. Pacman dumps just fine as skaman suggests, and likely my Pitfall II does too.
I'm getting an md5sum of Ms. Pacman as this: 87e79cd41ce136fd4f72cc6e2c161bee And my (10240 byte) Pitfall II is giving this as its md5sum: 37ea16edda0bc46f5527c3890ea121ca
Both are playable on the MiSTer and tested to open (but not control) in stella. I used my OSCRv3 (by the way, thanks for the hold button tip for fast game selection scrolling!) with the current unreleased git clone from 10/07/2023.
