Jump to content

Photo

INPTx registers seem to go crazy


3 replies to this topic

#1 Pantomchap OFFLINE  

Pantomchap

    Space Invader

  • 16 posts

Posted Sat May 20, 2017 9:37 PM

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


#2 alex_79 OFFLINE  

alex_79

    Stargunner

  • 1,017 posts
  • Location:Italy

Posted Sun May 21, 2017 2:41 AM

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, Sun May 21, 2017 2:45 AM.


#3 Pantomchap OFFLINE  

Pantomchap

    Space Invader

  • Topic Starter
  • 16 posts

Posted Sun May 21, 2017 10:41 PM

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!



#4 SpiceWare ONLINE  

SpiceWare

    Quadrunner

  • 11,304 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Mon May 22, 2017 7:55 AM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users