Jump to content

Photo

Bug Report Thread


267 replies to this topic

#251 bogax OFFLINE  

bogax

    Dragonstomper

  • 705 posts

Posted Sun Sep 18, 2016 2:34 PM

first (not really a bug)

   1915  f4c9    .L021 ;  a{0}  =  !a{0}
   1916  f4c9
   1917  f4c9        a5 d6       LDA a
   1918  f4cb        29 01       AND #1
   1919  f4cd        08       PHP
   1920  f4ce        a5 d6       LDA a
   1921  f4d0        29 fe       AND #254
   1922  f4d2        28       PLP
   1923  f4d3        d0 02       .byte.b $D0, $02
   1924  f4d5        09 01       ORA #1
   1925  f4d7        85 d6       STA a

there's got to be a better way, especially considering that bit indices are constants

 

 

second

 

sometimes when we do something like

 
if !(a & 1) then skip
 

we'll get a complaint that skip is an unknown keyword

it doesn't happen all the time

I haven't figured out exactly what will cause it


Edited by bogax, Sun Sep 18, 2016 2:38 PM.


#252 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,632 posts
  • Bitnik
  • Location:Canada

Posted Mon Oct 3, 2016 7:07 PM

sometimes when we do something like

 
if !(a & 1) then skip
 
we'll get a complaint that skip is an unknown keyword
it doesn't happen all the time
I haven't figured out exactly what will cause it


Looking at the code, it seems it should happen all the time if you've used a complex statement and a then...label. There wasn't an entirely clean way to fix this in the current code flow, so I added a check to skip the label as a keyword if the previous statement was a "then".

 

first (not really a bug)


I don't have an easy fix for this one, other than recommend people use bitwise math instead. ;)

While I was in the code base, I reordered memory so var0-z is now continuous. It makes more sense that way.

The new build is labeled "beta". If nobody reports issues in the next few weeks, I'll remove the old build and the "beta" tag.

#253 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 526 posts

Posted Fri Jan 27, 2017 2:48 AM

I may have found another problem in the DPC+ kernel.

Looks like VAR8 isn't completely available like the Batari documentation at Random Terrain's site states.

I was using it to store information for the sprites to use.  When certain things weren't working right, I couldn't see for the life of me what was wrong. I went over my code several times.  It seemed that what was being stored in VAR8 was for some reason holding the wrong value constantly.  I couldn't see what was causing it.  On a whim, I switched from VAR8 to VAR0 to see if it would make a difference and it did.  It worked fine after that, so VAR8 appears to be used by the kernel for something and not completely free to use like the documentation said.

Let me know what you guys find on that.

 

Thanks.



#254 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,632 posts
  • Bitnik
  • Location:Canada

Posted Fri Jan 27, 2017 7:38 AM

I compiled a test with the latest bB, and I couldn't reproduce this. I setup a trap in stella to detect memory access to $f4, and nada.

If you're using a lot of stack with nested gosubs, then the var* memory can be overwritten, starting with var8. Maybe this is the case here?

