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

User avatar
cpow
NESICIDE developer
Posts: 1089
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow » Thu May 31, 2012 1:02 pm

unregistered wrote: What could be going bad? It just ran through the code once and then it started the MainLoop again and is back to the same part of the loop... it'll keep going and going and going and going... an...ing. :?
If you don't see smoke coming from your NES then don't panic...you haven't yet executed the self-destruct sequence.

Seriously though...not sure how anyone can help you beyond the 38 pages of help you've already received if you can't set breakpoints and step through your own creation.

EDIT: I crossed to the 39th page with my post but I'll leave my original count at 38 since my reply isn't "helpful". :shock:

Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru » Thu May 31, 2012 1:11 pm

Normally, if your large-scale code crashes, you need to check its smaller pieces that could be tested independently. Review them in the source code, maybe you made a typo. Trace them, maybe you made a mistake in its logic and it actually works not as you think it will work. That's a general debugging, no one can really help without having full access to code and an explaination what and how it should do.

User avatar
Kasumi
Posts: 1289
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi » Thu May 31, 2012 3:07 pm

unregistered wrote: What could be going bad? It just ran through the code once and then it started the MainLoop again and is back to the same part of the loop... it'll keep going and going and going and going... :?
To clarify, you logged from the very first instruction (power on), compared the log with your source code and cannot find an error? If you haven't done this, do it, especially if you have no idea what else to do.

Are you waiting a couple of frames for the PPU to warm up before writing to $2006 for the first time? That's about the last thing I can really think of.

The main loop looping just means the main loop is working fine. There could still be something wrong before it. Your NMI could be doing something that affects your tile or palette writing, or who knows what else. As was said by shiru and cpow, there's not much we can say that hasn't already been said with the information we've been given.

If you looked through a log from the beginning and even that didn't help, If I were you, I'd get rid of all the code except the absolute standard stuff (clearing RAM, waiting for vblank twice) before your main loop, which seems to be working fine. Reimplement each thing one by one. (Save the old code in a separate file, that's not assembled so it's not lost)

I'd start with palettes. You said your palettes were all black. After getting rid of this new screen code, just put in what writes the palettes.

If that works, cool. Try to put another small piece back. If not, well, I have no idea. REALLY check your NMI? I would actually start over if that didn't work. You've only got an NMI and a function that reads the joypad from the look of things.

If it's taking you longer to debug than it would to rewrite you're losing time. If you choose to rewrite, keep careful track of changes so you don't run into a similar problem. Make sure each piece works before moving on.

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

Post by unregistered » Fri Jun 01, 2012 4:00 pm

Kasumi wrote:
unregistered wrote: What could be going bad? It just ran through the code once and then it started the MainLoop again and is back to the same part of the loop... it'll keep going and going and going and going... :?
To clarify, you logged from the very first instruction (power on), compared the log with your source code and cannot find an error? If you haven't done this, do it, especially if you have no idea what else to do.
Just finished doing this... everything runs correctly... I did not find an error. I also did not spend the time to check FamiTone's code... one of his updates runs each vblank. And there was a vblank... everything looked and seemed correct... then it ended and my MainLoop repeated, so I stopped there. :) Going to try working through the rest of your post by maybe tonight or by Monday.

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

Post by unregistered » Tue Jun 05, 2012 9:39 am

Kasumi wrote:Are you waiting a couple of frames for the PPU to warm up before writing to $2006 for the first time?
What do you mean by "a couple of frames"? :) My code waits 2 vblanks at the start. The first write to $2006 happens shortly after that when it is loading our palette into $3F00.

User avatar
Kasumi
Posts: 1289
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi » Tue Jun 05, 2012 10:39 am

The vblank signals the start of a frame, so you are waiting a couple of frames by doing that. I'm out of guesses.

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames » Tue Jun 05, 2012 11:21 am

If you would post your startup code this could be solved in a couple minutes.

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

Post by unregistered » Tue Jun 05, 2012 4:31 pm

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! :shock:
Can see the palette and tiles again! YES! THANK YOU KASUMI! :D

edit: It was your focus on my palette... I was blessed to learn all of these debugging ideas! I remember now I renamed my "palette" to "Apalette" and it was missing the capital a! Joy! :D

Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru » Tue Jun 05, 2012 4:51 pm

If you renamed something, assembler would tell you that a label or a file is missing. How could you miss that?

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

