It is currently Fri Jun 22, 2018 5:47 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1451 posts ]  Go to page Previous  1 ... 34, 35, 36, 37, 38, 39, 40 ... 97  Next
Author Message
 Post subject:
PostPosted: Wed May 23, 2012 3:57 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 886
Location: cypress, texas
Shiru wrote:
Learn to trace in an emulator debugger, it'll help you a lot to figure out problems like this. It is difficult for other people to help you fix large chunks of the code, because they don't have information that you have (what it is, what it should do, how it should work etc).

Ok, I understand that now. :) Thank you!


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 25, 2012 12:33 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 886
Location: cypress, texas
When I open our game's nes file with FCEUX I am awarded with
...an 'FCEUX Error' message pops up and wrote:
Error opening Game Genie ROM image!

What does that mean? :?


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 25, 2012 1:00 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20165
Location: NE Indiana, USA (NTSC)
Does it say that even if you turn off cheating?


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 25, 2012 2:12 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 886
Location: cypress, texas
tepples wrote:
Does it say that even if you turn off cheating?

Cheating?! :shock: Um, how can I turn off cheating? :)


Last edited by unregistered on Fri May 25, 2012 2:19 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Fri May 25, 2012 2:18 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1149
Config, uncheck game genie.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 25, 2012 2:36 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 886
Location: cypress, texas
Ah, thank you Kasumi. :)

tepples wrote:
Does it say that even if you turn off cheating?
No it doesn't say anything now that cheating is off. Thank you for asking that. :) It's not a horrible gray screen creater.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 25, 2012 3:33 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 886
Location: cypress, texas
Kasumi wrote:
unregistered wrote:
This section of code I posted is my new code. I dont think its ever been run... I do expect the pc to reach it... i think Going to look now.

Keep in mind, you never have to guess. You can put a breakpoint for that range.

But as for the problem, and there's not much to go on. I would just go through and put breakpoints for ranges of all the routines.

reset:
Otherstuff1:;Maybe checking the joypad?
Otherstuff2:
Otherstuff3:;Maybe updating tiles?
Otherstuff4:;Maybe updating the sprites?
Otherstuff5:
end;

Start at Otherstuff3. If that breakpoint hits, make one for end. If that doesn't hit, make one back at Otherstuff4. If it hits, try Otherstuff5. If it hits, step through it and find out why end never runs. If all the sections of your code are hit like you expect, you have to do a more indepth check in order. Put a breakpoint directly after all the routines that were recently changed.

For instance, right now, it seems like no tiles are being written to $2007 at all. (Either that, or your palettes are all gray for some reason.) Put a breakpoint directly after your tile update routine, and look in RAM for the proper values. If that works, check why those values are never being written in the NMI.

Quote:
The recent changes have been the new code I've posted. I don't remember what was where when... In my coding process so far I try to write the code first... then I play debug... then I run it when it can be run. That's the best I can do right now... I think.

Do you keep a changelog, or backups? If so, I'd start to. Even something simple like this is good.
Version 1:
Added animations.
Add movement.
Version 2:
Added horizontal scrolling.
Added 16bit movement for sprites.

I backup my entire source folder for every major change, and keep track of changes. This allows you to only check what was changed when you have an issue. "It was working. I added X, and changed Y. Now it's not. The problem is probably in X or Y, so I'll look at their logic." This also means if you REALLY screw up, you can just copy over the last backup.

Also, never write super large portions of code without checking them. For an example of something you've done before (tile updating), you could write something that gets the two right most 8x8 tile numbers of a known 16x16 metatile and writes them to ram. Run it, and check to see the write values are written to RAM. Then you write something that writes a whole known column of the tiles to RAM. If it doesn't work, or breaks your program you know exactly what to check. Then, you make your NMI write the tiles to $2007. Then you make it so can write a column at X position. If you write a single routine that does the equivalent of all that without checking any of it, you're in REALLY deep. Especially if you have to rewrite it ALL instead of just fix it.

And if you have no idea what was changed, you basically have to check the entire program.

So I guess those were debugging tips, because I have no idea about the actual problem with the information given. It's time to get your hands dirty! :D

Kasumi, thank you so much for all these incredible debugging tips!! :D It really helps me to learn at debugging! So far I've determined that the function runs fully twice. :) I'm going to try keeping the changelog you suggested with version numbers. And I'm going to save a copy of this once the Gray Screen goes away. :)

tepples wrote:
Quote:
Then, you make your NMI write the tiles to $2007. Then you make it so can write a column at X position. If you write a single routine that does the equivalent of all that without checking any of it, you're in REALLY deep. Especially if you have to rewrite it ALL instead of just fix it.

And once you do get it correct, you can make an automated test suite that plugs in a few numbers, calls the subroutine, and compares its output to what was expected.

Thanks tepples! :D Maybe I will try that. :)


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 5:09 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 886
Location: cypress, texas
the nesdev wiki wrote:
The NTSC video signal is made up of 262 scanlines, and 20 of those are spent in vblank state. After the program has received an NMI, it has about 2270 cycles to update the palette, sprites, and nametables as necessary before rendering begins.


