N00b questions about Pitfall Hack starting point...

[LatchKeyKid]

Hello, folks!  First post for a complete noob.  I've recently gotten the bug to try and code a bit for the first time in decades (my last attempt was on an Apple IIe school computer when it was the defacto standard!) and decided to start with the Atari 2600.  I've been reading threads here and watching youtube videos and had a few questions to start out with.

 

Is an existing game "hack" a good first step?  I've been considering modding/hacking Pitfall just to get the creative juices flowing but didn't know if that was a good place to start.  I figure changing up a few sprites and visuals before (hopefully) graduating to maybe tweaking a basic mechanic would be a realistic goal for someone as out of practice as myself.  If that doesn't discourage me then I could either graduate to Batari or coding something very simple the traditional way.  I've found and downloaded some annotated code for Pitfall so hopefully starting with cut/pasting sprite data might work.

 

Assuming the above isn't a bad idea, I do have some basic questions about my source game, Pitfall.  I've been using Stella dev mode and did see that the ladder and rope seem to be built by using the ball sprite.  Are either missile sprites used at all in the game?  If not, was there a reason why?  I was considering using the ball sprites to add a second color to creatures (using the player 1 missile for player 0 and vice versa since they use the default colors).  I don't plan on adding any "shooting" to the game and I assume (yikes!) you can just ignore collision but I don't know if there is something I'm missing with "attaching" the opposite missile to the other sprite in terms of clock cycles.  I'm incredibly surprised at 8blit's video tutorials showing that just drawing the two main sprites seems to use up all the clock cycles for the line they're actively drawn on.

 

Thanks in advance!

[Sohl]

Hi  @LatchKeyKid!  Hope you find this place fun and helpful.  Hacking an existing game is not the way I happened to start, but I do believe several others have started this way, and it would allow you to change things bit by bit as you learn and can understand the original code. 

 

For some games, there are commented and annotated "disassembly" code listings available, which are very helpful to study.  @DEBRO has made these for several titles, but I don't know whether Pitfall is one of these.

 

For extra colors, you need to remember how the ball and missile object colors relate to player graphics and playfield.  At a given point in time, Missile 0 is the same color as Player 0, likewise for Missile 1 & Player 1, while the Ball is the same as the playfield (foreground) color.  Depending on whether the player sprites are visible in the same location as the missiles, or the ball with foreground playfield, it may not matter and you will have opportunities to switch the colors in time to use them as you suggest.  So you can use Missile 1 to add a different color to the figure drawn by Player 0, and vice-versa if these figures are on different scan lines, or on alternating frames, or the colors are complementary (e.g. Player 0 is blue with a touch of red from Missile 1, while Player 1 is red with a touch of blue from Missile 0).  Depending on your color needs, using the ball may fit perfectly, or the playfield is empty in near the figure you want to compose, so you can switch your playfield/ball color for the figure then switch to something for your playfield graphics. Hope that all makes sense! 

[LatchKeyKid]

Thanks!  Sorry about the delay in responding.  I did see the limitations on color but figured I could add just a splash to the player sprite if the NPC sprite wasn't using its missile (and collision was turned off).  I did see a disassembled version of Pitfall on github but when I tried to reassemble (terminology?)/compile it on the dev studio it gave me a half dozen errors.   It's still helpful though just to see how things are done but obviously I can't just tweak a few things and still have it work since it's not seemingly working in the first place.

[LatchKeyKid]

Separate follow up question as well based on what I saw in this thread post:

 

 

I'd love to take one of the static enemies with two sprite animation and simply move them across the screen as the post suggests.  How do you do that using which programs?  I've downloaded an annotated version of Pitfall that I found on github but compiling it in Dev Studio just gives me a half dozen errors so it's not "working" in that regard so I can't just tweak the existing code.  I see that Stella has the compile machine code in a window of the dev mode but can you just copy/paste that out?  Or is there another method?

[glurk]

