RevEng Posted February 13, 2020 Share Posted February 13, 2020 Just a follow-up that TwentySixHundred tracked this down, in a PM. It appears that pfpixel was being given some off-screen data in certain circumstances. It's a known bB limitation that you need to keep pf* function coordinates within bounds, so it's not a bB bug. 2 Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted February 21, 2020 Share Posted February 21, 2020 (edited) I have found a bug with the score in DPC+ where by adding this code score = score + 252 score = score - _blahblah or score = score + 252 score = score - t One random digit becomes a garbled mess. If i comment out 'score = score - t' then everything is fine again. The variable 't' only increments by 9 for every pfread and never exceeds 252. Edited February 21, 2020 by TwentySixHundred Quote Link to comment Share on other sites More sharing options...
+Karl G Posted February 21, 2020 Share Posted February 21, 2020 I don't have a link handy at the moment, but take a look in the batari Basic guide for the discussion about the score and binary coded decimal. in short, the score is stored as binary coded decimal, and you're adding a variable which is not. 1 Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted February 21, 2020 Share Posted February 21, 2020 (edited) 22 minutes ago, Karl G said: I don't have a link handy at the moment, but take a look in the batari Basic guide for the discussion about the score and binary coded decimal. in short, the score is stored as binary coded decimal, and you're adding a variable which is not. Thanks! yes i was just about to remove the post as i worked this out. That solved the issue, i really didn't think it aplied for the math that added the to the variable (thought it was the total value) turns out the math also needs to be BCD ? Edit: Actually it still does it, i will keep playing around with it however everything that stores the value is BCD. Might need to code it a different way/ Edited February 21, 2020 by TwentySixHundred Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 21, 2020 Share Posted February 21, 2020 36 minutes ago, TwentySixHundred said: Thanks! yes i was just about to remove the post as i worked this out. That solved the issue, i really didn't think it aplied for the math that added the to the variable (thought it was the total value) turns out the math also needs to be BCD ? Edit: Actually it still does it, i will keep playing around with it however everything that stores the value is BCD. Might need to code it a different way/ Have you looked at this: randomterrain.com/atari-2600-memories-batari-basic-commands.html#bcd_dec Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted February 21, 2020 Share Posted February 21, 2020 10 minutes ago, Random Terrain said: Have you looked at this: randomterrain.com/atari-2600-memories-batari-basic-commands.html#bcd_dec Yeah i have, for some reason it just wasn't liking my subtraction however i never tested in dec mode. It's all good as i scrapped that idea and rewrote for the cost of an additional 8bytes. Rather then subtracting the value of that variable i just added the score per playfield check with and 'else' condition. I had plans to still use that variable globally later down the track and i still can, as the next feature doesn't require addition or subtraction to the score. I was just trying to eliminate any unnecessary code and share the variable but for the cost of 8bytes im happy ? Quote Link to comment Share on other sites More sharing options...
freshbrood Posted May 14, 2020 Share Posted May 14, 2020 Version 1.0, build 568, Win7 64bit. Whenever I post even a small line of code the program will endlessly scroll up then freeze and crash. Am I doing something wrong? It's making me crazy! Also, in forums, I see that I can edit a post but is it possible for me to delete a post completely? I only recently started posting here and sometimes I reply in the wrong forum. I don't want to be annoying. Thanks for any help. Quote Link to comment Share on other sites More sharing options...
+splendidnut Posted June 24, 2022 Share Posted June 24, 2022 Seems that bBasic doesn't like simple expresssions wrapped in parenthesis: .L0803 ; rem --- set bonus if red plane group .L0804 ; if NewCOLUP1 = _CI_RedPlane then w_stage_bonus_counter = (32 - stage) LDA NewCOLUP1 CMP #_CI_RedPlane BNE .skipL0804 .condpart149 LDA #(32 SEC SBC stage) STA w_stage_bonus_counter .skipL0804 Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 25, 2022 Share Posted June 25, 2022 Seems to be working on my end... 735 8000 .L04 ;; w_stage_bonus_counter = ( 32 - stage ) 736 8000 737 8000 ; complex statement detected 738 8000 a9 20 LDA #32 739 8002 38 SEC 740 8003 e5 e9 SBC stage 741 8005 85 e8 STA w_stage_bonus_counter From the source code in your generated file, it looks like the preparser didn't add whitespace to the end brace. Guessing that something earlier is leaving the preparser in a bad state. You can likely work around it by manually adding the whitespace to the braces. 2 Quote Link to comment Share on other sites More sharing options...
+splendidnut Posted June 25, 2022 Share Posted June 25, 2022 Yes. I fixed the issue by adding whitespace. It's still a tokenizer/parser bug that should be probably be fixed. Also, I think I found a limitation on the number of constants that are allowed to be defined. If the user exceeds that limitation, the compiler (and/or assembler) should notify the user of that issue. Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 25, 2022 Share Posted June 25, 2022 2 hours ago, splendidnut said: Yes. I fixed the issue by adding whitespace. It's still a tokenizer/parser bug that should be probably be fixed. Yep, I'd just need more info to fix it, since I can't reproduce it. It could be there's a missing "end" or some other similar syntax issue that's leaving the preparser stuck in an incorrect state. That's my working theory anyway, but it's all guessing at this point. Agreed that the compiler should error on constant overflow. I don't have personal cycles to do more than critical bug fixes, and even then not enough for that. I do accept pull requests. Quote Link to comment Share on other sites More sharing options...
+splendidnut Posted June 25, 2022 Share Posted June 25, 2022 The code was within 1942-Bb. I ended up rewriting that code in a different way, so it's no longer an issue. But, I was able to recreate it (using AtariDevStudio v0.7.5 with bBasic v1.5.) If you replace https://github.com/splendidnut/1942-bB/blob/main/src/1942_HSC.bas#L1388 with: rem --- set bonus if red plane group if NewCOLUP1 = _CI_RedPlane then w_stage_bonus_counter = (32-stage) rem w_stage_bonus_counter = r_stage_bonus_counter & %01111111 Then the Assembly output appears as follows: .L0797 ; rem --- set bonus if red plane group .L0798 ; if NewCOLUP1 = _CI_RedPlane then w_stage_bonus_counter = (32 - stage) LDA NewCOLUP1 CMP #_CI_RedPlane BNE .skipL0798 .condpart148 LDA #(32 SEC SBC stage) STA w_stage_bonus_counter .skipL0798 I completely understand not having the time/energy to commit to fixing this. So, no worries. ? Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 25, 2022 Share Posted June 25, 2022 Ok, I was close-enough able to reproduce it. "Close-enough" because the source relies on the pluscart bB fork, so I don't get a successful compile, but I can see the issue in the generated list file. It seems this statement is throwing the preparser into a bad state... if temp2 < 226 then _read_attack_data ...the issue appears to be the "_data" ending of the label name, which is switching the preparser into "data" statement preparsing mode, which it will be stuck in until the preparser encounters an "end" statement. When I change all the labels and variables that end in "_data" to instead end with "_dat" or "_qdata", the reported issue goes away. To avoid unpredictable errors, I'd recommend at this time to not end symbols with an underscore followed by a valid bB statement name. I'll see if this can be fixed when I have more time (and frankly fortitude to dive into the lex code) but at least it's now "known bug with work-around" status. 4 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 25, 2022 Share Posted June 25, 2022 24 minutes ago, RevEng said: To avoid unpredictable errors, I'd recommend at this time to not end symbols with an underscore followed by a valid bB statement name. I'll see if this can be fixed when I have more time (and frankly fortitude to dive into the lex code) but at least it's now "known bug with work-around" status. What happens if the first letter of the valid bB statement name is capitalized? Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 25, 2022 Share Posted June 25, 2022 2 minutes ago, Random Terrain said: What happens if the first letter of the valid bB statement name is capitalized? That works to avoid the issue, too. 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 29, 2022 Share Posted June 29, 2022 It seems the bB priming reads were problematic. (reverted them in the github master.) If there isn't any other bug reported between now and the weekend, I'll push out a release with the correction. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 2, 2022 Share Posted July 2, 2022 No other issues were reported. I've gone ahead an put out release v1.7 which reverts the problematic DPC+ priming reads. 2 Quote Link to comment Share on other sites More sharing options...
Fort Apocalypse Posted July 19, 2022 Share Posted July 19, 2022 (edited) These may be a couple of known bugs, but I ran into them today in bB 1.7 and 1.5 (and they may exist in other versions). The first bug seems to happen when it hits an expression multiplied by a hardcoded number (not variable) that's between 0 and 1, including 0 but not including 1. It gets into an infinite loop outputting the asm. The second bug is a similar situation, but with division, and it just freezes during output of the asm. These happen when "preprocess$EXT<$1 | 2600basic$EXT -i "$bB" >bB.asm" is executed. I removed the part that redirects to bB.asm to get the output below. Here's an example: include div_mul.asm b = ( 1 + a ) * 0.9 mainloop n=n+1 : COLUBK=n drawscreen goto mainloop Output: ; complex statement detected LDA #0 SEC SBC b asl asl clc adc Areg asl clc adc Areg sta temp2 asl asl clc adc temp2 asl clc adc temp2 sta temp2 ... (outputs last 8 lines over and over) Similarly, it's frozen / hung on division, but in this case it just stops outputting, though the process keeps going: include div_mul.asm b = ( a + 1 ) / 0.9 mainloop n=n+1 : COLUBK=n drawscreen goto mainloop -> ; complex statement detected LDA a CLC ADC #1 (stuck here) Edited July 19, 2022 by Fort Apocalypse Quote Link to comment Share on other sites More sharing options...
Fort Apocalypse Posted July 19, 2022 Share Posted July 19, 2022 (edited) Another bug that may be known already- I don't know: If you add or subtract an integer value of 1 to a float variable, it works as expected, but if you try to add or subtract an integer value of 2 or more, it produces an unexpected result. However, if you add or subtract a float to or from a float, it works as expected. This happens in bB 1.7. I didn't try other versions. I attached code and binary to reproduce it using first joystick to add or subtract 1 (down/up) or 2 (left/right) and display as the empty space between two missiles and as score. bb_bug_2022_07_19.bas.bin bb_bug_2022_07_19.bas.asm bb_bug_2022_07_19.bas Edited July 19, 2022 by Fort Apocalypse Quote Link to comment Share on other sites More sharing options...
Fort Apocalypse Posted July 25, 2022 Share Posted July 25, 2022 An inconsistency(?) in how bB handles partially defined conditionals: This actually executes and always hits the "else": if somenum< then COLUBK=$0E else pfclear 42 This produces the compilation error, "if-then too complex for logical OR": if othernum> then COLUBK=$44 else pfclear 255 bb_bug_20220725.bas.bin bb_bug_20220725.bas Quote Link to comment Share on other sites More sharing options...
+Karl G Posted July 27, 2022 Share Posted July 27, 2022 On 7/25/2022 at 12:06 PM, Fort Apocalypse said: An inconsistency(?) in how bB handles partially defined conditionals: This actually executes and always hits the "else": if somenum< then COLUBK=$0E else pfclear 42 This produces the compilation error, "if-then too complex for logical OR": if othernum> then COLUBK=$44 else pfclear 255 bb_bug_20220725.bas.bin 4 kB · 1 download bb_bug_20220725.bas 315 B · 1 download I would think that in the case of malformed conditional statements we should expect undefined behavior, unless I'm missing something here? Quote Link to comment Share on other sites More sharing options...
orange808 Posted July 27, 2022 Share Posted July 27, 2022 30 minutes ago, Karl G said: I would think that in the case of malformed conditional statements we should expect undefined behavior, unless I'm missing something here? Given that it is Basic, I think users would expect the parser to catch it and throw an error. It's a hobby project, so it may or may not ever get patched, but I wouldn't expect Basic to trust users to know what they are doing. 1 Quote Link to comment Share on other sites More sharing options...
T Studios Posted December 10, 2022 Share Posted December 10, 2022 On 25/7/2005 at 7:14, batari said: Se ha confirmado que se trata de un error... Se solucionará en la próxima versión. 🙂hi, I need you to solve a batari basic error. The error is that every time I create a project correctly (without spaces in the name and in a good location) and after compiling 4 or 5 times the program deletes the file .bas of the project then it doesn't let compile try everything like reinstall grab other .bas files and watch videos but nothing works for me😪 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted December 11, 2022 Share Posted December 11, 2022 22 hours ago, T Studios said: 🙂hi, I need you to solve a batari basic error. The error is that every time I create a project correctly (without spaces in the name and in a good location) and after compiling 4 or 5 times the program deletes the file .bas of the project then it doesn't let compile try everything like reinstall grab other .bas files and watch videos but nothing works for me😪 Hi, this isn't a bug report but a usage issue, so in the future you should probably not post it in this topic. To help you, I'll need to know what you are using to compile batari Basic code (compiling from the command line, or using something like Atari Dev Studio or Visual batari Basic). If you are compiling from the command line, then what are you using as your editor, and where are you putting your source files? There's absolutely no reason why the source file would get deleted normally. 3 Quote Link to comment Share on other sites More sharing options...
T Studios Posted December 12, 2022 Share Posted December 12, 2022 On 10/12/2022 at 21:02, Karl G said: Hola, este no es un informe de error sino un problema de uso, por lo que en el futuro probablemente no deberías publicarlo en este tema. Para ayudarlo, necesitaré saber qué está usando para compilar el código Batari Basic (compilando desde la línea de comando o usando algo como Atari Dev Studio o Visual Batari Basic). Si está compilando desde la línea de comando, entonces, ¿qué está usando como editor y dónde está colocando sus archivos fuente? No hay absolutamente ninguna razón por la que el archivo de origen se elimine normalmente. I use the bb compiler but it gives me an error I use visual batari basic these are the configurations Emulator = C:\Program Files\Stella\Stella.exe Compiler = D:\*********\bB\2600basic.exe Set Environment Variable = True Set System Path = True Save Open Files = False Cleanup Compilation Files = False Enable Syntax Checking = True Load Start Web Page = False Autosave = True every 5 minutes Backup Projects = False 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.