Perfect Pitfall! (1:42)

[supercat]

Modifying the stream would be more problematic.  The difficult issue would be creating a GUI within Stella to do it.  However, if someone were to create an external GUI/application, or someone wanted to manually edit the input state file, it would make things much easier.

 

Well, creating a DLL would be one approach, but that would open all sorts of nasty security risks. How about allowing a user to write a VM event handler in 6507 code? Hitting selected addresses would trigger VM mode with the following effects:

 

-1- Address ranges $2000-$FFFF would be switched in containing the VM code and some extra RAM.

 

-2- Current PC, address, data, and operation (first read, second read, first write, second write) would be latched and available to the VM handler at otherwise-unused addresses; code execution would start at the VM handler.

 

-3- The TIA and RIOT timer would be frozen.

 

-4- VM mode would be exited by writing to a certain special location in the $2000-$FFFF area. If the operation triggering VM mode was a write, exiting VM mode will cause execution to resume at the following instruction. If it was a read, the instruction will be re-executed but with the value in the VM data register used in place of the actual byte read.

 

-5- Writing to a certain location (in the $2000-$FFFF range) would exit VM mode and cause instruction execution to resume, using (if appropriate) the data in the VM data register.

[pacmanfevr76]

How does one get this thing to run?

[D.Yancey]

How does one get this thing to run?

972326[/snapback]

 

Unzip into a folder that contains the z26 emulator. Move a copy of your Pitfall! binary file into that directory and rename it Pitfall!.bin. Open a command prompt and and goto the new directory you just created. Type z26.exe Pitfall!.bin.

 

I realize that there are different ways to do this setup, so folks, please don't take my advice and cut it to shreads.

Edited November 27, 2005 by D.Yancey

[Luc]

How does one get this thing to run?

972326[/snapback]

 

Unzip into a folder that contains the z26 emulator. Move a copy of your Pitfall! binary file into that directory and rename it Pitfall!.bin. Open a command prompt and and goto the new directory you just created. Type z26.exe Pitfall!.bin.

 

I realize that there are different ways to do this setup, so folks, please don't take my advice and cut it to shreads.

972403[/snapback]

 

This is a bit easier: create a directory in which you unzip the file. Then add a copy of a pitfall!.bin file, and a copy of sdl.dll which you can find in your original z26 directory. Now just drag 'n drop the file pitfall!.bin on the z26.exe file and off you go.

 

Another method I use for playing games in emulators without a front-end is change the .bin extension of the rom files to .z26 and then tell Windows to automatically open .z26 files with z26.exe. That way all you have to do is double-click on a rom file to get it going.

[D.Yancey]

How does one get this thing to run?

972326[/snapback]

 

Unzip into a folder that contains the z26 emulator. Move a copy of your Pitfall! binary file into that directory and rename it Pitfall!.bin. Open a command prompt and and goto the new directory you just created. Type z26.exe Pitfall!.bin.

 

I realize that there are different ways to do this setup, so folks, please don't take my advice and cut it to shreads.

972403[/snapback]

 

This is a bit easier: create a directory in which you unzip the file. Then add a copy of a pitfall!.bin file, and a copy of sdl.dll which you can find in your original z26 directory. Now just drag 'n drop the file pitfall!.bin on the z26.exe file and off you go.

 

Another method I use for playing games in emulators without a front-end is change the .bin extension of the rom files to .z26 and then tell Windows to automatically open .z26 files with z26.exe. That way all you have to do is double-click on a rom file to get it going.

972519[/snapback]

Thanks Luc, That helps me too.

[atarilovesyou]

...could this be done with Kaboom?...INFINTE KABOOMING!

 

...for some reason I can't open up the link to watch this feat of Pitfall...what happens when you grab the last prize, anyway?...little song?...game ends?...stops?

[A.J. Franzman]

Pitfall...what happens when you grab the last prize, anyway?...little song?...game ends?...stops?

974009[/snapback]

Harry hops into a waiting Jeep and drives away.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

J/K, this is what some jerk who thought he was hot stuff told a lot of people at my school back in the day. The game really just freezes.

[atarilovesyou]

ha, that's great...I remember a myth back in school about finding a TV set treasure in Pitfall...oh well, we never did figure out the damn screens loop!..or the connection with the underground to the above ground screens.

 

Reminds me when I heard from a 'friend' that my Turbo for Colecovision had the White House graphic snuck into like, the 20th city or something...yeah right!...I remember I played that game for sooo long my damn foot couldn't depress the gas properly....NO WHITE HOUSE!...also funny, how the gas pedal wasn't analog, it was ON or OFF...no sweep at all!

