Trying to hack game to use fire instead of select

[tdp]

Hello,

I'm trying to hack a game that currently needs the Select switch to start the game. I want to start the game using the fire button.

From my research, I understand that the Select button has the mnmonic SWCHB. It can be 1 = not pressed, 0=Pressed. It's hex value is 282. to read the joystick fire button, it's INPT4 (player 1 port). It's the 7th bit that controls this, so if the 7th bit is 0, then button pressed, else if 7th = 1, then no buttin pressed. I hope I have got this right.

I'm guessing that the game will have a small loop running on the title screen, that is continually checking to see if the Select switch has been activated. I assuming that it is looking for SWCHB.1 to change to SWCHB.0. To acheive my goal, would it be as easy as changing the loop to wait for the fire button to be pressed instead of the Select switch?

Now doing this in Stella debugger, do I need look for code that is monitoring SWCHB?

I'm new to this, so please bear with me? Am looking at things in the correct way?

Thanks in advance.

 

********************************************************************************************************************************************

Ok - here's what I have done so far:-

 

Changed ship sprite - hopefully it's a little more interesting

Changed the score font - looks more rounded and smooth

Changed text on title screen - now says Fire to Start (removed Igor's name - sorry!!)

 

Todo:-

Start game with fire button

 

Please try it out

Allia Quest hack v0-1.bin

Edited July 12, 2017 by tdp

[+stephena]

Typing "trap swchb" in the debugger will immediately jump to any read of SWCHB register. Somewhere around there is where you would modify the code. I can't be more specific, since it will vary per ROM how to do it.

[tdp]

Thanks Stephena.

 

When I type trap swchb, I get the message "invalid word argument (must be 0-$ffff)". It looks like the trap command checks address locations.

 

When I step the code, it loops the two following lines of code:-

 

LF977 LDA INTIM

BNE LF977

 

If i understand the above correctly, it's first loading the timer, and the second branches back to LF977. Here's a capture of the code block.

[+stephena]

Looks like this is a bug I need to fix before the next release. The register name needs to be uppercase. So type "trap SWCHB".

[tdp]

Ok, that worked.

 

I get:- 0282: read|write (SWCHB) + mirrors

 

Not sure what that means yet. More reading to do.

[+stephena]

Exit the debugger, and let the game run. The next read or write to SWCHB will cause the debugger to open again, and the current PC will be one instruction after the line of code that caused the trap. IOW, that (or somewhere around it) is where code needs to change to read from the fire button instead.

 

BTW, the above issue is now fixed, and will be present in Stella 5.0.

[tdp]

Cool!! First I help in getting the Pal version of the supercharger bios out, and now helping find bugs in Stella.

 

Thanks for the response, Stephena. Will have a play with that.

[tdp]

Ok I have having a go at this. The trap drops out on the following code:-

 

lda swchb

and #$01

bne lf74f

lf74f

lda ram_FA

cmp #$01

bne lf7bd

lf7bd

lda ram_94

bne lf7c4

jmp lf977

lf977 ------ once back in the debugger, after stepping through the above code, the next two lines keep on looping

lda intim

bne lf977

 

 

From what I can grasp of the above code, the value for SWCHB is loaded into the A register, and (which from what I have read, is a bitwise and operand with accumulator - puts the value in the accumulator).

Is it the line cmp #$01 where the value copied in the A register is compared to see if it is true? For the select to be recognised as being activated, the 7th bit needs to be 1 (i think).

If I'm right with the above, then this could be where the check is being done (and I would need SWCHB ( R ) should be 0000001 for the select activation - I'm guessing). Screenshot of the I/O values below:-

 

 

 

[Nukey Shay]

AND#$01 is checking Game Reset (bit0 of SWCHB). It'll be = 1 if not pressed. AND#$02 would check Game Select (bit1 of SWCHB). It'll be = 2 if not pressed. A pressed switch = 0 in all cases.

[tdp]

AND#$01 is checking Game Reset (bit0 of SWCHB). It'll be = 1 if not pressed. AND#$02 would check Game Select (bit1 of SWCHB). It'll be = 2 if not pressed. A pressed switch = 0 in all cases.

 

Ok - cool. That helps. Will look at this more next week, when I have more free time. I think I might give learning 6507 assembler a chance. Has anyone here read the following books (and would they recommend them):-

 

Making Games for the Atari 2600 by Steven Hugg

Racing the Beam: The Atari Video Computer System (Platform Studies Series) by Nick Montfort

Edited July 7, 2017 by tdp

[+stephena]