This is just stating the obvious, but the very first thing you need to do is get set up to assemble the source code and have that all working.  I downloaded "Pitfall.asm" from Bjars here: http://www.bjars.com/disassemblies.html and it successfully assembled and ran for me using DASM.

 

I can't help with Dev Studio, as I just use DASM and Wordpad for everything...

 

And generally you will find with MOST 2600 games, the 4K (or 2K, or whatever) is absolutely FULL.   So you can certainly change things in the code, but in order to add stuff, you will probably have to remove stuff, or try to optimize other things to gain more space.  But it can be a good way to learn, changing stuff just to see what happens...  You certainly can't 'hurt' anything.

 

I'd recommend getting some help with getting Dev Studio set up to assemble first.  Sorry I can't be much use with that... 

[LatchKeyKid]

Thanks.  I think dev studio includes DASM but I tried the latest version on github for Windows 10 x64 and the exe just flashes a dos box/command line window for a fraction of a second and closes down.  I have no idea if it's something on my end like anti-virus as I've tried running it as an administrator just in case but no luck.  That's the same pitfall.asm file I tried with dev studio that gave me a bunch of memory errors that is over on bjars. 

[alex_79]

9 hours ago, LatchKeyKid said:

I tried the latest version on github for Windows 10 x64 and the exe just flashes a dos box/command line window for a fraction of a second and closes down. 

Dasm is a command line program. You cannot run it by double clicking on the exe. You need to run it from the command prompt.

 

On 5/28/2022 at 11:32 PM, LatchKeyKid said:

when I tried to reassemble (terminology?)/compile it on the dev studio it gave me a half dozen errors. 

It would be useful to post the error messages, as those will tell what exactly the issue is.
Maybe you didn't put the required "vcs.h" file in the same directory as the source? If so, dasm would complain with something like "Unable to open 'vcs.h'", followed by a bunch of errors about unresolved symbols.

 

Anyway, note that the disassembly linked above (from 2001) apparently used an older version of vcs.h. If you assemble it with the one included with dasm, it won't give any errors, but the binary won't match the original and the game won't work correctly. Add the line

TIA_BASE_READ_ADDRESS = $30

in the source, just before "include vcs.h" to fix this.

 

---------

edit:

Alternatively, delete the "-$30" offset used in the source for each TIA read register (Collisions and joystick button input).

e.g. change "INPT4-$30" into "INPT4", "CXP0FB-$30" into "CXP0FB", etc.

 

Edited May 30, 2022 by alex_79

[LatchKeyKid]

Thanks!  It worked with a vcs.h swap and adding the line you wrote.  The vcs swap let me compile it without some sort of memory errors and the line fixed the broken gameplay (no jumping, swinging animation when approaching a ladder hole, etc).  Is this a Pitfall specific fix or general line I should add when toying around with hacks of existing games?

 

Woohoo!   I can make a few more changes now that I have a roadmap as to what is going on in the game file.  Previously, I was basically limited to sprite swaps via bithacker and about to start attempting color swaps by changing some values by trial and error and will have to manually port those back over to this annotated version as well.  Hopefully the annotated code will make the later easier plus adding in some basic gameplay tweaks and possibly minor additions as well.  As @glurk mentioned, the file is pretty full and I'd like to stay within the 4k limit for my first attempt so I'll have to prune some things after I get the simple swaps working first!

 

 

[alex_79]

1 hour ago, LatchKeyKid said:

Is this a Pitfall specific fix or general line I should add when toying around with hacks of existing games?