[Zach]

I was wondering Thomas, have you determined conclusively that your path is the fastest? If not maybe we could do an A* search or something.

[Thomas Jentzsch]

I was wondering Thomas, have you determined conclusively that your path is the fastest? If not maybe we could do an A* search or something.

975305[/snapback]

No, I haven't.

 

I also was wondering about implementing some player AI and let it find the optimal path alone. But the liana is pretty complicated (especially when combined with rolling logs or opening pits), so I gave up that idea.

[D.Yancey]

You used exactly the same path that I've always used and I believe it is the fastest. All the other tunnels that do not hit a brick wall require substantial back tracking to get the missed treasures.

 

However, with 1:42 remaining you may be able to start with the tunnel on screen 1 and go left to screen 250, surface and run right 1 screen to 251 and take the tunnel to the left and emerge at screen 245. Then take all the same tunnels until you get to what was the final gold bar on screen 29. Turn around to the left to get the new final gold bar which was formerly the first gold bar on screen 7. I've never run this route and actually had a perfect game, but I know it would not be faster than the route displayed in Thomas' program. I challenge anyone to find a faster route.

[atarilovesyou]

You used exactly the same path that I've always used and I believe it is the fastest.  All the other tunnels that do not hit a brick wall require substantial back tracking to get the missed treasures.

 

However, with 1:42 remaining you may be able to start with the tunnel on screen 1 and go left to screen 250, surface and run right 1 screen to 251 and take the tunnel to the left and emerge at screen 245.  Then take all the same tunnels until you get to what was the final gold bar on screen 29.  Turn around to the left to get the new final gold bar which was formerly the first gold bar on screen 7.  I've never run this route and actually had a perfect game, but I know it would not be faster than the route displayed in Thomas' program.  I challenge anyone to find a faster route.

975638[/snapback]

 

...do you mean once you collect all the treasures, you then have to backtrack to get a 'new' gold bar that reappears on that screen??...cheesy...or is it more laid out, same treasures in the same locations.

[D.Yancey]

You used exactly the same path that I've always used and I believe it is the fastest.  All the other tunnels that do not hit a brick wall require substantial back tracking to get the missed treasures.

 

However, with 1:42 remaining you may be able to start with the tunnel on screen 1 and go left to screen 250, surface and run right 1 screen to 251 and take the tunnel to the left and emerge at screen 245.  Then take all the same tunnels until you get to what was the final gold bar on screen 29.  Turn around to the left to get the new final gold bar which was formerly the first gold bar on screen 7.  I've never run this route and actually had a perfect game, but I know it would not be faster than the route displayed in Thomas' program.  I challenge anyone to find a faster route.

975638[/snapback]

 

...do you mean once you collect all the treasures, you then have to backtrack to get a 'new' gold bar that reappears on that screen??...cheesy...or is it more laid out, same treasures in the same locations.

975654[/snapback]

 

No. When you've collected all 32 treasures, the game ends. In my above quote, what I meant to show was that in the modified pattern being described, which I believe is not as good, you skip the part of the pattern where Thomas collected the first gold bar and use 2 alternate tunnels. That gold bar would then, logically, become the final treasure to be collected, since the entire jungle of 255 screens wraps around in a loop. The rest of the game would play identically to Thomas' example.

Edited December 3, 2005 by D.Yancey

[Thomas Jentzsch]

I challenge anyone to find a faster route.

975638[/snapback]

I strongly doubt a faster route does exist.

[+stephena]

Modifying the stream would be more problematic.  The difficult issue would be creating a GUI within Stella to do it.  However, if someone were to create an external GUI/application, or someone wanted to manually edit the input state file, it would make things much easier.

 

Well, creating a DLL would be one approach, but that would open all sorts of nasty security risks. How about allowing a user to write a VM event handler in 6507 code? Hitting selected addresses would trigger VM mode with the following effects:

 

-1- Address ranges $2000-$FFFF would be switched in containing the VM code and some extra RAM.

 

-2- Current PC, address, data, and operation (first read, second read, first write, second write) would be latched and available to the VM handler at otherwise-unused addresses; code execution would start at the VM handler.

 

-3- The TIA and RIOT timer would be frozen.

 

-4- VM mode would be exited by writing to a certain special location in the $2000-$FFFF area. If the operation triggering VM mode was a write, exiting VM mode will cause execution to resume at the following instruction. If it was a read, the instruction will be re-executed but with the value in the VM data register used in place of the actual byte read.

 

