Jerky Posted August 6, 2004 Share Posted August 6, 2004 I've been using Thomas Jentzsch's disassembly of Pitfall to change the sprites and the colors, but I have one problem that's stopping me from wanting to continue with my hack idea. It seems that when I change the color of Harry's pants to black, he ends up sinking in the black pitfalls when they are closed. Changing the color of the black pitfalls did not help. The only time when I stopped Harry from sinking was when I changed the color of Harry's pants while he's climbing to a color other than black. Can someone help me out here? I really need Harry's pants to be black for my hack idea! Quote Link to comment Share on other sites More sharing options...
Susuwatari Posted August 6, 2004 Share Posted August 6, 2004 Why not try a dark grey? Something with a value of $02 or $03 (both PAL and NTSC)? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 6, 2004 Share Posted August 6, 2004 I haven't looked, but the program could be EXPECTING that the color of Harry is non-zero...like performing a BNE conditional branch afterward (as a method of saving a byte when doing a JMP). Try changing the color to $01 instead. Odd values are rounded down in colors...so it will still show up as black ($00 & $01 both are black). $01 is loaded, it's not zero, so the branch is taken normally. Quote Link to comment Share on other sites More sharing options...
Jerky Posted August 6, 2004 Author Share Posted August 6, 2004 Thanks for the suggestions! So far, no luck. I started incrementing the color values by 1, until I just started doing $05, $0f, $10, $15, $1f, etc. It seems that the only time Harry doesn't sink into the black swamp is when his pants are a color greater than $20. Another thing that I noticed is that I can have "Running Harry's" pants be black, but "Climbing Harry's" pants need to be greater than $20. Again, I'm just fooling around with the disassembly and looking for patterns. I do not know how to program in assembler. Quote Link to comment Share on other sites More sharing options...
neotokeo2001 Posted August 7, 2004 Share Posted August 7, 2004 try having the very bottom line (foot) be a different color then black. You should be able to find a shade of red/brown that will work and not really show up on the display. Quote Link to comment Share on other sites More sharing options...
Jerky Posted August 7, 2004 Author Share Posted August 7, 2004 Harry still sinks when I gave him brown shoes! Most of Harry's climbing pants cannot be black. This is really frustrating! I can't help but think that there's something wrong with the disassembly. One thing that I thought was strange was that there are two animation sprites for the climbing Harry. But one sprite consists of 21 lines and the other has 22. The colors for the climbing sprites deal with 22 lines Can anyone try to get Pitfall to work with Harry having black pants? All you have to do to test it is have Harry go left! Harry7: .byte %00110000; | XX | .byte %00010000; | X | .byte %00010000; | X | .byte %00010000; | X | .byte %00010110; | X XX | .byte %00010100; | X X | .byte %00010100; | X X | .byte %00010110; | X XX | .byte %00010010; | X X | .byte %00010110; | X XX | .byte %00011110; | XXXX | .byte %00011100; | XXX | .byte %00011000; | XX | .byte %00111000; | XXX | .byte %00111000; | XXX | .byte %00111100; | XXXX | .byte %00011110; | XXXX | .byte %00011010; | XX X | .byte %00000010; | X | .byte %00011000; | XX | .byte %00011000; | XX | .byte %00011000; | XX | Harry8: .byte %00001100; | XX | .byte %00001000; | X | .byte %00001000; | X | .byte %00001000; | X | .byte %01101000; | XX X | .byte %00101000; | X X | .byte %00101000; | X X | .byte %01101000; | XX X | .byte %01001000; | X X | .byte %01101000; | XX X | .byte %01111000; | XXXX | .byte %00111000; | XXX | .byte %00011000; | XX | .byte %00011100; | XXX | .byte %00011100; | XXX | .byte %00111100; | XXXX | .byte %01111000; | XXXX | .byte %01011000; | X XX | .byte %01000000; | X | .byte %00011000; | XX | .byte %00011000; | XX | BranchTab: . . . ; Harry's colors while climbing: ClimbColTab: .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte PINK .byte PINK .byte PINK .byte BROWN ; Harry's colors while running: RunColTab: .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte PINK .byte PINK .byte PINK .byte BROWN Quote Link to comment Share on other sites More sharing options...
Jerky Posted August 7, 2004 Author Share Posted August 7, 2004 Harry still sinks when I gave him brown shoes! Most of Harry's climbing pants cannot be black. This is really frustrating! I can't help but think that there's something wrong with the disassembly. One thing that I thought was strange was that there are two animation sprites for the climbing Harry. But one sprite consists of 21 lines and the other has 22. The colors for the climbing sprites deal with 22 lines Can anyone try to get Pitfall to work with Harry having black pants? All you have to do to test it is have Harry go left! Harry7: .byte %00110000; | XX | .byte %00010000; | X | .byte %00010000; | X | .byte %00010000; | X | .byte %00010110; | X XX | .byte %00010100; | X X | .byte %00010100; | X X | .byte %00010110; | X XX | .byte %00010010; | X X | .byte %00010110; | X XX | .byte %00011110; | XXXX | .byte %00011100; | XXX | .byte %00011000; | XX | .byte %00111000; | XXX | .byte %00111000; | XXX | .byte %00111100; | XXXX | .byte %00011110; | XXXX | .byte %00011010; | XX X | .byte %00000010; | X | .byte %00011000; | XX | .byte %00011000; | XX | .byte %00011000; | XX | Harry8: .byte %00001100; | XX | .byte %00001000; | X | .byte %00001000; | X | .byte %00001000; | X | .byte %01101000; | XX X | .byte %00101000; | X X | .byte %00101000; | X X | .byte %01101000; | XX X | .byte %01001000; | X X | .byte %01101000; | XX X | .byte %01111000; | XXXX | .byte %00111000; | XXX | .byte %00011000; | XX | .byte %00011100; | XXX | .byte %00011100; | XXX | .byte %00111100; | XXXX | .byte %01111000; | XXXX | .byte %01011000; | X XX | .byte %01000000; | X | .byte %00011000; | XX | .byte %00011000; | XX | BranchTab: . . . ; Harry's colors while climbing: ClimbColTab: .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte $20 .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte PINK .byte PINK .byte PINK .byte BROWN ; Harry's colors while running: RunColTab: .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte YELLOW_GREEN .byte PINK .byte PINK .byte PINK .byte BROWN Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 Hmm...I found out something pretty interesting. Compiling the reverse-engineered assembly made by Thomas causes the SAME glitch that you are experiencing! Anyone know what is wrong with that assembly file?? BTW Jerky... I changed harry's pants color in my hack "Bottomless Pitfall"...and it worked perfectly You can use this to hack your game if you wish (though you'll need to hack in your own changes). Keep in mind that this assembly I did on my own, so some of the things have shifted around compared to the original...and not much of anything is labelled as well as the reverse-engineered source. To make things easier to find for you, I copied over some of Thomas' data lines and pasted it into this one. Try the rom below...black pants works (just by hacking the color table). The glitch must be coming from something else (?) blkpants_rom_.zip blkpants_assembly_.zip Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 Alternately, you could look how things are layed out in Thomas' code and hack in your chages directly into the binary image using HOM. Harry's colors for example begin at byte $0C0B and end at $0C35 in HOM...and follows this pattern in the original game... ;(climbing) .byte $D2,$D2,$D2,$D2,$D2,$D2,$D2,$D2,$D2,$D2,$D2 .byte $D2,$C8,$C8,$C8,$C8,$C8,$C8,$4A,$4A,$4A,$12 ;running .byte $D2,$D2,$D2,$D2,$D2,$D2,$D2,$D2,$D2,$D2,$C8 .byte $C8,$C8,$C8,$C8,$C8,$C8,$4A,$4A,$4A,$12 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 @Thomas... Here's a list of changes between Pitfall! (the original game), and what compiles from your source (with optimizations disabled)... Comparing files Pitfall.bin and Tpitfall.bin 00000282: 02 D2 000002ED: 07 D7 000002F0: 02 D2 0000073B: 07 D7 00000818: 0C DC Looks like a few ram locations are being misinterpreted Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 I changed the offending lines back into ram locations COLUP1 and WSYNC. Here's a list of them (*'s inticates changes)... .skipDisable: sta GRP1 ; 3 dex ; 2 bpl .loopEndLiana ; 2³ jsr DrawHarry ;27/37 ldx CXP0FB-$30 ; 3** stx hitLiana ; 3 ** Altered line for above... ldx WSYNC ; 3 .notZero: sta temp3 ; 3 ; check Harry's collisions (JTZ: superfluous code!) lda CXPPMM-$30 ; 3 ***Harry collided w.objects? asl ; 2 lda CXP0FB-$30 ; 3 ****Harry collided w.playfield? ror ; 2 sta cxHarry ; 3 store here (this...else!) *** **** Altered lines for above... lda COLUP1 ; 3 Harry collided w.objects? asl ; 2 lda WSYNC ; 3 Harry collided w.playfield? .inTime: ; check collisions between Harry and object: lda CXPPMM-$30 ; 3 *****Harry collided? bmi .contCollision ; 2³ yes, process collisions lda #0 ; 2 no, skip collisions sta patOfsHarry ; 3 beq .endCollision ; 3 ***** Altered line for above lda COLUP1 ; 3 *****Harry collided? .notJumping: ora climbPos ; 3 Harry at ladder.. ora patOfsHarry ; 3 ..or Harry kneeing.. ora atLiana ; 3 ..or Harry at liana? bne .noFire ; 2³ yes, skip new jump lda INPT4-$30 ; 3 ****** and #%10000000 ; 2 cmp fireButton ; 3 sta fireButton ; 3 ****** Altered line for above... lda REFP1 ; 3 ****** And here's a zip of the corrected source. I just checked it against the original binary...and no differences are now reported Edit those lines listed above in your hacked assembly, and the game should work properly. pitfall___altered_source_.zip Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 7, 2004 Share Posted August 7, 2004 Looks like a few ram locations are being misinterpreted Yes, that's a problem with the different vch.h files we are using. In my file, the collision registers etc. start at $30 in yours they start at $00. So you have to fix, this either in your vcs.h file or my code. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 Hm...I had no idea that there were different VCS.H files. But you are right...they are listed incorrectly! The support files downloaded from here are incorrect!! http://www.taswegian.com/TwoHeaded/Atari2600/dasm/ Somebody oughta update that Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 One thing that I thought was strange was that there are two animation sprites for the climbing Harry. But one sprite consists of 21 lines and the other has 22. The colors for the climbing sprites deal with 22 lines Nope...both sprites and the color table are ALL 22 lines. If you notice in the second climbing bitmap, the top of Harry's head is "shared" with the bottom part of the tree branch (both bytes are the same value)...which follows directly below the climbing sprite. By sharing data like this, the code takes up less rom memory. In this case, 1 byte was saved. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 7, 2004 Share Posted August 7, 2004 Somebody oughta update that Actually there should be a variable base address ($00,$30) in that file. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 Somebody oughta update that Actually there should be a variable base address ($00,$30) in that file. This section? ; TIA_BASE_ADDRESS; The TIA_BASE_ADDRESS defines the base address of access to TIA registers. ; Normally 0, the base address should (externally, before including this file) ; be set to $40 when creating 3F-bankswitched (and other?) cartridges. ; The reason is that this bankswitching scheme treats any access to locations ; < $40 as a bankswitch. IFNCONST TIA_BASE_ADDRESS TIA_BASE_ADDRESS = 0 ENDIF ; Note: The address may be defined on the command-line using the -D switch, eg: ; dasm.exe code.asm -DTIA_BASE_ADDRESS=$40 -f3 -v5 -ocode.bin ; *OR* by declaring the label before including this file, eg: ; TIA_BASE_ADDRESS = $40 ; include "vcs.h" ; Alternate read/write address capability - allows for some disassembly compatibility ; usage ; to allow reassembly to binary perfect copies). This is essentially catering ; for the mirrored ROM hardware registers. ; Usage: As per above, define the TIA_BASE_READ_ADDRESS and/or TIA_BASE_WRITE_ADDRESS ; using the -D command-line switch, as required. If the addresses are not defined, ; they defaut to the TIA_BASE_ADDRESS. IFNCONST TIA_BASE_READ_ADDRESS TIA_BASE_READ_ADDRESS = TIA_BASE_ADDRESS ENDIF IFNCONST TIA_BASE_WRITE_ADDRESS TIA_BASE_WRITE_ADDRESS = TIA_BASE_ADDRESS ENDIF Wherever it is, it's not working right...it's the same one I have. * glad he ALWAYS uses equates instead of .include files Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 7, 2004 Share Posted August 7, 2004 This section? Yup. Set TIA_BASE_READ_ADDRESS to $30 and it should work. Quote Link to comment Share on other sites More sharing options...
Jerky Posted August 7, 2004 Author Share Posted August 7, 2004 A lot of activity this morning! I really appreciate it! I just hope that my hack ends up being good enough to warrant all this research... I took Nukey Shay's "corrected source", and changed Harry's pants colors. Still sinking! At first, I had a totally different vcs.h file, so I got the latest one from the dasm page Hope this is it: ; VCS.H ; Version 1.05, 13/November/2003 VERSION_VCS = 105 ; THIS IS A PRELIMINARY RELEASE OF *THE* "STANDARD" VCS.H ; THIS FILE IS EXPLICITLY SUPPORTED AS A DASM-PREFERRED COMPANION FILE ; PLEASE DO *NOT* REDISTRIBUTE THIS FILE! ; I changed the TIA_BASE_ADDRESS to $30 and the screen rolls. So now I'm thinking that I'm not executing DASM correctly: dasm pitfall.txt -f3 -opitfall.bin Quote Link to comment Share on other sites More sharing options...
vb_master Posted August 7, 2004 Share Posted August 7, 2004 You should be using .asm files for the source files. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 7, 2004 Share Posted August 7, 2004 Change TIA_BASE_READ_ADDRESS only! Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 A lot of activity this morning! I really appreciate it! I just hope that my hack ends up being good enough to warrant all this research... I took Nukey Shay's "corrected source", and changed Harry's pants colors. Still sinking! Hm... did you try the binary for Bottomless Pitfall? I changed his pants to black, and it compiles and runs perfectly What emulator are you using? Can you post your assembly (or shoot one to me via PM if you don't want it posted yet)? At first, I had a totally different vcs.h file, so I got the latest one from the dasm page Hope this is it: ; VCS.H ; Version 1.05, 13/November/2003 VERSION_VCS = 105 ; THIS IS A PRELIMINARY RELEASE OF *THE* "STANDARD" VCS.H ; THIS FILE IS EXPLICITLY SUPPORTED AS A DASM-PREFERRED COMPANION FILE ; PLEASE DO *NOT* REDISTRIBUTE THIS FILE! ; Yup...that's it. I changed the TIA_BASE_ADDRESS to $30 and the screen rolls. Noooo...that would change the base address for EVERYTHING. Thomas was saying that you should only change TIA_BASE_READ_ADDRESS...it's a bit lower in the file. So now I'm thinking that I'm not executing DASM correctly: dasm pitfall.txt -f3 -opitfall.bin That is correct (if pitfall.txt is the name of your assembly) Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 OK...I think that I've got the mystery solved. Take a look at this code... quicksand pit eor QuickSandTab,x ; 4 a=0-15 pha ; 3 -- tay ; 2 y=0-15 lda QuickSandSize,y ; 4 See that lowest line? It's loading from the QuickSandSize table...and the Y offset is going to be a value of UP TO 15 ($0F) But then look for the table... QuickSandSize: .byte 0, 4, 8, 16, 28 ; Harry's colors while climbing: ClimbColTab: .byte DARK_GREEN .byte DARK_GREEN .byte DARK_GREEN .byte DARK_GREEN .byte DARK_GREEN .byte DARK_GREEN .byte DARK_GREEN .byte DARK_GREEN .byte DARK_GREEN .byte DARK_GREEN .byte DARK_GREEN There's your problem. The QuickSandSize table has 11 of it's bytes shared with the first color table. So when they are black (0), the pit is read as being fully open! Solution: Move the table above another data table that has at least 11 high values at the beginning. Some code manipulation will not be necessary...just the data table relocation. Hang on and I'll find one Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 Got it... Grab this... QuickSandSize: .byte 0, 4, 8, 16, 28 ...and move it above the pit graphics... QuickSandSize: .byte 0, 4, 8, 16, 28 ; pattern for different the jungle grounds: PF2PatTab: OneHole: .byte %01111111; | XXXXXXX| one hole .byte %01111111; | XXXXXXX| ;(etc) That should do it Hopefully, it won't have a problem with such high values! Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 Damn...that didn't work (because the program adds 16 to it and the counter rolls over...the values were too high in that table). At least I know what to look for...a table that begins with 11 bytes that are no more than a value of 239 (%11101111) Still looking... Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 7, 2004 Share Posted August 7, 2004 Nope...that doesn't work either. The program EXPECTS a definate value of $52 to be in those 11 bytes. You are either going to need to live with the dark green color -or- enable Thomas' optimizations. If you do the latter, you can eliminate 16 byte's worth of his FILL_NOP commands and put the table there instead. I've done it below. I moved the table to the area that holds the sprite color tables, and cut out 16 of his NOP fillers there. Keep in mind that if you increase the size of the objects, you'll need to cut out more of those optimized filler lines (I just commented 16 bytes' worth out) Running w/black pants now... corrected_.zip Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.