It's for this specific disassembly, because it was done with an older version of "vcs.h" that defined different addresses for the TIA registers^*. That line makes the new "vcs.h" behave like the old one, so the code assembles as it was intended without further changes. Other very old disassemblies (or source code for homebrews) might need that too, but there's not a general rule (most of the times the binary will differ in a few bytes but will otherwise work just fine, while in this specific case you have bugs in the gameplay if you don't change the TIA_BASE_READ_ADDRESS constant).

 

________________________________________________________

(*) The "vcs.h" file defines TIA and RIOT registers, so you can reference them in the code by using their names (as described in the "Stella programmer's guide").

The issue is that there are several mirrors for them (the same register responds to different addresses).

The TIA has 45 write-only registers, and each of them is mirrored twice in zero page memory: they're mapped from $00 to $2c and also from $40 to $6c. (If you consider the entire 64K memory area, from $0000 to $ffff, then there are 256 mirrors for each TIA write-only register).

The TIA also has 14 read-only registers, which are repeated 8 times in zero page: $00-$0d, $10-$1d, $20-$2d, $30-$3d, $40-$4d, $50-$5d, $60-$6d and $70-$7d. (The TIA read-only registers are mirrored 1024 times in the entire 64k address space).

The old "vcs.h" defined the TIA read-registers in the area $30-$3d, the current one uses $00-$0d instead.

Since the original "Pitfall" uses the $00-$0d mirrors, @Thomas Jentzsch put a "-$30" offset when referencing the registers so that the code would assemble in an exact copy of the original binary. But when you apply that offset to the registers as they're defined in the new "vcs.h", the resulting address is NOT a mirror of the register the code is meant to access (it's a RIOT ram location instead), and so the game doesn't work correctly anymore.

Edited May 30, 2022 by alex_79

[LatchKeyKid]

Thanks again.  I'd never have guessed that vcs.h had been changed in the past two decades.  I just automatically assumed the base programming tools (whether official or homebrew) was long set in stone by then for what was originally a 1976 product. 

[LatchKeyKid]

I appreciate all the help so far.  I've added the code above successfully and changed the sprites to a different creature than the snake but the animation is way too quick.  From the annotated code, it's changing every two frames which explains why the legs are flickering like Road Runner's rather than visibly animating.  For the snake and fire, is there an easy code tweak to change the animation to every 4th or 8th frame for example?  I've been watching the 8blit youtube tutorials on animating sprites but he seems to be using a different technique than in the Pitfall assembly.  I will try watching the Programmer Dan tutorials on youtube tonight hopefully.  I've posted what I think are the relevant code sections below at least according to the notes.
 

Spoiler

 

Quote

; animate some treasures and hazards:
    lda    random2          ; 3
    and    AnimateTab,x     ; 4
    sta    temp1            ; 3
    lda    ObjectPtrTab,x   ; 4
    clc                     ; 2
    adc    temp1            ; 3
    sta    objPatPtr        ; 3

    lda    NuSize1Tab,x     ; 4
    sta    nusize1          ; 3                 save number of object copies
    lda    Color1PtrTab,x   ; 4
    sta    objColPtr        ; 3

 

Since I'm using the tweaked code posted earlier in thread to have normally stationary objects move across the screen, here is that relevant section as well.

 

Quote

; animate, bounce and move rolling logs:
    ;3 new lines

   LDA  objectType    ;3

   CMP  #$05          ;2 skip ahead if

   BCS  NEWTAG        ;2³ not logs
    lda    xPosObject       ; 3
    asl                     ; 2
    asl                     ; 2
    asl                     ; 2
    and    #$30             ; 2                 rolling logs bounce for..
    cmp    #$30             ; 2                 ..2 pixel every 8th x-position
    and    #$10             ; 2
    adc    objPatPtr        ; 3
    sta    objPatPtr        ; 3
    ;added tag

NEWTAG:
    lda    frameCnt         ; 3
    lsr                     ; 2                 move logs every 2nd frame
    bcs    .skipLogs        ; 2�
    ldx    xPosObject       ; 3
    bne    .skipResetLogs   ; 2�
    ldx    #SCREENWIDTH     ; 2
.skipResetLogs:
    dex                     ; 2
    stx    xPosObject       ; 3
.skipLogs:

 

 

 

Edited May 31, 2022 by LatchKeyKid
more legible copy/paste format