-5- Writing to a certain location (in the $2000-$FFFF range) would exit VM mode and cause instruction execution to resume, using (if appropriate) the data in the VM data register.

972313[/snapback]

I think this is way more complex than necessary. I've been experimenting over the past day or so with adding event recording to Stella. I think we just need to save an initial state, and then save events. The first part is done, as Stella can save its entire state. The second part is now partially done as well. The scheme I use is as follows:

 

-X A B A B ... -X A B ...

 

'X' represents the number of frames to wait until processing the next set of events. 'A B' are event/value pairs. Every event in Stella is an enumeration (A) and has some associated value (B) such as on/off/analog value. So, '-1 10 1 15 1 10 0 -10 15 0' would mean:

 

1) wait one frame

2) set event 10 with a value of 1 (on)

3) set event 15 with a value of 1 (on)

4) set event 10 with a value of 0 (off)

5) wait 10 frames

6) set event 15 with a value of 0 (off)

 

This is easily editable, and (with the initial state included) fully deterministic. Thomas has intrigued me with this feature, so I now plan to have it in Stella 2.1

[supercat]

Well, creating a DLL would be one approach, but that would open all sorts of nasty security risks.  How about allowing a user to write a VM event handler in 6507 code?  Hitting selected addresses would trigger VM mode with the following effects:

972313[/snapback]

I think this is way more complex than necessary. I've been experimenting over the past day or so with adding event recording to Stella. I think we just need to save an initial state, and then save events. The first part is done, as Stella can save its entire state. The second part is now partially done as well. The scheme I use is as follows:

 

-X A B A B ... -X A B ...

 

'X' represents the number of frames to wait until processing the next set of events. 'A B' are event/value pairs. Every event in Stella is an enumeration (A) and has some associated value (B) such as on/off/analog value. So, '-1 10 1 15 1 10 0 -10 15 0' would mean:

 

1) wait one frame

2) set event 10 with a value of 1 (on)

3) set event 15 with a value of 1 (on)

4) set event 10 with a value of 0 (off)

5) wait 10 frames

6) set event 15 with a value of 0 (off)

 

This is easily editable, and (with the initial state included) fully deterministic. Thomas has intrigued me with this feature, so I now plan to have it in Stella 2.1

979073[/snapback]

 

The events would need finer resolution than frames, since some games may check controllers multiple times per frame. That having been said, this relates to something I'd like to see in an emulator: the ability to have the emulator save the full execution state every frame or so, and also log all of the controller actions that are sampled (noting when they are sampled). In this way, it would be possible to run a program at full speed until something bad is observed, then go back and find out what happened. Sometimes I use Z26 logging for that, but if I can't predict within a second or so when the bad thing is going to happen, the logs get too enormous.

[Atariboy]

So I drop in the Pitfall rom on to the Z26 icon I downloaded like I normally start a game in Z26, and it won't work?

[Luc]

So I drop in the Pitfall rom on to the Z26 icon I downloaded like I normally start a game in Z26, and it won't work?

979103[/snapback]

 

You should drop it on the executable file z26.exe, not on the icon file. If you can't see file extensions, tell Windows not to hide them (somewhere in Folder Options I think).

[Cybergoth]

Hi there!

 

This is easily editable, and (with the initial state included) fully deterministic.

 

Well, that's probably the opposite of what you want for serious Hiscore competition

 

Greetings,

Manuel

[Thomas Jentzsch]

Well, that's probably the opposite of what you want for serious Hiscore competition

You can already cheat anyway, so where the (new) problem?

 

And maybe Stella could watermark all screenshots from unpaused, unrestored, unsomething games. Though the code would be still publically available...

[+stephena]

Hi there!

 

This is easily editable, and (with the initial state included) fully deterministic.

 

Well, that's probably the opposite of what you want for serious Hiscore competition

 

Greetings,

Manuel

979287[/snapback]

Probably so, but I think it comes down to a fundamental opposition as to what a developer wants and what an end-user wants. Thomas mentioned that the stream should be easily editable, and that makes sense from a developers POV. What use is the stream if you can't speed up, slow down, pause, or generally figure out why something is working/not working the way it is?

 

But from the POV of the hiscore competitions, doing this makes it easier to cheat. This isn't the first time I've heard of potential problems with competitions, but everyone has to realize two things: (a) these features are being added to Stella to help developers, and as such should be as easy as possible to modify/figure out, and (b) while these features will undoubtedly help cheaters, people who cheat are going to cheat no matter what.

 

