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 »

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

Post by unregistered »

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

Post by tepples »

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

Post by unregistered »

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.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi »

Config, uncheck game genie.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

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

Post by unregistered »

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

Post by unregistered »

the [url=http://wiki.nesdev.com/w/index.php/PPU]nesdev wiki[/url] 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! :)
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

If you don't fit the VBlank time with VRAM access, program won't crash, it will just show jumpy or messy screen.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi »

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

Post by unregistered »

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

Post by unregistered »

[color=green]Kasumi[/color] 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: Select all

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.
[color=green]Kasumi[/color] 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.
[color=green]Kasumi[/color] 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.
[color=green]Kasumi[/color] 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.
[color=green]Kasumi[/color] 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? :?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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".
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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