Jump to content
IGNORED

Bug Report Thread


kisrael

Recommended Posts

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
Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

  • 3 months later...

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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
  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 year later...

Hello. I am using Windows 7 Professional, and -VISUAL- BatariBasic Version 1.0 Build(568)

 

For some reason lately, I am unable to remove -unnecessary- code. For example, in an 8 bank program, sometimes I will add COLUBK=14 to test something. (When the background color is already defined at the start of the main loop)

 

However, later when I try to optimize my code and remove this unnecessary code snippet, the program will no longer run. For all intents and purposes, there should be absolutely no reason I need this, but when I remove it, the only error code I get is "Could not recomplie name.bas.bin", or occasionally just a completely black screen. It will also say under the Warnings window that frame10hi, frame10lo, etc.. are not valid keywords.

 

Yet when I add back this supposedly unnecessary and arbitrary COLUBK=14, it compiles and runs again. This seems to have only happened when my code became pretty large, but I still have plenty of space left. I cannot for the life of me figure out why. This is just one example. Often, at other times, previously, completely unnescessary code, when removed, will cause it to fail to compile, and I will have to put useless code back in just to get it to run.

 

I am a total amateur/noob, but it almost seems like it's not saving correctly.. WHatever backup or duplicate background files that are required for compiling are not matching up or something.

 

Can anybody help me? Thanks.

Edited by freshbrood
Link to comment
Share on other sites

I have this problem also, so you aren't alone.

 

I just adapted to saving many times when I code.

 

That program you type in is not batari Basic.

It is an editor, compiler, sprite/ playfield / sound and music IDE program. "Integrated Development Program" if I had to guess.

For instance I also use jEdit which can be set up to edit and compile similar to the VisualbB editor.

You can also code in just the simplest text editor, but that's plain crazy.

 

My need to find other ways to code was the time I neared the end of filling a 32K game.

Somewhere near that size every time you return on a line, VbB jumps to a place way above where you are coding.

 

VbB is an extremely valuable tool to use due to all the functions it contains.

 

Only other thing I've noticed is "text encoding types" can cause problems.

There is a Windows way of what is a return character, a UNIX way, etc.

I'm struggling with modifications to one of the compiler files.

The new one I was given causes compiler errors, the original one works, the original one edited with the new changes added works, and yes it is visually identical to the new file I was sent, but something behind the scenes is different which is why I mentioned "text encoding types".

  • Like 1
Link to comment
Share on other sites

Visual Batari Basic- I stand corrected. Can you suggest a similarly easy to use but alternative IDE, or a work around? After so much progress and such incredible results, this is really killing me. I think I have a rather mindblowing, amazing game that I'm trying to finish, and I've barely filled 3 banks. But for some reason there is certain code I just am unable to remove without breaking it. For the life of me I just cannot remove otherwise clearly useless code.

 

For now, is there a noob friendly alternate IDE that I can copy and paste the code I write using vbb into, to see if it compiles correctly in the other version? I have no idea how to use the DOS version of bataribasic. None whatsoever. This hurts.

 

@kdgarris, how exactly would I post the source file? Should I just upload the code I'm working on?

Link to comment
Share on other sites

@kdgarris, how exactly would I post the source file? Should I just upload the code I'm working on?

All you need to do is post the .bas file that isn't working:

 

How to Attach Files and Images

 

Just to make sure, you are using the latest version of batari Basic, right?

 

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

 

When I was working on long programs with VbB, I had to disable Enable Syntax Checking. Syntax checking is just too slow for long programs, but it didn't stop the program from running if I removed certain code.

 

I had the kind of trouble you are talking about when using def and sometimes when using smartbranching, so I stopped using both. I'm talking about completely insane, hair-pulling things that made absolutely no sense so I always avoid smartbranching and use if ... then goto __Label instead of if ... then __Label and my programming life became waaaaay less frustrating when I said goodbye to def.

  • Like 1
Link to comment
Share on other sites

Thank you for your response. I'm not sure how to disable Syntax Checking- it seems enabled by default and I can't figure out how to turn it off.

 

I haven't used def at all.

 

As far as smartbranching, my last good version (with the arbitrary useless code I want to delete) works with it on- but when I turn it off, the last good program also crashes.

 

I changed a LOT of the "then goto label" to "then label", because it seemed to save a lot of memory and worked fine. Should I add back the "goto" if I turn smartbranching off?

 

Also, visually I don't like spaces, and try to condense my code as tightly as possible, so instead of "x = 10" I wrote all "x=10" before. Do you think the lack of spacing well negatively affect it as well?

 

I will upload the sourcecode in a bit- it's on an off grid pc at the moment.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...