I own and have read the second one (and Stella is specifically mentioned ). It was a good book, but not really meant for learning how to program for the 2600. More of a general overview of the system, with an in-depth analysis of a few specific games, how they work, and their cultural significance. So while not a deeply technical book, it's still an interesting read.

[Thomas Jentzsch]

There is a complication you may have missed. Many games allow pressing RESET (or SELECT) while you are playing the game. Alia Quest is one of them. If you now hack it to react to the fire button like pressing RESET, the game will become unplayable.

[tdp]

There is a complication you may have missed. Many games allow pressing RESET (or SELECT) while you are playing the game. Alia Quest is one of them. If you now hack it to react to the fire button like pressing RESET, the game will become unplayable.

 

Interesting. So, to save memory, the routine that checks when the reset switch is reused.

 

Btw, how did you figure out it was Allia Quest?

[Thomas Jentzsch]

You hack the code, what do you mean with "memory is reused"?

 

I found Alia Quest by searching for some bytes of the code you posted.

[Thomas Jentzsch]

[duplicate]

Edited July 7, 2017 by Thomas Jentzsch

[tdp]

You hack the code, what do you mean with "memory is reused"?

 

I found Alia Quest by searching for some bytes of the code you posted.

 

 

Ohh - I didn't say the memory is reused. I said that routines are reused to save memory.

 

 

 

Interesting. So, to save memory, the routine that checks when the reset switch is reused.

 

My knowledge of assembler is extremely limited, just starting too learn. But I'm seeing situations where developers try to save memory (or I should say getting more out of the limited memory) but using routines in different ways, instead of writing new routines each time, that effectively do the same thing. Or using a single variable for multiple things.

 

Maybe, I'm just misinterpreting what I'm seeing in the code. Assembler is a bit of a mountain for a mortal like me.

Edited July 7, 2017 by tdp

[Nukey Shay]

The code isn't constantly checking it to save memory or whatever. When the switch only has one function assigned to it (like beginning a new game), there is no need to bypass the function when a game is already in progress. To make the fire button act in the same manner, you'd need to skip over the routine if a game is already in progress. Check Ram memory in Stella's debugger to see if you can find which byte(s) change to specific values when a game is active and inactive...then test suspect Ram locations in the debugger by manually altering it to those values.

[tdp]

Ok, Nukey Shay. I'll look into that. Thanks for looking.

[tdp]

Ok - I think I have updated the code that checks for the reset switch to be activated (I know I said select in previous posts - sorry):-

 

; LDA SWCHB

; AND #$01

LDA INPT4

AND #$80

BNE LF74F

I disassembled the game using Distella, and then edited the above (in red). If I am understanding this right, original the above was loading the value in the swchb register, and then comparing it to the value $01 to see if reset has been activated. I have changed the to check the value of the fire button reigister to see if that has been pressed. I rem'd out the code that was checking for reset.

I then assembled it (using the http://8bitworkshop.com/ide). I had to add the following lines at the top:-

processor 6502

include "vcs.h"

include "macro.h"

For some reason, I getting flags on the following lines of code:-

: these lines get the error EQU: Value mismatch

CXPPMM = $37

INPT4 = $3C

SWCHA = $0280

:these lines get the error label mismatch

.byte $26,$16,$06,$F6,$E6,$D6,$C6,$B6,$A6,$96,$77,$67,$57,$47,$37,$27

.byte $59,$58,$42,$41,$40,$4F,$4E,$4D,$4C,$4B,$4A,$49,$48,$32,$31,$30

.byte $D1,$D0,$DF,$DE,$DD,$DC,$DB,$DA,$D9,$D8,$C2,$C1,$C0,$CF,$CE,$CD

 

I have attached the updated asm file. Does anyone have any ideas?

aq-hack.asm

[+stephena]

Since this is a 4K ROM, you could have also used the built-in disassembler in Stella, which is also Distella. But the major advantage is that Stella will augment the disassembly at runtime, and give you a much more detailed disassembly. See the attached file to see what I mean.

 

Allia Quest hack v0-1.asm

 

To generate this file, run the ROM for a while, and exercise as many code paths as possible (ie lose a life, play on beginner and advanced, etc). Then enter the debugger and at the command prompt type 'savedis'. This will generates an assembly file in the same directory as your ROM.

[Thomas Jentzsch]

Also note that INPT4 is a zeropage address while SWCHB is not. So loading INPT4 takes one bytes less. To keep the following code at the correct addresses, insert one NOP.

[Nukey Shay]

One cycle longer if ya did

 

LDA.w INPT4

Edited July 14, 2017 by Nukey Shay