Jump to content
IGNORED

Pitfall II Beta?


Tempest

Recommended Posts

I was given a rom file from a review copy of Pitfall II.  Usually Activision review copies are 100% identical to the released versions, but this one tests different in an odd way.  This prototype is slightly smaller than the released version (by .3K) and is missing a small block of code at the end.  Normally I'd say it was a bad dump, but the game seems to play just fine.  Can anyone take a look at this and see what the heck is going on?  I haven't noticed any differences which isn't surprising given that 99.99% of the game code is identical.

 

Pitfall II (Beta).bin

  • Thanks 1
Link to comment
Share on other sites

2 hours ago, DeafAtariFromKansas said:

Update: there a lot glitches every time you either fall in pit or climb down the ladder.  (there's no edit for this)

Yes it seems to happen every time the screen scrolls vertically.  I wonder if this is an actual bug in the proto or the proto is just a bad dump?

Link to comment
Share on other sites

36 minutes ago, Tempest said:

Yes it seems to happen every time the screen scrolls vertically.  I wonder if this is an actual bug in the proto or the proto is just a bad dump?

Released versions showed 10,495 bytes, while prototype version shows 10,240 bytes. More likely it's bad dump, but let other users test this file to see if it was bad or bug

Link to comment
Share on other sites

BTW if anyone else is interested, here are two more betas I've been handed.  One is a late beta for Millipede that has already been dumped but I was never able to figure out what was different.  The other is a late beta for Solaris.  This one already has all the Last Starfighter graphics stripped out but tests differently than the final.

 

 

Millipede.bin Solaris Pre-Release.bin

  • Thanks 1
Link to comment
Share on other sites

I thought this was an interesting puzzle so I thought about how we could perhaps make an automatic tool to illustrate where a game plays differently.

 

I've hacked up my emulator so that it runs two emulations side by side, with the two different ROMs. Both emulations receive the same user input.

 

The video below shows what I found. The large screen is the known good dump of the Pitfall 2 ROM, while the smaller window has the "beta" ROM in the top part and a screen showing the visual differences between the two ROM in the bottom part.

 

The first minute or so there are no differences apart from the visual glitch that has already been found and a small difference in the water snake (probably been run a frame behind). This shows that the tool basically works as intended I think.

 

After I die and go back to the beginning, I manage to trigger some differences, with quite a dramatic difference when I fall into the water for a second time. It looks to me like one or other of the ROMs hasn't quite scrolled by the same amount.

 

What's interesting about this is that the different persists right up to when I pick up the gold bar. At which point the two games come back into alignment.

 

 

 

 

 

  • Like 3
Link to comment
Share on other sites

2 minutes ago, Tempest said:

I do something similar running two emulator windows side by side, but I haven't figured out to have input go to both at the same time.  How are you doing that?

 

It's my own emulator called Gopher2600. I added the comparison window this evening so this tooling is brand new. If you think it would be useful I can polish it up and make it more usable.

 

I had a quick look at the Solaris ROM and it was quite successful at showing the differences with that too.

 

(I just had another watch of the YouTube video and I noticed that the first glitch as you fall in the water might not be visible unless you're running the video at 720 60fps)

Link to comment
Share on other sites

35 minutes ago, JetSetIlly said:

 

It's my own emulator called Gopher2600. I added the comparison window this evening so this tooling is brand new. If you think it would be useful I can polish it up and make it more usable.

 

I had a quick look at the Solaris ROM and it was quite successful at showing the differences with that too.

 

(I just had another watch of the YouTube video and I noticed that the first glitch as you fall in the water might not be visible unless you're running the video at 720 60fps)

Yes I think it would.  Do most games play the same or do most randomize things?

 

So what did you see in Solaris?

Link to comment
Share on other sites

Is there a document explaining the file format for DPC binary files used by emulators?


It's my understanding that Pitfall 2 has 8k of program rom (2x4k banks using "F8" bankswitching), plus an extra 2k of rom built into the DPC chip itself which is indirectly accessible using the chip data fetchers.

 

The binary file contains the program rom from $0000 to $1fff, and the DPC rom from $2000 to $27ff.

 

The beta rom posted above ends there, while the known dumps have 255 extra bytes at the end of the file ($2800 to $28fe).

diff.thumb.png.68667c3b9c225fa83a72f3114f5ea08d.png
What are those for?
At first glance, they are all the values from $00 to $fe in random order without repetitions.

 

 

Link to comment
Share on other sites

1 hour ago, alex_79 said:

Is there a document explaining the file format for DPC binary files used by emulators?


It's my understanding that Pitfall 2 has 8k of program rom (2x4k banks using "F8" bankswitching), plus an extra 2k of rom built into the DPC chip itself which is indirectly accessible using the chip data fetchers.

 

The binary file contains the program rom from $0000 to $1fff, and the DPC rom from $2000 to $27ff.

 

The beta rom posted above ends there, while the known dumps have 255 extra bytes at the end of the file ($2800 to $28fe).

diff.thumb.png.68667c3b9c225fa83a72f3114f5ea08d.png
What are those for?
At first glance, they are all the values from $00 to $fe in random order without repetitions.

 

 

looks like every byte is the low byte of the double (+1) of the previous byte. But some are just the double (seems to change for every group of 5 bytes)

 

Link to comment
Share on other sites

5 hours ago, DeafAtariFromKansas said:

For Solaris Pre-Release, I notice the different than Released version..  Millipede information you posted here, aleady listed in Stella....?

Oh I figured out that much, I was wondering if you saw something specific.  I haven't had time to look at these in depth yet.

Link to comment
Share on other sites

14 hours ago, Tempest said:

Yes I think it would.  Do most games play the same or do most randomize things?

 

There is no randomisation in the emulation for these tests. Any random elements can only come from user input. The effects of which I've mostly ironed out by running the two emulations in parallel. This should mean that any differences we see come only from the differences in the binary itself.

 

14 hours ago, Tempest said:

So what did you see in Solaris?

 

The first difference I can see is that the pre-release must be started with the panel's start switch. The release version that I have can be started with the joystick's fire button.

 

Visual differences in the video below. As I say there is no randomisation and the video is shown from startup, so the differences in the planets/craters is caused by the initial state of the binary itself. The only user input is pressing of the start switch and then the fire button to get the ship moving.

 

 

Trivial differences really. All this tells us I think, is that the starting state of the binaries are slightly different.

 

Synchronisation of the emulations is tricky. The previous video was being synchronised by frame (so the visual differences are matched frame by frame) which is fine, but it's possible for user input to be given on or near a frame boundary. This means that it is possible for one emulation to receive the input on one frame and for the other emulation to receive it on the next frame.

 

The previous Pitfall video I believe that's what happened in the second half of the video when we see the screen having been scrolled by slightly different amounts. It makes more sense that this was caused by a slight difference in user input than any differences in the binary. It should be possible to synchronise input exactly but I haven't done that yet.

 

 

Link to comment
Share on other sites

Wow that dual window emulator with the third showing the differences (is that part of the emulator?) would really come in handy for seeing differences between some of these prototypes.

 

42 minutes ago, JetSetIlly said:

Trivial differences really. All this tells us I think, is that the starting state of the binaries are slightly different.

So the 'seed' for the position and number of craters and planets and whatnot is different because the code is different between the two protos isn't the same, but the code for these routines is actually the same?  I know that sounds contradictory, but you get what I'm saying right? 

 

One thing I see from your clip there is that one version takes longer to bring up the map screen after blasting off.

Link to comment
Share on other sites

2 minutes ago, Tempest said:

Wow that dual window emulator with the third showing the differences (is that part of the emulator?)

It is.

2 minutes ago, Tempest said:

would really come in handy for seeing differences between some of these prototypes

 

So the 'seed' for the position and number of craters and planets and whatnot is different because the code is different between the two protos isn't the same, but the code for these routines is actually the same? I know that sounds contradictory, but you get what I'm saying right? 

 

I don't think we tell from this if the routines are the same or not.

 

All we can say is that the starting seed is different - there's no randomisation from any other source and the user input is the same. Why the starting seed is different I'm not sure. My guess is that it's a magic number in the binary.

 

Has anyone ever done a disassembly of Solaris? It would be interesting to know what randomisation method it uses. We might then be able to force the use of the same seed to test whether the routines are the same.

 

2 minutes ago, Tempest said:

 

One thing I see from your clip there is that one version takes longer to bring up the map screen after blasting off.

 

That might be because that particular sequence takes longer. Sometimes, the map screen comes up at the same time.

 

One thing I did notice is that shade of blue in the compass is sometimes different on the map screen. This isn't a difference in the binaries I don't think because it doesn't always happen.

 

image.thumb.png.be5cfab1a0379200433a1d165d62b97d.png

 

2 minutes ago, Tempest said:

would really come in handy for seeing differences between some of these prototypes

 

Yes. Once I've nailed down the synchronisation so that it's perfect, it could be a useful tool.

 

What it would be useful for is testing for differences between machines. So two emulations using the same ROM but the emulation is using a different TIA revision. That would quickly tell us whether a ROM plays or looks different on different versions of the 2600.

 

 

  • Like 4
Link to comment
Share on other sites

On 11/24/2021 at 11:54 AM, alex_79 said:

[...] the known dumps have 255 extra bytes at the end of the file ($2800 to $28fe).

What are those for?

I found the answer in this old thread:

On 10/6/2003 at 3:06 PM, Eckhard Stolberg said:

The 10K version of the Pitfall 2 ROM contains 8K of program code, 2K of graphics data for the sprites, and 256 bytes with all the values for the random number generator. The random number generator could be emulated with a formula if needed, so those 256 bytes aren't really nessessary. But the 2K of graphics data get read from the DPC chip. Without it Pitfall 2 will only have garbled sprites.

This also match with the fact that there aren't repeated values in those bytes.


I guess modern emulators don't need those 255 bytes and just emulate the DPC random number generator instead.
I tried stripping those bytes from the rom of the release NTSC "Pitfall II" and it plays just fine in Stella, Gopher2600, Stellerator and Javatari, while it does not work in Z26.

 

 

 

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...