8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tepples wrote:That depends on how your assembler outputs listing or map files.
WOAH WOW! LISTING FILES RULE! :mrgreen: Thank you!!
qbradq wrote:What I usually do is put in a dummy instruction and set a breakpoint on that. In Nintendulator you can tell it to break when a certain address is read or written to.

I usually do a bit $0100 to read from the last byte of the stack, something that does not normally happen in my programs. I stick that instruction in wherever I want a break, then set the break point to Read $0100.
Thank you qbradq! :D
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Post by thefox »

In NintendulatorDX you can also input the function name in the debug watch window (given that your assembler is capable of spitting out a compatible debug file) and set breakpoint on that. In NESICIDE you can simply click on the left hand margin to set a breakpoint (again, if you have the debug info).

BTW, it probably wouldn't be too hard to add debug file support to ASM6/NESASM.. the debug file format is pretty much self explanatory (and if there are problems, I can help). Any takers?
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
qbradq
Posts: 972
Joined: Wed Oct 15, 2008 11:50 am

Post by qbradq »

I could look into this, although QASM is coming along nicely :D Which one do you think would be more worth-while to start with?
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Post by thefox »

qbradq wrote:I could look into this, although QASM is coming along nicely :D Which one do you think would be more worth-while to start with?
Probably ASM6, but I don't know. Probably going to be an unthankful job for anybody who's not using the said assemblers themselves. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

---
This question is to anyone. (Sorrry to interrupt yall's conversation. :( )

Does the controller work during the step through? I can't tell, it's all much to learn, and I'm going to learn it. :) edit: I'm using a regular nintendo controller with a nes-to-usb adapter that i bought here.
Last edited by unregistered on Thu Jun 30, 2011 8:12 am, edited 1 time in total.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

Everything should work through step throughs. :)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

unregistered wrote:Does the controller work during the step through?
In theory, yes. In practice, some emulators might ignore button presses while the emulator's video output window (the one with the game in it) is not focused, causing buttons to read as not pressed or as stuck if you Run several frames in the debugger. This behavior of ignoring presses to an unfocused has little to do with whether you're using a keyboard, a PC game controller, an NES controller through a retrousb.com adapter, or a Nintendo 64 controller through an Adaptoid adapter (what I use), and more to do with how Windows handles input focus.
User avatar
qbradq
Posts: 972
Joined: Wed Oct 15, 2008 11:50 am

Post by qbradq »

I have a rough time getting Nintendulator to do this. When I need to debug a program's input handling I usually add a small test to fake a conditional breakpoint.

Code: Select all

  lda control_state
  beq skip_break
    bit $0100
skip_break:
And I set a breakpoint for reads to $0100. That way the emulator breaks the next time I press a button, and I can single-step through my handling of it.

It's little tricks like this that need to be documented somewheres :D
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Post by thefox »

The only fix for the focus problem I know is to focus the main window and then step using Shift+F2 or whatever the shortcut for step was. This way the controller keys can be held down simultaneously, altho it's a bit awkward.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
qbradq
Posts: 972
Joined: Wed Oct 15, 2008 11:50 am

Post by qbradq »

Wouldn't the keys need to be held down at the start of the frame though? Or do we get the state of the keyboard the instant we strobe $4016 in Nintendulator?

I was trying to do frame advance mode, hold down the buttons I needed, use Space Bar to advance a frame, then step into my controller code. Never worked right for me.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

Well, the controller correctly reads 8, 4, 2, or 1 for the first hex number and 0 for the last hex number. Something is not working, but it's all good cause God and I can figure it out! :) Yall are so helpfull, thanks 3gengames, tepples, and qbradq. :D I'lm going to try doing it your way now qbradq...

Oh, before that there's something else I wanted to share. tepples, I did rearange what the buttons do and it seemed to me, yesterday, that the code I added below BUTTON_UP didn't work for me then; it kindof did... it incremented the aFrame... but incorrectly. After two presses of the Up button it went through all our frames (which is definitly more than 2 frames). :? The updownleftright pad must repeatedly be pressed over and over... like turbo?

edit: Thank you to thefox too! :)
User avatar
qbradq
Posts: 972
Joined: Wed Oct 15, 2008 11:50 am

Post by qbradq »

Maybe your controller reading routine is a bit off? I dunno, I have a hard time groking all of the binary xor'ing stuff that's required. I haven't touched my controller library in ages :D

I've been scolded once before for posting incomplete controller polling routines, so I'll include my entire library. It's in QASM syntax, so you'd have to change it a little bit to work with other assemblers, but it's very well tested and works reliably. As a bonus it calculates what was just pressed this frame and what was just released this frame as well.

Code: Select all

; Control pad library, for player 1 only


.scope control


; Button bits
; abltudlr
; |||||||+- DPad Right
; ||||||+-- DPad Left
; |||||+--- DPad Down
; ||||+---- DPad Up
; |||+----- Start
; ||+------ Select
; |+------- B Button
; +-------- A Button
.equ abutton	%10000000
.equ bbutton	%01000000
.equ select		%00100000
.equ start		%00010000
.equ dpadup		%00001000
.equ dpaddown	%00000100
.equ dpadleft	%00000010
.equ dpadright	%00000001


; Control pad registers
.equ reg_pad1	$4016
.equ reg_pad2	$4017


; Globals
.segment zeropage
	.res pressed 1		; If a bit is set in this register the button was just pressed this frame
	.res released 1		; If a bit is set in this register the button was just released this frame
	.res state 1		; If a bit is set in this regsiter the button is currently down
.endsegment


; Updates the controller states
.proc update
	; Locals
	.segment ram
		.res previous_controler_state 1	; The value of state from the previous frame
	.endsegment
	
	; Cycle controller states
	lda	state
	sta	previous_controler_state
	
	; Strobe the controler port
	ldx	#$09
	stx	reg_pad1
	dex
	stx	reg_pad1
	
	; Read control port data
loop:
	lda	reg_pad1
	lsr					; bit0 -> Carry
	rol	state	; bit0 <- Carry
	dex
	bne loop

	; Compute pressed
	lda	previous_controler_state
	eor	#$ff
	and	state
	sta	pressed
	
	; Compute released
	lda	state
	eor	#$ff
	and	previous_controler_state
	sta	released
	
	rts
.endproc


.endscope
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

qbradq wrote:I have a rough time getting Nintendulator to do this. When I need to debug a program's input handling I usually add a small test to fake a conditional breakpoint.

Code: Select all

  lda control_state
  beq skip_break
    bit $0100
skip_break:
And I set a breakpoint for reads to $0100. That way the emulator breaks the next time I press a button, and I can single-step through my handling of it.
How does that work? It didnt for me. I understand now though how inserting bit $0100 and setting a breakpoint for a read from $0100 is done, thanks :), but I dont see how these 4 lines of code here make the emulator break every time a button is pressed. :? Am I susposed to figure that part out for myself?
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

Go to the debugger, and set a break point for every time it reads/write from/to that location in memory, it won't do anything with your game [besides possibly mess it up] unless you use the debugger. When it hits the read/write from that location, it'll stop, allowing you to step through your code there.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

3gengames wrote:Go to the debugger, and set a break point for every time it reads/write from/to that location in memory, it won't do anything with your game [besides possibly mess it up]...
It reads $0100 and then writes twice to the status register, right? That's pretty safe, to me. :)
Post Reply