1200XL M.U.L.E. Posted March 14, 2021 Share Posted March 14, 2021 7 hours ago, dmsc said: No, that should not happen. Please, post the code that shows an error (you can take a picture of your TV or monitor). As @vitoco said, "bad loop" is also shown on other constructs. I should clarify parser errors, currently the possible errors are: - "undef label" : You tried to call a PROC that was never defined. - "too long" : The current line is too long for the parser - this means that the generated code is more than 256 bytes or that the expression is too complicated. - "bad loop" : This means that the parser found an "ELSE/ENDIF/ENDPROC/WEND/LOOP/UNTIL/NEXT" without the corresponding starting "IF/PROC/WHILE/DO/REPEAT/FOR", or an "EXIT" outside a loop. - "no end loop/proc/if" : After the file was completely parsed, there is a missing loop ending. - "parse error" : The parser could not parse a complete line. Note that the parser is greedy, it always parses the longest possible part of a line, so the reported position is the rightmost position which the parser could reach. @dmsc Here are pictures of my code. My code is using the TIME function to count seconds. I would not be surprised if I made an error in my code construction. You can see the "bad loop" error on top. Then I simplify my loop. I assumed that loop would run one time. Error persists. Then I removed the loop completely. I still see "bad loop" error ... but I deleted my loop. 7 hours ago, dmsc said: This was added as popular request: whenever you modify the source, the IDE will ask to save the old file before loading a new one (or any other operation that clears the buffer). You can skip the save by pressing CONTROL-C, then you will see the LOAD prompt. Ohh, this feels a little awkward and was not intuitive. The prompt says, "Save?" like a question so I say "N" to be no. Instead the IDE saves my code under a file named N. Maybe change the prompt to be "Save? (Esc to skip)" or something more obvious like that? Did I miss this in the manual? Thank you! Quote Link to comment Share on other sites More sharing options...
snicklin Posted March 14, 2021 Share Posted March 14, 2021 Please excuse me for the expansive code. I have tried to cut it short, but whenever I do, I am not able to pinpoint the exact cause of this issue. I will show you some code which does not work. @HELLO ' Get the current time S=TIME ' Clear memory for the database @ClearMemory 180,10 ' Inform user that the DB is being instantiated ? "Instantiating DB" ' Location of the DB in memory DBLocation=32768 ' One off step to set up the DB @InstantiateDB DBLocation,1024,16,240 ' Note that the DB has been instantiated ? "DB Instantiated" @TEST ' Sample call to DB system @GetByteFromDB 0,0,5 ' Get the final completion time and inform the user of the running time T=TIME ? "Time=";(T-S) @EndlessLoop ' Sets up the database in memory (one-off step) PROC InstantiateDB Location Size DBVarOffset DBVarSize DBVarLocation=Location+DBVarOffset @ClearMemory Location,Size @SetDBHeader Location,256,DBVarLocation ENDPROC PROC SetDBHeader Location Size DBVarLocation VarTable=DBVarLocation DPOKE Location,VarTable ENDPROC PROC ClearMemory Location Size EXEC FillMemory Location,Size,0 ENDPROC PROC FillMemory Location Size Value FOR I=Location TO Location+Size-1 POKE I,Value NEXT I ENDPROC PROC EndlessLoop WHILE 1=1 WEND ENDPROC ' Table Layout ' 0: Record Width (Bytes) ' 1: Cartridge bank (0=In memory) ' 2-5: Table Name (4 chars of name at least) ' 6: 0= Read/Write, 1=Read only ' 7,8: MaxNo Records ' 9,10: Pointer to record 0 of table ' 11-15: Currently unused PROC HELLO TEST=DPEEK(1) ENDPROC PROC TEST DATALOCATION=DPEEK(1) ENDPROC PROC GetDataLocation DataTableNo DataRecordNo DataOffset DATALOCATION=DPEEK(1) DBPTR_CurrentTable=DPEEK(DBVarLocation+(DataTableNo*16)) DBBYTE_RecordWidth=PEEK(DBPTR_CurrentTable) TEMPByte=PEEK(DBPTR_CurrentTable+1) 'DATALOCATION=DPEEK(1) 'DataLocation=DataLocation+(DBBYTE_RecordWidth*DataRecordNo)+DataOffset ENDPROC PROC SwitchMediaOn IF PEEK(TEMPByte) = 1 ' Do some cartridge bank switching routine here ENDIF ENDPROC PROC SwitchMediaOff IF PEEK(TEMPByte) = 1 ' Do some cartridge bank switching routine here ENDIF ENDPROC PROC GetByteFromDB TableNo RecordNo Offset @GetDataLocation TableNo,RecordNo,Offset @SwitchMediaOn 'DBByte_Return=PEEK(DataLocation) @SwitchMediaOff ENDPROC PROC GetWordFromDB TableNo RecordNo Offset @GetDataLocation TableNo,RecordNo,Offset @SwitchMediaOn 'DBByte_Return=DPEEK(DataLocation) @SwitchMediaOff ENDPROC When I compile, this is what I get: C:\Users\Steve\Desktop\FastBasic4.5>fb-int MyBas\Lib.bas Compiling 'Lib.bas' to assembler. C:\Users\Steve\Desktop\FastBasic4.5\MyBas\Lib.bas:75:7: parse error, expected: '=' ENDPROC<--- HERE --> I do not think that there is an actual problem with the ENDPROC. If there was, it should have complained at line 75, the end of the HELLO procedure. There seems to be something odd going on if you have a DPEEK inside a PROC, I could be wrong though. Quote Link to comment Share on other sites More sharing options...
vitoco Posted March 14, 2021 Share Posted March 14, 2021 6 hours ago, 1200XL M.U.L.E. said: I still see "bad loop" error ... but I deleted my loop. Bug found! The problem was caused by the NEXT_TIME variable. It seems that the line NEXT_TIME = CURR_TIME + 60 It seems that the parser is splitting the variable name as "NEXT" and "_TIME". The NEXT component in the FOR-NEXT structure does not require the variable name like in Atari BASIC, and the remaining statement is discarded. This parses OK: FOR X=1 TO 5 ? X NEXT_TIME=10 but the loop runs only 1 time. It is strange how the code following the "NEXT" is parsed. With some expressions parses OK, but it fails with a "parser error" on another ones. It also fails if there is an undeclared variable name. Quote Link to comment Share on other sites More sharing options...
vitoco Posted March 14, 2021 Share Posted March 14, 2021 I pasted your code in the IDE and it failed in the ENDPROC of the TEST procedure, like waiting for something different than "PROC" after the "END", or complaining for the "END". I isolated the problem into this: @TEST PROC TEST DATALOCATION=DPEEK(1) ENDPROC Trying to compile this, I get a "bad loop" error, but if I rename the variable "DATALOCATION" to "DATLOCATION" (without an "A"), it parses and runs OK. Just like with the "NEXT_TIME" variable, the problem seems to be that using some reserved words at the beginning of variables names breaks something in the parser. On 3/9/2021 at 12:45 AM, dmsc said: - The parser is more robust to syntax errors, I discovered some erroneous inputs that could slow down the parser a lot. I tried this test code in version 4.4 (with "EXEC" instead of "@") and I got the same "bad loop" error, so it is not something new. ? I didn't face this problem before, because all my FastBasic programs are tenliners, with single char variable names.... Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 14, 2021 Author Share Posted March 14, 2021 Hi! 7 hours ago, 1200XL M.U.L.E. said: @dmsc Here are pictures of my code. My code is using the TIME function to count seconds. I would not be surprised if I made an error in my code construction. Oh, the problem is the variable named "NEXT_TIME", this is parsed as a "NEXT" followed by garbage, but at this time is too late, as the "NEXT" triggered the "loop error". 17 minutes ago, vitoco said: Bug found! The problem was caused by the NEXT_TIME variable. It seems that the line NEXT_TIME = CURR_TIME + 60 It seems that the parser is splitting the variable name as "NEXT" and "_TIME". Yes. I tough that this couldn't happen, but the condition was 17 minutes ago, vitoco said: The NEXT component in the FOR-NEXT structure does not require the variable name like in Atari BASIC, and the remaining statement is discarded. This parses OK: FOR X=1 TO 5 ? X NEXT_TIME=10 but the loop runs only 1 time. It is strange how the code following the "NEXT" is parsed. With some expressions parses OK, but it fails with a "parser error" on another ones. It also fails if there is an undeclared variable name. Yes, the parser is really confused after the NEXT is found. But this can be fixes, by checking there is an end-of-line before checking if there is a FOR loop. Fixed version attached. 7 hours ago, 1200XL M.U.L.E. said: Ohh, this feels a little awkward and was not intuitive. The prompt says, "Save?" like a question so I say "N" to be no. Instead the IDE saves my code under a file named N. Maybe change the prompt to be "Save? (Esc to skip)" or something more obvious like that? Did I miss this in the manual? Yes, it is at the start of the manual. Prompts are all the same length: SAVE, LOAD, NAME, LINE, because the code to input the line is the same in all cases - it is not a simple "INPUT" to filter-out control keys, see the code at https://github.com/dmsc/fastbasic/blob/master/src/editor.bas#L314 and also the InputFileName procedure. Perhaps I could add a "NAME" after all the prompts, this will add 11 bytes to the IDE, like "SAVE NAME?", "LOAD NAME?", "EXEC NAME?", and "LINE NUM ?". What do you think? Have Fun! fastbasic-v4.5.1.atr 1 Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 14, 2021 Author Share Posted March 14, 2021 Hi! 25 minutes ago, vitoco said: I pasted your code in the IDE and it failed in the ENDPROC of the TEST procedure, like waiting for something different than "PROC" after the "END", or complaining for the "END". I isolated the problem into this: @TEST PROC TEST DATALOCATION=DPEEK(1) ENDPROC Trying to compile this, I get a "bad loop" error, but if I rename the variable "DATALOCATION" to "DATLOCATION" (without an "A"), it parses and runs OK. Yes, this is basically the same as above, but harder to fix... Here, the parser sees "DATA", then the word "LOCATION", so it defines a new label called "LOCATION" and stores the label address. Problem is that *before* storing the label address, the parser needs to emit a JUMP over the data, so it adds a "fake loop", this allows the parser to detect the end of the DATA line and store that address in the JUMP. Now, when the parser continues, it finally error outs because the "()" after the DATA label are not there, so it roll-backs the parsing state - but not the loop state, so the DATA loop will be kept open. Rolling back the loop state is not possible, as there is too much state to keep. Fro the time being, I prefer to simply document in the manual that variable names can't start with "DATA" (or "IF"). In fact, in Atari BASIC variable names can't start with any statement, I have tried very hard to make the parser more flexible by allowing almost all names. Have Fun! Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 14, 2021 Author Share Posted March 14, 2021 Hi! 1 hour ago, snicklin said: When I compile, this is what I get: C:\Users\Steve\Desktop\FastBasic4.5>fb-int MyBas\Lib.bas Compiling 'Lib.bas' to assembler. C:\Users\Steve\Desktop\FastBasic4.5\MyBas\Lib.bas:75:7: parse error, expected: '=' ENDPROC<--- HERE --> I do not think that there is an actual problem with the ENDPROC. If there was, it should have complained at line 75, the end of the HELLO procedure. The error is really surprising, but expected ? As I explained above, the variable that starts with DATA above that line starts a DATA statement, so the parser thinks that we are inside a DATA. when the ENDPROC is parsed, it can't parse as a real ENDPROC, as this is not valid inside a DATA, so it assumes it should ve a variable named "ENDPROC", and it misses the "=" setting the value of the variable. I will add detecting of variables starting with "DATA" to the cross-compiler, so it errors out in the line before, this will make the error code much easier to understand. Have Fun! Quote Link to comment Share on other sites More sharing options...
vitoco Posted March 14, 2021 Share Posted March 14, 2021 1 hour ago, dmsc said: In fact, in Atari BASIC variable names can't start with any statement, I have tried very hard to make the parser more flexible by allowing almost all names. Atari BASIC has the LET statement to allow variable names to start with a reserved word. See this: Line 50 could be written as the following line and it would be OK: 50IFA=1ANDAND=5THENPRINTAND You have done a very good work here by checking if the variable after the reserved word already exists (*), but it seems that there are some places where a variable is not required that bangs the parser, like in DATA and NEXT. (*) The check for current variables sometimes might be confusing: a variable named IFA will be parsed OK on asignment by FastBasic only if A is not already used in the listing, but if multiple asignments are done to IFA variable, the parser will fail with a "no end loop/proc/if" error for the following assignments. Also, an asignment like SOUNDFX=1 might turn off sound voice 0 or 1 depending on the current value of FX variable, or it simply won't turn any voice and define the variable as expected if the FX variable does not exist (yet, at least for the current parsed line). Quote Link to comment Share on other sites More sharing options...
1200XL M.U.L.E. Posted March 14, 2021 Share Posted March 14, 2021 11 hours ago, vitoco said: Bug found! The problem was caused by the NEXT_TIME variable. It seems that the line NEXT_TIME = CURR_TIME + 60 @vitoco Thanks for jumping in with @dmsc to help me here. ? OK - lesson learned. I should not start my variable names with statements. The code runs and I even compiled it to an executable file! 10 hours ago, dmsc said: Yes, it is at the start of the manual. Prompts are all the same length: SAVE, LOAD, NAME, LINE, because the code to input the line is the same in all cases - it is not a simple "INPUT" to filter-out control keys, see the code at https://github.com/dmsc/fastbasic/blob/master/src/editor.bas#L314 and also the InputFileName procedure. Perhaps I could add a "NAME" after all the prompts, this will add 11 bytes to the IDE, like "SAVE NAME?", "LOAD NAME?", "EXEC NAME?", and "LINE NUM ?". What do you think? Have Fun! @dmsc Looks like I need to (re)read the manually more carefully. I was probably too excited to jump into coding. I think this is where I just need to learn to use the tool as it is. If you are going to spend energy updating this platform then I would like to see better error reporting. Give a line number where the error is found? I don't know how complicated or not that would be. Again - very, very good work here! Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 15, 2021 Author Share Posted March 15, 2021 Hi! 15 minutes ago, 1200XL M.U.L.E. said: Looks like I need to (re)read the manually more carefully. I was probably too excited to jump into coding. I think this is where I just need to learn to use the tool as it is. If you are going to spend energy updating this platform then I would like to see better error reporting. Give a line number where the error is found? I don't know how complicated or not that would be. This is already done: on parsing errors, the cursor is placed in the line and column of the error! Have Fun! 1 Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 15, 2021 Author Share Posted March 15, 2021 Hi! 20 hours ago, 777ismyname said: I will help some more on the manual! All of the previous work and a lot more I had done was on a laptop that was stolen a few months back. Just let me know what I need to do! Thanks (again) for the offer. I don't have specific needs for the manual, normally is other people that notices the omissions. For example, @vitoco noted that the INC and DEC statements does not mention that they do work on word arrays but not in byte of floating point arrays. I will add a note to both. Problem is, the manual will keep growing and probably become harder to read, specially for a novice. There is a line between writing a "specification document" or a "beginners guide", and I think that the manual should be both approachable without being too technical. Perhaps it is better to write two manuals, one more like a guide and other with the full description of the statements - but having too much documentation also is not good, as people will not read it and won't find what they need. Any toughs? Have Fun! 1 Quote Link to comment Share on other sites More sharing options...
1200XL M.U.L.E. Posted March 15, 2021 Share Posted March 15, 2021 1 hour ago, dmsc said: Hi! This is already done: on parsing errors, the cursor is placed in the line and column of the error! Have Fun! I never realized that. Sometimes I miss the obvious when looking for the not-so-obvious. ? Thank you for the kick in the right direction! Quote Link to comment Share on other sites More sharing options...
snicklin Posted March 15, 2021 Share Posted March 15, 2021 Ahhhh!!!!! I went around in circles, unaware it was something as silly as the name of my variable! As I am compiling everything, I do not mind long and descriptive variable names, forgetting its name could clash with a statement. Thank you. Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 15, 2021 Author Share Posted March 15, 2021 Hi! 12 hours ago, vitoco said: I pasted your code in the IDE and it failed in the ENDPROC of the TEST procedure, like waiting for something different than "PROC" after the "END", or complaining for the "END". I isolated the problem into this: @TEST PROC TEST DATALOCATION=DPEEK(1) ENDPROC Trying to compile this, I get a "bad loop" error, but if I rename the variable "DATALOCATION" to "DATLOCATION" (without an "A"), it parses and runs OK. Ok, I also fixed this. Was easier than expected, I split the parsing of the label and the starting of the DATA/DLI/PROC (the three use the same code), and now the above parses ok. Current version 4.5.2 attached. 25 minutes ago, snicklin said: Ahhhh!!!!! I went around in circles, unaware it was something as silly as the name of my variable! As I am compiling everything, I do not mind long and descriptive variable names, forgetting its name could clash with a statement. Just use attached version, or download the cross-compiler and manual from github: https://github.com/dmsc/fastbasic/releases/ Have Fun! fastbasic-v4.5.2.atr 1 Quote Link to comment Share on other sites More sharing options...
CuloMajia Posted March 15, 2021 Share Posted March 15, 2021 Fast Basic has bought something amazing to the Atari Community. Old TurboBasic XL, Basic XL / XE games, may be able to be ported to Fast Basic and bring a whole new life to them. I am digging up some old games and see what I can do with them. I figured out how to use external data like for fonts, sprites, ML routines, music. Inside a separate assembly file do: .segment "ALIGNDATA" CHARSET_GAME: .incbin "GAMEFONT.FNT" CHARSET_GAME_HI = >CHARSET_GAME .export CHARSET_GAME .export CHARSET_GAME_HI Inside the program: POKE 756,@CHARSET_GAME_HI ML routines. If you still have the original assembly. You need to eliminate the first PLA that grabs the # of bytes pushed onto the 6502 stack. I believe the parameters are in reverse order. Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 15, 2021 Author Share Posted March 15, 2021 Hi! 2 hours ago, CuloMajia said: Fast Basic has bought something amazing to the Atari Community. Old TurboBasic XL, Basic XL / XE games, may be able to be ported to Fast Basic and bring a whole new life to them. I am digging up some old games and see what I can do with them. I figured out how to use external data like for fonts, sprites, ML routines, music. Inside a separate assembly file do: .segment "ALIGNDATA" CHARSET_GAME: .incbin "GAMEFONT.FNT" CHARSET_GAME_HI = >CHARSET_GAME .export CHARSET_GAME .export CHARSET_GAME_HI Inside the program: POKE 756,@CHARSET_GAME_HI As "CHARSET_GAME_HI" is 8 bit only, you can make the code a little smaller by using " .exportzp CHARSET_GAME_HI" and then " POKE 756, @@CHARSET_GAME_HI ". The "@@" means "import from assembly as 8 bit", the ".exportzp" means "export as an 8 bit". 2 hours ago, CuloMajia said: ML routines. If you still have the original assembly. You need to eliminate the first PLA that grabs the # of bytes pushed onto the 6502 stack. I believe the parameters are in reverse order. I suspect the parameters are in the same order, but I'm starting to doubt it as you are the second one that said this ? Anyway, most ML routines could be replaced with usage of "DLI", "MOVE" and "PMGRAPHICS". Have Fun! Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted March 15, 2021 Share Posted March 15, 2021 14 minutes ago, dmsc said: ".exportzp" means "export as an 8 bit". That's a bit of an stretch/abuse as it means it's a zero page address, which just happens to need 8 bits. Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 15, 2021 Author Share Posted March 15, 2021 Hi! 31 minutes ago, Wrathchild said: That's a bit of an stretch/abuse as it means it's a zero page address, which just happens to need 8 bits. Yes ? But, LD65 only support address for relocation, not arbitrary numbers, so the only way to export an 8-bit symbol from CA65 that I know of is using exportzp. From the manual https://cc65.github.io/doc/ca65.html#ss8.1: Quote ca65 assigns each segment and each symbol an address size. This is true, even if the symbol is not used as an address. You may also think of a value range of the symbol instead of an address size. Possible address sizes are: Zeropage or direct (8 bits) Absolute (16 bits) Far (24 bits) Long (32 bits) Have Fun! Quote Link to comment Share on other sites More sharing options...
danwinslow Posted March 15, 2021 Share Posted March 15, 2021 (edited) this is the good part of CA65's complexity Edited March 15, 2021 by danwinslow Quote Link to comment Share on other sites More sharing options...
janzh Posted April 20, 2021 Share Posted April 20, 2021 This is really a great BASIC Compiler. It is fast and slim. I love it for fast prototyping. THANX A LOT! GREAT WORK! One wish: Could I get a FBC with SpartaDOS command line support, e.g. FBC source.BAS executable.COM ? Quote Link to comment Share on other sites More sharing options...
777ismyname Posted May 1, 2021 Share Posted May 1, 2021 On 3/14/2021 at 8:19 PM, dmsc said: Hi! Thanks (again) for the offer. I don't have specific needs for the manual, normally is other people that notices the omissions. For example, @vitoco noted that the INC and DEC statements does not mention that they do work on word arrays but not in byte of floating point arrays. I will add a note to both. Problem is, the manual will keep growing and probably become harder to read, specially for a novice. There is a line between writing a "specification document" or a "beginners guide", and I think that the manual should be both approachable without being too technical. Perhaps it is better to write two manuals, one more like a guide and other with the full description of the statements - but having too much documentation also is not good, as people will not read it and won't find what they need. Any toughs? Have Fun! Hmm, I will play about with a few ideas and send them over pretty soon. Things have been a bit turbulent here, but have hopefully settled down for a while. I agree 100% on the points you raised. P.S: looking forward to seeing something about Fast Basic on the Compy CLC-88 one of these days over at the Catrin Labs website 1 Quote Link to comment Share on other sites More sharing options...
dmsc Posted May 1, 2021 Author Share Posted May 1, 2021 (edited) Hi! Quote This is really a great BASIC Compiler. It is fast and slim. I love it for fast prototyping. THANX A LOT! GREAT WORK! Thank you for your comments!! Quote One wish: Could I get a FBC with SpartaDOS command line support, e.g. FBC source.BAS executable.COM ? To not miss this, I added a bug report on github: https://github.com/dmsc/fastbasic/issues/46 Have Fun! Edited May 1, 2021 by dmsc Quote Link to comment Share on other sites More sharing options...
nebpehtira Posted August 13, 2021 Share Posted August 13, 2021 This is an incredible project, DS! Real labour of love. Looking forward to playing with FastBasic as I've been getting really frustrated with line numbers in Atari Basic. Wondering if you have a PDF version of the manual available? Call me old fashioned but I like having paper documentation on hand sometimes Quote Link to comment Share on other sites More sharing options...
dmsc Posted August 13, 2021 Author Share Posted August 13, 2021 Hi! 15 minutes ago, nebpehtira said: This is an incredible project, DS! Real labour of love. Looking forward to playing with FastBasic as I've been getting really frustrated with line numbers in Atari Basic. Wondering if you have a PDF version of the manual available? Call me old fashioned but I like having paper documentation on hand sometimes Thank you, hope you do some great programs with FastBasic You can download the PDF manual at: https://github.com/dmsc/fastbasic/releases/ Have Fun! 1 Quote Link to comment Share on other sites More sharing options...
nebpehtira Posted August 15, 2021 Share Posted August 15, 2021 Feel silly on this one as it's so simple, but can't see the error! Just a basic selection IF/ELIF/ELSE structure for a user menu... getting a BAD LOOP error when parse/run? Initially left out THEN as assumed wasn't needed but got the bad loop error so thought maybe they are but still no joy. PRINT "Select option..." INPUT option IF option = 1 THEN EXEC trimix ELIF option = 2 THEN EXEC mod ELIF option = 3 THEN EXEC end ELIF option = 4 THEN EXEC min_od ELIF option = 5 THEN EXEC part_fill ELIF option = 6 THEN EXEC ccr_blend ELIF option = 7 THEN EXEC density ELIF option = 8 THEN EXEC shutdown ELSE EXEC init ENDIF ENDPROC 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.