bogax Posted September 18, 2016 Share Posted September 18, 2016 (edited) 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 September 18, 2016 by bogax Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 4, 2016 Share Posted October 4, 2016 sometimes when we do something like if !(a & 1) then skip we'll get a complaint that skip is an unknown keywordit 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. Quote Link to comment Share on other sites More sharing options...
Sprybug Posted January 27, 2017 Share Posted January 27, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 27, 2017 Share Posted January 27, 2017 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. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted January 27, 2017 Share Posted January 27, 2017 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. Quote Link to comment Share on other sites More sharing options...
Sprybug Posted January 28, 2017 Share Posted January 28, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 28, 2017 Share Posted January 28, 2017 Once you guys figure out what the problem is, I'll update the bB page. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 28, 2017 Share Posted January 28, 2017 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. Quote Link to comment Share on other sites More sharing options...
Sprybug Posted January 28, 2017 Share Posted January 28, 2017 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? 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 28, 2017 Share Posted January 28, 2017 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. Quote Link to comment Share on other sites More sharing options...
Sprybug Posted January 28, 2017 Share Posted January 28, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
Sprybug Posted January 28, 2017 Share Posted January 28, 2017 (edited) 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 January 28, 2017 by Sprybug 2 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 28, 2017 Share Posted January 28, 2017 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 28, 2017 Share Posted January 28, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 28, 2017 Share Posted January 28, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 29, 2017 Share Posted January 29, 2017 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 29, 2017 Share Posted January 29, 2017 Looks good to me 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 29, 2017 Share Posted January 29, 2017 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. Quote Link to comment Share on other sites More sharing options...
freshbrood Posted June 10, 2018 Share Posted June 10, 2018 (edited) 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 June 10, 2018 by freshbrood Quote Link to comment Share on other sites More sharing options...
+Karl G Posted June 10, 2018 Share Posted June 10, 2018 Could you post a source file where you observe this issue? Quote Link to comment Share on other sites More sharing options...
iesposta Posted June 10, 2018 Share Posted June 10, 2018 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". 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted June 10, 2018 Share Posted June 10, 2018 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? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 10, 2018 Share Posted June 10, 2018 @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. 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted June 11, 2018 Share Posted June 11, 2018 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. Quote Link to comment Share on other sites More sharing options...
freshbrood Posted June 11, 2018 Share Posted June 11, 2018 (edited) Under the "Stand1" label, I cannot remove "COLUBK=14". It will crash. It's been doing a lot of funny things like that lately. Edited June 29, 2018 by freshbrood Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.