It is currently Thu Jan 18, 2018 9:09 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1394 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12, 13, 14 ... 93  Next
Author Message
 Post subject:
PostPosted: Wed Jun 29, 2011 4:25 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 815
Location: cypress, texas
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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2011 6:55 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2986
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2011 7:30 am 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 939
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?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2011 7:51 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2986
Location: Tampere, Finland
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. :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2011 8:08 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 815
Location: cypress, texas
---
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.

Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2011 8:10 am 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
Everything should work through step throughs. :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2011 8:11 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19486
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2011 8:27 am 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 939
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:
  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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2011 9:24 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2986
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2011 9:32 am 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 939
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2011 9:47 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 815
Location: cypress, texas
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! :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2011 10:12 am 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 939
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:
; 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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 01, 2011 9:34 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 815
Location: cypress, texas
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:
  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?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 01, 2011 9:50 am 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 01, 2011 9:59 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 815
Location: cypress, texas
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. :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1394 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12, 13, 14 ... 93  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group