Post by unregistered » Tue Jun 05, 2012 4:58 pm

Shiru wrote:If you renamed something, assembler would tell you that a label or a file is missing. How could you miss that?
Cause I was forced to rename "palette" to something else cause I already had that one. So I put the capital A infront and I guess I don't know what happened... then I was awarded with a grey screen up until a few minutes ago. :)

User avatar
cpow
NESICIDE developer
Posts: 1089
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow » Tue Jun 05, 2012 6:40 pm

unregistered wrote:
Shiru wrote:If you renamed something, assembler would tell you that a label or a file is missing. How could you miss that?
Cause I was forced to rename "palette" to something else cause I already had that one. So I put the capital A infront and I guess I don't know what happened... then I was awarded with a grey screen up until a few minutes ago. :)
Um OK but a debugger of any worth will show you what addresses are being loaded from either in real-time [an execution trace] or in design-time [an IDE with a "Go to declaration" option for symbols]. Best of all...for NES they're all *free*!

User avatar
tokumaru
Posts: 11443
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Tue Jun 05, 2012 6:58 pm

You should be more careful with labels. Putting random letters to making them unique is a poor way to handle a situation like this. You should use more descriptive names (such as TitleScreenPalette, MenuPalette, and so on), or even look into local/temporary labels, so that you can reuse the names within different scopes.

When coding in assembly you should make thing as clear as possible, other wise it will be hell to maintain. If you pick up the code after a couple of weeks and all you have to tell labels apart is a (meaningless) prefix/suffix character, you'll be in trouble.

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

Post by unregistered » Tue Jun 05, 2012 8:53 pm

cpow wrote:
unregistered wrote:
Shiru wrote:If you renamed something, assembler would tell you that a label or a file is missing. How could you miss that?
Cause I was forced to rename "palette" to something else cause I already had that one. So I put the capital A infront and I guess I don't know what happened... then I was awarded with a grey screen up until a few minutes ago. :)
Um OK but a debugger of any worth will show you what addresses are being loaded from either in real-time [an execution trace] or in design-time [an IDE with a "Go to declaration" option for symbols]. Best of all...for NES they're all *free*!
Thanks cpow! :) Does the FCEUX debugger have those options?

tokumaru wrote:You should be more careful with labels. Putting random letters to making them unique is a poor way to handle a situation like this. You should use more descriptive names (such as TitleScreenPalette, MenuPalette, and so on), or even look into local/temporary labels, so that you can reuse the names within different scopes.

When coding in assembly you should make thing as clear as possible, other wise it will be hell to maintain. If you pick up the code after a couple of weeks and all you have to tell labels apart is a (meaningless) prefix/suffix character, you'll be in trouble.
tokumaru, thank you so much! :D Yes, you are right. I will make things as clear as possible from now on and I will try to use more descriptive variable names. I already have a lot of those temporary labels just add a + or - in front and then can reuse the variable name in different scopes! :D

edit: I'm unsure if + and - labels are temporary labels... :oops:

tepples
Posts: 21720
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Sound, debugger, free: pick two

Post by tepples » Wed Jun 06, 2012 6:07 am

cpow wrote:a debugger of any worth will show you what addresses are being loaded from either in real-time [an execution trace] or in design-time [an IDE with a "Go to declaration" option for symbols]. Best of all...for NES they're all *free*!
Almost. For NES, you don't get sound and a debugger in the same executable unless you pay $150 for Windows. FCEUX for Windows in Wine lacks sound, NESICIDE for Linux runs at less than full speed on my machine and therefore also lacks sound, and FCEUX for Linux lacks a debugger.
unregistered wrote:Thanks cpow! :) Does the FCEUX debugger have those options?
cpow is the developer of NESICIDE, an emulator containing such a debugger.

User avatar
tokumaru
Posts: 11443
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Sound, debugger, free: pick two

Post by tokumaru » Wed Jun 06, 2012 6:49 am

tepples wrote:Almost. For NES, you don't get sound and a debugger in the same executable unless you pay $150 for Windows.
Or you stop being such a square and illegally download a 11-year operating system nobody even cares about anymore. Not pirating Windows 7 is one thing, but nobody gives a damn about XP anymore. Just get one of those pre-activated minified versions and be happy.
unregistered wrote:I'm unsure if + and - labels are temporary labels... :oops:
Yeah, they are. When you use + and - you can reuse label names, and whenever you reference such labels the nearest one will be used.

Post Reply