Jump to content
IGNORED

INPTx registers seem to go crazy


Recommended Posts

I'm trying to read INPT4 but it seems like any load or store instruction changes their value as well. How do I prevent this? Setting D6 to 1 in VBLANK doesn't seem to help. Am I missing something?

 

Here's the part of the code that I'm trying to use. It's located in the overscan section, 28 scanlines after the picture. It's supposed to change COLUBK which is read off of $80 when the picture is about to be drawn.

	lda #%01000000
	sta VBLANK
	ldx INPT4 ;Hopefully read player0 fire button
	bne skipjump ;I seriously don't know what to use here
	jmp newcolubk
	
skipjump
	lda #136
	sta $80
	sta WSYNC
	jmp picture
	
newcolubk
	lda #$0E
	sta $80
	sta WSYNC
	jmp picture
Link to comment
Share on other sites

Only bit 7 of INPTx is used, the other 7 bits are undefined. On most consoles those remaining bits keep the last status they were in*, but results might vary and you shouldn't rely on their value. So when the joystick button is pressed, bit 7 will be zero, but the instruction "bne newcolubk" will take the branch only if all 8 bits are zero.

To only test one bit, you could mask the others with an AND instruction.

    lda INPT4       ; INPT4 -> A
    and #%10000000  ; clears bits 6-0 of A, leaves bit 7 untouched
    bne skipjump

If you only need to test bit 7 and/or bit 6, you can use the BIT instruction instead, which will save 2 bytes, leave the Accumulator unchanged and store bit 7 in the Negative (N) flag and bit 6 in the Overflow (V) flag, so that you can check them with bpl/bmi (for bit 7) and bvc/bvs (for bit 6):

    bit INPT4       ;INPT4 bit 7 -> N flag
    bmi skipjump    ;branch if N=1

(*) In this case, the last value that was on the data bus is INPT4 address, that is $0c (%00001100). That's why you get $8c: bit 7 is determined by the actual status of the joystick button, the other bits are from the previous value ($0c). While this is what happens most of the time, you can sporadically experience a different behaviour on real hardware, so it's not something you can rely on. Stella has an option called "Drive unused TIA pins randomly on a read/peek" in the TIA tab of the debugger, which you'd better set when testing new code as it will make bugs related to those unused bits very evident.

Edited by alex_79
  • Like 1
Link to comment
Share on other sites

Only bit 7 of INPTx is used, the other 7 bits are undefined. On most consoles those remaining bits keep the last status they were in*, but results might vary and you shouldn't rely on their value. So when the joystick button is pressed, bit 7 will be zero, but the instruction "bne newcolubk" will take the branch only if all 8 bits are zero.

 

To only test one bit, you could mask the others with an AND instruction.

    lda INPT4       ; INPT4 -> A
    and #%10000000  ; clears bits 6-0 of A, leaves bit 7 untouched
    bne skipjump

If you only need to test bit 7 and/or bit 6, you can use the BIT instruction instead, which will save 2 bytes, leave the Accumulator unchanged and store bit 7 in the Negative (N) flag and bit 6 in the Overflow (V) flag, so that you can check them with bpl/bmi (for bit 7) and bvc/bvs (for bit 6):

 

    bit INPT4       ;INPT4 bit 7 -> N flag
    bmi skipjump    ;branch if N=1

(*) In this case, the last value that was on the data bus is INPT4 address, that is $0c (%00001100). That's why you get $8c: bit 7 is determined by the actual status of the joystick button, the other bits are from the previous value ($0c). While this is what happens most of the time, you can sporadically experience a different behaviour on real hardware, so it's not something you can rely on. Stella has an option called "Drive unused TIA pins randomly on a read/peek" in the TIA tab of the debugger, which you'd better set when testing new code as it will make bugs related to those unused bits very evident.

 

This was exactly what I needed for testing the fire button input. Thanks a ton!

Link to comment
Share on other sites

You'll want to become very familiar with Stella's Debugger, it's an excellent aid when programming the Atari.

 

To enter the debugger hit the ` key (to the left of 1, above tab, below escape). I posted screenshots of the options to check in it in Reply 12 of one topic, tschak909 posted a couple of debugger tutorial videos in Replies 86 and 87 of another topic. I followed up with some minor corrections and additional detail in Reply 91.

 

Extensive documentation for the debugger are available here at Stella's site.

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...