If you're comfortable in the debugger, just enter "trap f4", and you can check access to this memory. Comparing the address where stella detects a write to this memory with your program's *.list.txt can tell you where the overwrite happened in your basic program (or bB's routines)

If you're not comfortable with the above steps, PM me a zip the source, and I can take a look.

#255 SpiceWare OFFLINE  

SpiceWare

    Quadrunner

  • 11,194 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Fri Jan 27, 2017 10:27 AM

Stack collision does sound probable, I've even had that happen with C code running on the ARM.  It's what led me to add the Cartridge RAM tab in Stella.



#256 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 526 posts

Posted Fri Jan 27, 2017 6:49 PM

I compiled a test with the latest bB, and I couldn't reproduce this. I setup a trap in stella to detect memory access to $f4, and nada.

If you're using a lot of stack with nested gosubs, then the var* memory can be overwritten, starting with var8. Maybe this is the case here?

If you're comfortable in the debugger, just enter "trap f4", and you can check access to this memory. Comparing the address where stella detects a write to this memory with your program's *.list.txt can tell you where the overwrite happened in your basic program (or bB's routines)

If you're not comfortable with the above steps, PM me a zip the source, and I can take a look.

 

Where would I put in trap f4?  The compiler?  Stella?  It's possible it could be a stack issue.  In fact I thought it might be and was trying to reduce the nesting in a part where it was happening and it didn't seem to make a difference.  I was manually counting the routine nesting and when it happened after I had made the change and I was only 2 or 3 levels in when it happened.  I could put var0 back to var8 in my program and send it if you'd like.



#257 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,003 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Jan 27, 2017 6:52 PM

Once you guys figure out what the problem is, I'll update the bB page.



#258 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,632 posts
  • Bitnik
  • Location:Canada

Posted Fri Jan 27, 2017 8:43 PM

Where would I put in trap f4?  The compiler?  Stella?  It's possible it could be a stack issue.  In fact I thought it might be and was trying to reduce the nesting in a part where it was happening and it didn't seem to make a difference.  I was manually counting the routine nesting and when it happened after I had made the change and I was only 2 or 3 levels in when it happened.  I could put var0 back to var8 in my program and send it if you'd like.


The "trap f4" is in the stella debugger.

Send it my way. You can leave it as the current version that uses var0, as the write to var8 should still happen anyway. But please also send the *.list.txt file too, so I can track down exactly where the problem happens in the source code.

#259 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 526 posts

Posted Fri Jan 27, 2017 9:58 PM

The "trap f4" is in the stella debugger.

Send it my way. You can leave it as the current version that uses var0, as the write to var8 should still happen anyway. But please also send the *.list.txt file too, so I can track down exactly where the problem happens in the source code.

 

I'm new to using the Stella Debugger.  I know how to get into it. I typed in trap f4 in the prompt, and it said read|write.  So I went out, played it to about the point where it changes the value, but it didn't notify me live when it happened, is there something to look at, or go to see it happen, or maybe a text file or something?



#260 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,632 posts
  • Bitnik
  • Location:Canada

Posted Fri Jan 27, 2017 10:31 PM

If $f4 (aka var8) was read or written to at all, Stella would have interrupted your gameplay session, switched back to the debugger, and highlighted the line of assembly that accessed $f4.

#261 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 526 posts

Posted Sat Jan 28, 2017 1:01 AM

If $f4 (aka var8) was read or written to at all, Stella would have interrupted your gameplay session, switched back to the debugger, and highlighted the line of assembly that accessed $f4.

Weird, that didn't happen at all.  I tried it again and it doesn't jump back into the debugger.  But there is a point when it screen transitions in the game after going through a door that it goes from 00 to 65.



#262 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 526 posts

Posted Sat Jan 28, 2017 1:39 AM

It does look like you guys are right though.  The whole routine that involved the screen transition had a lot of nested routines in it.  I decided to make the first routine in the branch to be just a straight goto, since the only time it is called is in one spot and doesn't really need to be a gosub anyhow.  Once I did that, F4 stayed blank (00) after the screen transition.  It looks like there might be a stack limit to 4 maybe 5 nested gosubs before you go over your stack and it starts effecting variables.  First one being VAR8.  It's not really a bug Random Terrain, but it might be something you want to mention in the documentation when it comes to your stack, so people don't spend a week going insane like me! XD


Edited by Sprybug, Sat Jan 28, 2017 1:40 AM.


#263 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,003 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Jan 28, 2017 2:44 AM

It does look like you guys are right though.  The whole routine that involved the screen transition had a lot of nested routines in it.  I decided to make the first routine in the branch to be just a straight goto, since the only time it is called is in one spot and doesn't really need to be a gosub anyhow.  Once I did that, F4 stayed blank (00) after the screen transition.  It looks like there might be a stack limit to 4 maybe 5 nested gosubs before you go over your stack and it starts effecting variables.  First one being VAR8.  It's not really a bug Random Terrain, but it might be something you want to mention in the documentation when it comes to your stack, so people don't spend a week going insane like me! XD

 

Thanks. I'll do that some time later today after I get some sleep.



#264 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,632 posts
  • Bitnik
  • Location:Canada

Posted Sat Jan 28, 2017 11:10 AM

Thanks. I'll do that some time later today after I get some sleep.


Just a heads up that var8 is the last variable before the reserved stack area only for the DPC+ bB kernel. The standard kernel has "statusbarlength" in that location. The multisprite kernel has "spritesort5" there. So a general note about using too many nested subroutine calls causing variables to be overwritten, and weird things ensuing, will suffice.

#265 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,632 posts
  • Bitnik
  • Location:Canada

Posted Sat Jan 28, 2017 11:20 AM

It does look like you guys are right though.  The whole routine that involved the screen transition had a lot of nested routines in it.  [...]



Great that you tracked it down. Often times you can replace those gosubs with gotos, in nested subs. i.e. this code...
 
mymain
   [bunch of code]
   gosub subroutine1
   [bunch of code]

subroutine1
   if foo=bar gosub subroutine2a else gosub subroutine2b
   return

subroutine2a
   [bunch of code]
   return

subroutine2b
   [bunch of code]
   return

Is equivalent to this code, but this one uses less stack, a bit less rom, and is slightly quicker...
 
mymain
   [bunch of code]
   gosub subroutine1
   [bunch of code]

subroutine1
   if foo=bar goto subroutine2a else goto subroutine2b

subroutine2a
   [bunch of code]
   return

subroutine2b
   [bunch of code]
   return

I use subs more than most 2600 coders, I suspect, but I really try to avoid going more than 3 levels deep. Aside from memory and cycle efficiency issues, I've seen some coders get into the random-crash weeds this way, when they lose track of how deep they are. It's more a symptom of their code not having cleanly defined modules, but the 2600 rewards creating working spaghetti code more than other platforms do.

#266 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,003 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Jan 28, 2017 9:52 PM

Can you guys look at this first and see if it also needs to be updated?

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#glossary_subroutines

 

Thanks.



#267 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,632 posts
  • Bitnik
  • Location:Canada

Posted Sat Jan 28, 2017 10:25 PM

Looks good to me

#268 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,003 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Jan 29, 2017 2:43 AM

Looks good to me


Thanks. Looks like more than one area is going to need an update and I better make sure there are related links to that glossary entry. This is going to take a little longer than I expected. I'll see if I can get it done before Sunday is over.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users