I was busy with work last week, just now have time to answer the thread.
vitoco, on 09 Jul 2017 - 4:57 PM, said:
I find very interesting that this version of BASIC has both the parser and the interpreter in the same module, As it has no editor, it just works like a compiler and a runtime... Hey, wait!!!! Why couldn't them be separated modules? A compiler/tokenizer and a linker/runtime. That could give extra RAM memory to the user program.
Seriously, I was impressed to see that the parser was written for the 6502 processor and not for a current platform like DMSC's TBXL-Parser.
Well, that was exactly the challenge, to be able to run in the atari as a standalone environment. Secretly, my goal is to have a platform to write better ten-liners
The parser is "based" on the TBXL-Parser project, rewritten to simplify the rules. I started modifying that code but realized that was too complicated for simply compiling the program, so I made the parsing rules generate the compiled code directly. Then, I replaced the ML generation with a simple stack-based code, this produced smaller code and allows larger programs.
pirx, on 05 Jul 2017 - 07:51 AM, said:
is saving parsed programs for quick execution possible?
would it be possible to make fb.com accept command line? would be much nicer than menu.
I plan to offer two versions, the "complete IDE version" and the "command line compiler", but I'm currently working in the IDE version as I find that more challenging. Modifying the github sources to accept command line options is nor that difficult, look at the "menu.asm" file.
Philsan, on 01 Jul 2017 - 02:46 AM, said:
Thank you very much for your PMG routine, now included in latest FastBasic version.
Which is the easiest way to write, edit and launch FB programs?
I read first post: "What is missing is an editor".
Well, not missing anymore.
Attached is my current working version, with integrated full-screen editor, written in FastBasic itself.
There are some limitations:
- The editor writes to the screen using the "E:" handler, so it's slow and big I tough that using E: would make the editor more "compatible" with screen upgrades, but I don't think it was worth the effort. Probably I will rewrite it using custom write routines.
- Now the IDE is a little less than 9kB, about 3kB bigger than the standalone parser.
- As the edited file is in memory at the same time that the parsed code, you have a lot less memory to your program. A minimal "? fre()" program reports 29kB free.
Sadly, the memory limitations makes my "CARRERA3.BAS" program incompatible with the IDE (the program needs 28kB free after load).
Attached is the ATR file and the editor sources.