It is currently Fri Apr 20, 2018 9:18 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1443 posts ]  Go to page Previous  1 ... 33, 34, 35, 36, 37, 38, 39 ... 97  Next
Author Message
 Post subject:
PostPosted: Thu May 10, 2012 4:41 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19923
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
Dwedit wrote:
When using jump tables, be very careful about safety. Don't allow out-of-range values to be used. Use bounds checking, or bit masking and dummy entries.

I was gonna say something like that... Jump tables are great when your cases are all consecutive numbers (and you should always try to make it so, since it's easier that way)

That or when your cases become consecutive numbers when shifted to the right. For example, you might have 32 different commands that have up to 8 different subtypes. The commands might be numbered 0, 1, 2, 3; 8 and 9; 16 through 23; 24; etc. In this case, you can still use a jump table as long as you shift out the subtype first.
Code:
do_command:
  and #$F8  ; clear the subtype
  lsr a
  lsr a  ; divide by 4
  tax
  lda command_handlers+1,x
  pha
  lda command_handlers,x
  pha
  rts
command_handlers:
  .addr wall_handler-1, powerup_handler-1, ...


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 10, 2012 5:11 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10417
Location: Rio de Janeiro - Brazil
Yeah, sure. I was mainly trying to point out that jump tables aren't the exact equivalent of the case statements of high level languages (which might or might not become jump tables when compiled), and if the distribution of your cases is weird you will have to go with the "bunch of IFs" solution.


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 10, 2012 5:40 pm 
Offline
Formerly ~J-@D!~
User avatar

Joined: Sun Mar 12, 2006 12:36 am
Posts: 445
Location: Rive nord de Montréal
And in the extreme, you can always use a simple hash function to calculate the index in the jump table (the right shift trick by Tepples is a kind of a simple hash function). Of course all the other entries have to be valid and point to a "default" case.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 11, 2012 9:26 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
Thank you tepples, cpow, tokumaru, Kasumi, Dwedit, and ~J-@D!~! :D

tokumaru, my case statement was going to be used with four cases: 0, 1, 2, and 3. I think I'll go with the comparisons route... it seems possible to me. :)


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 11, 2012 9:50 am 
Online
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4025
If you are using a bunch of IF statements, you can rearrange them better to get a speedup, similar to Binary Search.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 11, 2012 10:14 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1060
Location: Minneapolis, MN
Dwedit wrote:
If you are using a bunch of IF statements, you can rearrange them better to get a speedup, similar to Binary Search.


You mean like:

Code:
lda caseExpr
check1:
cmp #1
bpl check2
beq case1
bmi case0
check2:
cmp #2
bpl case3
beq case2
jmp out

case0:
   nop
   jmp out
case1:
   nop
   jmp out
case2:
   nop
   jmp out
case3:   
   nop
   jmp out
out:
   nop


I suppose the ordering of the branches could be changed too if you know the relative distribution of expected values.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 15, 2012 9:38 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
Now it has gone back to running without a screen; it's always gray. I know it is running because when I press select my song starts playing. I don't believe there are any extra RTS' PLAs or PHAs. But the screen is always gray... was because of having a JMP ending with RTS...

It never goes through this code... i dont think. After reset it always starts at around $C300.

Code:
0C23F                           attributetable: ;<this section isn't ever JSRed
0C23F                               ;76543210
0C23F                              ;saves the palette
0C23F                           
0C23F 85 2F                         sta palette ;<#xx000000b
0C241 A5 24                         lda anum
0C243                           
0C243                              
0C243 C9 00                        cmp #0
0C245 D0 03                        bne +not0
0C247 4C 5B C2                     jmp +action0
0C24A C9 01                     +not0:   cmp #1
0C24C D0 03                        bne +not1
0C24E 4C 67 C2                     jmp +action1
0C251 C9 02                     +not1:   cmp #2
0C253 D0 03                        bne +not2
0C255 4C 73 C2                     jmp +action2
0C258 4C 7F C2                  +not2:   jmp +action3
0C25B                              
0C25B A2 06                        +action0: ldx #06
0C25D A5 2F                                  lda palette
0C25F 20 0F C3                            jsr shift_right ;takes a and x
0C262 85 20                               sta att_upleft
0C264 4C A3 C2                              jmp +out
0C267 A2 04                        +action1: ldx #04
0C269 A5 2F                               lda palette
0C26B 20 0F C3                            jsr shift_right ;takes a and x
0C26E 85 21                                 sta att_upright
0C270 4C A3 C2                              jmp +out
0C273 A2 02                        +action2: ldx #02
0C275 A5 2F                                 lda palette
0C277 20 0F C3                              jsr shift_right ;takes a and x
0C27A 85 22                               sta att_loleft
0C27C 4C A3 C2                            jmp +out
0C27F A2 00                        +action3: ldx #00
0C281 86 24                                  stx anum
0C283 A5 2F                               lda palette
0C285                                     ;skip ;jsr shift_right cause x is 00
0C285 85 23                               sta att_loright
0C287                                       ; since this is the last tile of this metatile:
0C287                                     ; let's put it together...
0C287 A5 20                               lda att_upleft
0C289 05 21                               ora att_upright
0C28B 05 22                               ora att_loleft
0C28D 05 23                               ora att_loright
0C28F 48                                  pha ;------------------------------------->
0C290 48                                  pha ;----------------------------------->
0C291 98                                  tya
0C292 4A                                  lsr a  ;/2
0C293 4A                                  lsr a  ;/2
0C294 A8                                  tay
0C295 68                                  pla ;<-----------------------------------
0C296 99 F0 04                            sta attributeTable,y  ;<8bit palette updated into attributeTable
0C299 98                                  tya
0C29A 0A                                  asl a  ;*2
0C29B 0A                                  asl a  ;*2
0C29C A8                                  tay
0C29D 68                                  pla ;<-------------------------------------
0C29E EA                                  nop
0C29F EA                                  nop
0C2A0 4C A5 C2                            jmp +
0C2A3                              
0C2A3                              +out:
0C2A3                              ;ldx #06  ^loook above
0C2A3                           
0C2A3                           
0C2A3 E6 24                        inc anum
0C2A5                           +   ;iny  (...does it later... line 270)


and here is shift_right
Code:
0C30F                             ;shifts the accumulator right a certain amount (amount declared in x)
0C30F                             ;trashes x and a kind of... At the end, a holds the answer and x should be 0
0C30F                           shift_right:
0C30F 4A                        -   lsr a      ;>shifts the pal back right>
0C310 CA                           dex
0C311 D0 FC                        bne -
0C313 60                          rts


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 16, 2012 1:17 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1124
(My general conduct has probably already made it clear, but I've never directly stated it. I truly and honestly have terrible reading comprehension, so that's why I ask so many questions for things that are probably very obviously clear to someone else.)

The screen is gray meaning no tiles are being updated in the nametable memory? Rendering is completely disabled? Perhaps just that the attributes aren't updating and are all gray? I guess the easy way to check for some of these is to check the contents of the nametables using a debug emulator. If what's in there looks right but the actual screen is gray, it might be you're disabling rendering somewhere but forgetting to turn it back on.

Quote:
It never goes through this code... i dont think.

Does this mean that code is/should not run at ALL or something else? If that section of code is run when you don't expect the PC to reach it, the direct problem isn't the section of code, it's something else.

There are some odd things in the logic of "attributetable:", but nothing that I think would cause the problems I think you're describing. If it SHOULD and DOES run, but it's just not jsr'd to, what's above what you've posted? What's below it? Have you changed what's above or below it recently?

Where do you check for select to start up your song? If it's in your NMI, that's no indication that your program isn't stuck in an infinite loop elsewhere. The NMI could interrupt, check for select, start the song, then return to an infinite loop even for something like:
Code:
forever:
jmp forever


Either way, I see nothing posted that I think would cause a gray screen. My best guess with the info I have is disabled rendering without re-enabling it. If you can check for select outside your NMI and it actually works, your program is probably not crashing, and probably looping just fine. I assume it wasn't gray before, so what was are the most recent set of changes you made where before them the screen wasn't gray, and after it was?

Edit: You know what? I have to say this:
Code:
attributetable:
attributeTable,y

is not the best idea. If you accidentally jmp to attributeTable, bad things will probably happen. If you store to attributetable bad things may not happen if you don't use a mapper, but you'll wonder why you don't get a result.

If you have variable/label names that can be typo'd into each other, change them. "Typing error bugs" that the assembler can't catch are the WORST because you can look over the logic again and again and everything will look fine. Be nice to yourself and come up with some separate names.

Edit 2: And... wait, it kinda just struck me. You can get a song playing? Might it be something in your music engine that's causing the problem? If that's something you have now, but didn't have before it's worth you taking look at.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 16, 2012 9:30 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
Kasumi wrote:
(My general conduct has probably already made it clear, but I've never directly stated it. I truly and honestly have terrible reading comprehension, so that's why I ask so many questions for things that are probably very obviously clear to someone else.)

The screen is gray meaning no tiles are being updated in the nametable memory? Rendering is completely disabled? Perhaps just that the attributes aren't updating and are all gray? I guess the easy way to check for some of these is to check the contents of the nametables using a debug emulator. If what's in there looks right but the actual screen is gray, it might be you're disabling rendering somewhere but forgetting to turn it back on.


The screen is gray meaning that both nintendulator 0.970 and FCEUX 2.0.3 do not show anything when viewing a debug visual PPU screen... it's all just gray. :?

Kasumi wrote:

Quote:
It never goes through this code... i dont think.

Does this mean that code is/should not run at ALL or something else? If that section of code is run when you don't expect the PC to reach it, the direct problem isn't the section of code, it's something else.


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.

Kasumi wrote:
There are some odd things in the logic of "attributetable:", but nothing that I think would cause the problems I think you're describing. If it SHOULD and DOES run, but it's just not jsr'd to, what's above what you've posted? What's below it? Have you changed what's above or below it recently?

Above what I've posted is the first part of collisionU: and below it is the third last part of collisionU:. Even though the palette is not part of collision... it has to be saved within because the code of collisionU explores our place where we store the palette.

Kasumi wrote:
I assume it wasn't gray before, so what was are the most recent set of changes you made where before them the screen wasn't gray, and after it was?


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. :)