Besides, I said easy to edit, not necessarily easy to write. It will consist of waiting X frames, then doing a series of events, then waiting another Y frames, etc. Someone will still need to know the precise series of actions to follow, and when they should occur.

 

Once you go down the road of making Stella a developers emulator (and for better or worse, that's where it's going), you also make it easier for cheaters. Nothing can be done about it, really.

[+stephena]

Well, creating a DLL would be one approach, but that would open all sorts of nasty security risks.  How about allowing a user to write a VM event handler in 6507 code?  Hitting selected addresses would trigger VM mode with the following effects:

972313[/snapback]

I think this is way more complex than necessary. I've been experimenting over the past day or so with adding event recording to Stella. I think we just need to save an initial state, and then save events. The first part is done, as Stella can save its entire state. The second part is now partially done as well. The scheme I use is as follows:

 

-X A B A B ... -X A B ...

 

The events would need finer resolution than frames, since some games may check controllers multiple times per frame.

979096[/snapback]

No, I think you're overthinking the problem From my POV, all that needs to be included in the INP file is two things: an initial state save, and a series of frame waits/events as described above. Whether or not the emulation core/ROM code samples the controllers multiple times per frame is irrelevant from this POV.

 

Put another way, assume we play a game and record the events. These events happen at certain frames, and there may be more than one event per frame. If I then reload that state and input all the events at exactly the same time in exactly the same order, does it not follow that the emulator will do exactly what it did before? From that POV, it doesn't care what is being emulated, or what work is being done each frame. All that matters is that it's the same work that was done in a previous run.

[Cybergoth]

Hi there!

 

Well, that's probably the opposite of what you want for serious Hiscore competition

You can already cheat anyway, so where the (new) problem?

 

I can't follow you here, as this feature doesn't even exist yet?

 

And maybe Stella could watermark all screenshots from unpaused, unrestored, unsomething games.

Though the code would be still publically available...

 

Hm... you're talking about the HSC? It doesn't actually matter there, as this is just for fun competition

 

Well, I'm rather thinking in the direction of MARP or Twingalaxies, as for means of archieving and verifying player performances.

 

As it says about the purpose of MARP: "MARP's goal is to emulate the experience of "watching a virtual master play an arcade game", true to the arcade experience, as closely as possible." and I'd love to see that happening for 2600 games as well

 

Probably so, but I think it comes down to a fundamental opposition as to what a developer wants and what an end-user wants.  Thomas mentioned that the stream should be easily editable, and that makes sense from a developers POV.  What use is the stream if you can't speed up, slow down, pause, or generally figure out why something is working/not working the way it is?

 

Of course, this is an excellent feature.

 

But from the POV of the hiscore competitions, doing this makes it easier to cheat.  This isn't the first time I've heard of potential problems with competitions, but everyone has to realize two things: (a) these features are being added to Stella to help developers, and as such should be as easy as possible to modify/figure out, and (b) while these features will undoubtedly help cheaters, people who cheat are going to cheat no matter what.

 

Shouldn't there be ways to get it both under one hat? I'm not sure what all tgMAME or WolfMAME do here to secure "uncheated" MAME recordings, but I'm sure there's a lot of experience to learn from. Maybe there could be a split into a devcore and a competitioncore or something like that? Or watersign an "undoctored" input recording? I'm sure there'd be ways to achieve both goals

 

Once you go down the road of making Stella a developers emulator (and for better or worse, that's where it's going), you also make it easier for cheaters.  Nothing can be done about it, really.

 

Uihjah. You rarely hear "impossible" from a developer. You're sure you don't have any good ideas here?

 

What for example, if the data was only editable within Stella itself? In "competition mode" disable the editor and you're halfway there

 

Greetings,

Manuel

[Thomas Jentzsch]

I can't follow you here, as this feature doesn't even exist yet?

E.g. savestates exist and allow for cheating too. So addding this new feature just increases the number of possibilities to cheat.

 

Uihjah. You rarely hear "impossible" from a developer. You're sure you don't have any good ideas here?

IMO watersigns are probably the best idea. At least that would stop the occasional cheater.

[Cybergoth]

Hi there!

 

I can't follow you here, as this feature doesn't even exist yet?

E.g. savestates exist and allow for cheating too. So addding this new feature just increases the number of possibilities to cheat.

 

Ah, ok. That'll mostly allow cheating for "final score" pictures though - which can be done much faster with MS-Paint

 

Greetings,

Manuel