59 replies to this topic

[dmsc]

Hi all!

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?
 
EDIT
 
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.

Attached Files

•  fastbasic-20170710.atr   90.02KB   16 downloads
•  editor.bas   13.49KB   14 downloads

[dmsc]

Hi!

There is now a new FastBasic version!

- Adds a standalone interpreter, and a (cross-)compiler.
- There are optimizations passes in the native compiler (mainly some constant propagation and other simple replacements).
- Adds tokens for numeric constants "0" and "1", makes code smaller.
- More size optimizations in the interpreter, code is smaller and faster.

To use the cross compiler, you should download the sources, (either from github at https://github.com/dmsc/fastbasicor attached in this post) and install the CC65 suite from http://cc65.github.i...ng-started.html

Then, you can compile the FastBasic executable with "make bin/fastbasic", and compile your sources with two steps, first compile BAS to ASM and then use CL65 to compile from ASM to XEX:

bin/fastbasic MY_PROGRAM.bas MYPROGRAM.asm
cl65 -tatari -Csrc/fastbasic.cfg src/runtime.asm src/interpreter.asm src/io.asm src/alloc.asm src/standalone.asm src/exehdr.asm MY_PROGRAM.asm -o MY_PROGRAM.xex

All the other files are not needed if you only want the command line cross-compiler.

Note that the cross-compiler uses the same parsing state machine as the Atari compiler, but has two differences:
- The optimizer, that can produce smaller code,
- You can use "@NAME" as 16bit assembly constants and "@@NAME" as 8bit assembly constants. Those constants are passed to the generated ASM file, so must be available in the final assembly as .global / .globalzp symbols.

Well, attached is the ATR (now with the sample programs also compiled, try executing "CARRERA3", "DRAW", etc. The IDE is smaller now, at 8901 bytes, now a minimal "?FRE()" program reports 29424 bytes free, only about 2k less than Atari Basic with DOS.

Attached Files

•  fastbasic-20170713.atr   90.02KB   17 downloads
•  fastbasic-src-20170713.zip   151.54KB   16 downloads

[ivop]

I needed to add -std=c++1y to compile properly. Otherwise, excellent work!

[flashjazzcat]

Looks great! You might want to observe the right margin setting at RMARGN ($53) after opening the editor device: this will read $4F if an 80 column display is enabled with the SDX S_VBXE/CON.SYS drivers:

Attached Thumbnails

• 

[vitoco]

Secretly, my goal is to have a platform to write better ten-liners

 

Well, tenliners requires the shortest way to write many instructions to maximize the 1200 bytes for PUR-120 category. You said that the program editor is free-form, and I haven't seen the sources yet, so I don't know if the parser allows abbreviations and line numbers to comply with the tenliners rules.

 

Could the runtime be splitted in 2 portions like in TurboBASIC XL? Low RAM and under-OS high RAM? That could give about 4 o 6 extra KB of memory to the user program.

[pirx]

I don't know if the parser allows abbreviations and line numbers to comply with the tenliners rules.

Yea, abbreviations work nicely and generally you can write the compact style. Interesting plus of this kind of the editor is that the source does not get expanded, so you can work on the compact version.

[Philsan]

Now I only need Irgendwer's Turban for FastBasic.

[dmsc]

Hi!
 

Looks great! You might want to observe the right margin setting at RMARGN ($53) after opening the editor device: this will read $4F if an 80 column display is enabled with the SDX S_VBXE/CON.SYS drivers:

Yes, with minor changes to editor.bas it is now 80 column aware

I also now use a loop to print blanks (instead of a fixed string), so it's smaller at 8864 bytes.
 
 

Well, tenliners requires the shortest way to write many instructions to maximize the 1200 bytes for PUR-120 category. You said that the program editor is free-form, and I haven't seen the sources yet, so I don't know if the parser allows abbreviations and line numbers to comply with the tenliners rules.
 
Could the runtime be splitted in 2 portions like in TurboBASIC XL? Low RAM and under-OS high RAM? That could give about 4 o 6 extra KB of memory to the user program.

As pirx said, abbreviations are supported similar to turbo-basic, see in "basic.syn" file, lowercase characters in commands are "optional". Also, spaces are generally not required.

As a ram-under-rom version, it is possible, but will complicate the code a lot, I think.

Attached new version.

Attached Files

•  fastbasic-20170714.atr   90.02KB   19 downloads

[dmsc]

Hi!,
 

Well, tenliners requires the shortest way to write many instructions to maximize the 1200 bytes for PUR-120 category. You said that the program editor is free-form, and I haven't seen the sources yet, so I don't know if the parser allows abbreviations and line numbers to comply with the tenliners rules.
 
Could the runtime be splitted in 2 portions like in TurboBASIC XL? Low RAM and under-OS high RAM? That could give about 4 o 6 extra KB of memory to the user program.

As an example, this is the FastBasic version of my tenliner "carrera3d", sadly still does not work in the IDE (not enough memory), but works with the command line version.




Note that to compile you need the last FastBasic version (from github). That version is now only 8684 bytes, I'm approaching my 8kb target!

Attached Files

•  CARRERA.BAS   1.15KB   5 downloads

[flashjazzcat]

Yes, with minor changes to editor.bas it is now 80 column aware

I also now use a loop to print blanks (instead of a fixed string), so it's smaller at 8864 bytes.

Excellent! This works well using the SVBXE/CON drivers. Scrolling is rather slow, however. I wonder if it would be possible to inject line insert/delete characters at the top of the screen to speed this up somewhat? When scrolling one line back through the document, for example, insert a single line at the top of the window, causing all subsequent lines to move down using whatever efficient block move method is employed by the display driver. You'd then draw the new line at the top of the window in place of the blank one. The VBXE driver uses the blitter for scrolling, so this would be pretty fast (and scrolling would be quicker when using the OS screen handler too). Even if you wanted to scroll by multiples of lines, this technique could offer some improvement. Just a thought, anyway!