Kasumi wrote:
Edit: You know what? I have to say this:
Code:
attributetable:
attributeTable,y

is not the best idea. If you accidentally jmp to attributeTable, bad things will probably happen. If you store to attributetable bad things may not happen if you don't use a mapper, but you'll wonder why you don't get a result.

If you have variable/label names that can be typo'd into each other, change them. "Typing error bugs" that the assembler can't catch are the WORST because you can look over the logic again and again and everything will look fine. Be nice to yourself and come up with some separate names.


:idea: :!: Thank you very much! :D (no, it's still messed up... but thank you all the same :)) Your thoughts here have helped me! :D

Kasumi wrote:
Edit 2: And... wait, it kinda just struck me. You can get a song playing? Might it be something in your music engine that's causing the problem? If that's something you have now, but didn't have before it's worth you taking look at.
No my music engine was created by Shiru... it's working awesomly now. :D


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 16, 2012 11:36 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1124
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


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 16, 2012 11:55 am 
Offline

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

In other words, a unit test of each individual part of the subroutine. The problem comes when the existing emulators that run on your computer lack a debugger. It appears most emulators with a debugger are Windows-exclusive and either don't run at all (Nintendulator) or have noticeable practical problems (FCEUX) in Wine on Linux or Mac OS X. That's why I've started to write a 6502 simulator in Python so that I can run unit tests on my Ubuntu laptop. It already runs nestest correctly, matching the golden log from Nintendulator cycle for cycle.

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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 23, 2012 10:05 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
Maybe you can find the problem while I go eat.| At the bottom right before the +done: label it seems to never make it to the end. Maybe that's the reason for my gray screen. It runs through this code... without ending, I think. I have to reread Kasumi's post again... he listed what to do if it can't reach the end I think. Lunch time! :)

Code:
see: 

  ldy #$00
  ldx #$00
  pha ;------------------>
 
     lda #$90 ;10010000b
   sta $2000  ;PPUCTRL
   lda #00000000b  ; bit 3 and 4 are 0 so rendering will be off
   sta $2001  ;PPUMASK
   ;rendering is off!!!!!!
   
   
  pla ;<------------------
  ;  lda #$20
  sta $2006;Sets the high byte of the address $2007 will write to.
  lda #$00
  sta $2006;Sets the low bylte of the address $2007 will write to.
 
  ;a is still 0
 ; sta r


-- lda ($10), y
  tax
  lda MetatileTile0, x
  sta $2007;Writes to PPU address $2000. (which is the first tile of the first name table)
  lda MetatileTile1, x
  sta $2007;Writes to PPU address $2001. (which is the tile to the right of the first tile)
  iny
  tya
  and #00001111b
  beq +          ;branch if it a multiple of 16
  jmp --
 

+  tya
   sec
   sbc #16       ;subtract 16 so we can finish the metatile row...
   tay
   
-  lda ($10), y
  tax
  lda MetatileTile2, x
  sta $2007;Writes to PPU address $2010. (which is the third tile, first tile on second row, of the first name table)
  lda MetatileTile3, x
  sta $2007;Writes to PPU address $2011. (which is the tile to the right of the third tile)
  iny

  tya
  cmp #11110000b ;if (y >= 240)
  bcs +done;was bcc
  and #00001111b
  beq --
  jmp -

+done: 
  ;//attribute  table time, i think...
  ldx #63
 
 
  lda $23
  sta $2006  ;Sets the high byte of the address $2007 will write to.
  lda $C0
  sta $2006  ;Sets the low byte of the address $2007 will write to.
 
-  lda attributes, x
  sta $2007
  dex
  bne -
 
 
  lda #$1E
sta $2001  ;PPUMASK
              ;again, rendering is on!
 
  rts  ;end of screeeens and see


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 23, 2012 10:11 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
Just a quick note on the code:

lda $23 and lda $c0 near the end - probably #$23 etc?

beq + jmp -- - why not just bne -- ?


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 23, 2012 12:13 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
Shiru wrote:
Just a quick note on the code:

lda $23 and lda $c0 near the end - probably #$23 etc?

YES... I can't believe I missed the # again. :(

Thank you for helping Shiru! :D

Shiru wrote:
beq + jmp -- - why not just bne -- ?

still thinking about this ....Ahhh!! Yes! Thanks again. :)

---
Screen is still gray.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 23, 2012 12:24 pm 
Offline

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


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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