So does that mean I might be messing something up because at the start of screeeens I turn rendering off and then right before the end I turn rendering on again.? Could those actions cause the gray screen? :?: Maybe I spend more than 2270 cycles... I don't understand... :? I've followed the program... it keeps on running... the only thing in my infinite MainLoop is something that reacts to input... that's why my song plays when I press select. I just figured this out! :)


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 5:12 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
If you don't fit the VBlank time with VRAM access, program won't crash, it will just show jumpy or messy screen.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 6:11 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1149
I've taken a hard look at what you've posted, and I don't see anything I think would cause your problem. In fact, the logic of it shows some really creative thinking. But I'm assuming lots of things based on how I'd organize this.

Can you describe the general structure of your program? Where is the routine you posted? Above your main loop? In your NMI? What does your NMI currently DO? How about your main loop? How about before that? No need to post code, just give a description what they currently do.

Or just log the entire game from the beginning, and compare it with your source code. Compare what's happening with what you expect.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 6:40 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 886
Location: cypress, texas
Shiru wrote:
If you don't fit the VBlank time with VRAM access, program won't crash, it will just show jumpy or messy screen.

Ok that's good to know. :) My program doesn't crash... I want it to though. Thank you Shiru. :) My music keeps on playing!! :D

Kasumi wrote:
I've taken a hard look at what you've posted, and I don't see anything I think would cause your problem. In fact, the logic of it shows some really creative thinking.

Wow, thank you... gosh... really creative thinking... you are so kind! :D Thank you for all of your help... I'm going to finish this reply soon. :)


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 27, 2012 1:57 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 886
Location: cypress, texas
Kasumi wrote:
Can you describe the general structure of your program?

I could try, I think... Um, well so far it's not a very big program... at $C000 it starts with the 'reset' code. That code ends at $C058. After that the MainLoop starts and it runs react_to_input which basicly covers reading the controller... then it
Code:
0C05A 58                           cli
0C05B                           ;----------------------------END OF RESET-----------

-----------------------
0C05B                              ; Transfer control to the GAME LOGIC routines.
0C05B                           
0C05B                           
0C05B                              ;initialize the flag to "false"
0C05B A9 00                        lda #$00
0C05D 85 1F                        sta FrameReady
0C05F                           
0C05F                           MainLoop:
0C05F                           
0C05F                              ;DO THE GAME LOGIC HERE (i.e. movement, collisions, etc.)
0C05F 20 DA C0                    jsr react_to_input
0C062                             
0C062                             ;indicate that the frame calculations are done
0C062 C6 1F                       dec FrameReady
0C064                           
0C064                           WaitForUpdates:
0C064                           
0C064                              ;wait for the flag to change
0C064 24 1F                        bit FrameReady
0C066 30 FC                        bmi WaitForUpdates
0C068                           
0C068 4C 5F C0                  jmp MainLoop

That's pretty much it.

Kasumi wrote:
Where is the routine you posted? Above your main loop? In your NMI?
The better see: routine I posted is in a file called ...screeeens.asm. It is called twice toward the end of the reset code inside an init nametables so yes it runs above my MainLoop. Not in my NMI, I don't think.

Kasumi wrote:
What does your NMI currently DO?
My NMI? Guess you mean my vblank: routine. Currently it 1.) preforms some video updates and then 2.) it runs FamiToneUpdate (sound) and then 3.) it quits.

Kasumi wrote:
How about your main loop? How about before that?
I posted code for my MainLoop above because I can't describe the end of it :(... Before my MainLoop I set a variable to 0... and right before that is my reset code.

Kasumi wrote:
Or just log the entire game from the beginning, and compare it with your source code. Compare what's happening with what you expect.
Could I press the Next button with the keyboard some how? Cause then it would be easier to make it through the long loops. Just hold down the button... then it'd go pretty fast, I think. :) Or maybe I could somehow make it not run loops? :?


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 27, 2012 5:35 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10523
Location: Rio de Janeiro - Brazil
unregistered wrote:
Or maybe I could somehow make it not run loops? :?

Make a breakpoint for the address right after the loop, then press "run".


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 27, 2012 5:57 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
When it is too difficult to find where to put a breakpoint from a debugger, you can put 'stop' code into the program, i.e. label: jmp label - so the program gets into an infinite loop after reaching that point, allowing you to examine system state. You can then resume execution by setting PC past the loop from the debugger.


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 27, 2012 6:12 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10523
Location: Rio de Janeiro - Brazil
That's a good idea Shiru, the only problem I see with it is that interrupts (NMIs and IRQs) might still mess up the system state. Personally, I always use writes to $FF as breakpoint triggers, so all I have to do is "sta $ff" at the point I want to debug.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1451 posts ]  Go to page Previous  1 ... 34, 35, 36, 37, 38, 39, 40 ... 97  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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:  
Powered by phpBB® Forum Software © phpBB Group