FastBasic - Summer Release

[dmsc]

Hi all!

 

A new release of FastBasic is available, this is Release 3.

 

This release has with many enhancements, mayor ones:

- Added string comparison operators,

- Interpreter is about 3% faster in FOR loops and other simple operations. SIEVE benchmark now takes 17 seconds.

- The integer-only IDE is now less than 8KB, the floating point IDE is 9.2kB, and there are 200 bytes more available for the programs.

- Cross compiler produces smaller executables by only including used parts of the runtime, a simple '? "Hello"' compiles to 453 bytes, including the interpreter and runtime.

 

Minor improvements to the IDE and language:

- The IDE now can edit files with lines of up to 255 bytes.

- The IDE is a little faster to parse large files.

- More abbreviations to the statements, The list of abbreviations is in the manual.

 

Mayor improvements to the cross-compiler and optimizer:

- New scripts for the cross-compilers allows passing options to the compiler and linker, also writes label files for debugging.

- Cross compiler gives better errors in many cases.

- Optimizer for NEG/MUL/DIV/MOD and all bitwise operations.

- Optimizer ignores comments and can span multiple lines.

- Adds tail-call optimizations (replaces CALL/RET with JUMP and JUMP to RET with RET)

 

And many fixes:

- Optimizer no longer ignores negative numbers,

- Correct corner cases with MOVE / -MOVE, updates docs.

- Cleanup all variables and arrays on run, fixes on memory-clearing function.

- Fixes some cases of integer to floating point comparisons.

- Fixes parsing of NOT with parenthesis and NOT/NOT.

- Fixes errors on line numbers > 255 in the IDE.

- Fixes some corner cases in the IDE editor with lines at top/bottom of screen.

- Parsing of statements after a ':' ignored errors.

 

As always, full sources and binaries for Atari, Linux, Windows and MacOS are available over Github: https://github.com/dmsc/fastbasic/releases

 

Have fun!

 

Edit: current version is v4, announcement at https://atariage.com/forums/topic/288617-fastbasic-40-tenliners19-release/

Edited February 25, 2019 by dmsc

[pirx]

niiiice!

 

Just a question - is it possible to call an asm routine like a proc? You know, not via USR(@XXXX)?

[flashjazzcat]

This makes me wish I was still programming in BASIC. Immediate observation, though: if you press CTRL+N for a new file by accident, there's no way to back out (via ESC or similar) at the "Save?" prompt without losing everything in the buffer. Also, if you do take the opportunity to provide a filename for the save operation and the save fails (mistyped drive number, disk full, etc), the buffer is still cleared following the IO error.

Edited February 19, 2018 by flashjazzcat

[dmsc]

Hi!

 

niiiice! Just a question - is it possible to call an asm routine like a proc? You know, not via USR(@XXXX)?

 

Not currently without modifying the parser, but you can call any routine with USR() with no special preparations. USR() does three things:

- pushes the return address to the stack, so that the interpreter is called on return,

- pushes each argument to the stack, if any,

- calls the supplied address.

 

The difference with Atari BASIC USR() is that there is no "number of arguments" pushed to the stack, so you don't need to start your assembly routine with "PLA".

 

I could modifying the parser to add a "call" token, like "CALL $1234", or "CALL @MyASM" that would do the same as "X=USR($1234)", but I don't think it would add much to the language.

 

This makes me wish I was still programming in BASIC. Immediate observation, though: if you press CTRL+N for a new file by accident, there's no way to back out (via ESC or similar) at the "Save?" prompt without losing everything in the buffer. Also, if you do take the opportunity to provide a filename for the save operation and the save fails (mistyped drive number, disk full, etc), the buffer is still cleared following the IO error.

Yes, I'm not very good with user interfaces

 

I wanted to keep "ESC" to signal "don't save, just throw the buffer", but you are right that it's a little easy to lose your work by mistake... perhaps "CONTROL-N" again for don't save?

[flashjazzcat]

Yes, I'm not very good with user interfaces

I think you're striking a pretty good balance between economy and usability, though.

 

I wanted to keep "ESC" to signal "don't save, just throw the buffer", but you are right that it's a little easy to lose your work by mistake... perhaps "CONTROL-N" again for don't save?

These kinds of compound confirmations (do you want to save and do you want to throw the buffer) are a little tricky to manage with lightweight UIs. "ESC" is a very logical "cancel" signal, but in this case it's ambiguous whether one wants to cancel the save or cancel the New File operation. You could get around this by checking for unsaved changes to the buffer contents (just keep a flag which is cleared after a successful save and set every time an edit occurs), and if there are unsaved changes, throw up a prompt "New File: Save changes (Y/N)?" or similar instead of immediately presenting the user with a filename prompt. An affirmative response would bring up the file save dialog, while negative would skip saving and clear the buffer. An "Esc" response here could back out of the whole operation and just return you to the editor with the contents unchanged. You could even append "/C" to the "Y/N" prompt to denote cancel (so "C" and "Esc" would both be understood as "Cancel"). I see from the source code that no check is made for an IO error, so perhaps if the save operation failed, one could also be returned to the editor with the contents intact.

 

Speaking of buffer edits: I tried some of the example programs (lots of fun and very impressive) and I was asked if I wanted to save the file before loading another even though no edits had been made. The aforementioned buffer edits flag could avoid this (since the only way to clear the edit flag after making changes to the buffer is a successful save operation or deliberately abandoning the buffer to create a new file without saving).

 

That's just my suggestion, anyway. FastBasic is so good as it is that some small refinements to the UI would be absolutely worthwhile.

Edited February 19, 2018 by flashjazzcat

[dmsc]

Hi!

 

I think you're striking a pretty good balance between economy and usability, though.

 

 

These kinds of compound confirmations (do you want to save and do you want to throw the buffer) are a little tricky to manage with lightweight UIs. "ESC" is a very logical "cancel" signal, but in this case it's ambiguous whether one wants to cancel the save or cancel the New File operation. You could get around this by checking for unsaved changes to the buffer contents (just keep a flag which is cleared after a successful save and set every time an edit occurs), and if there are unsaved changes, throw up a prompt "New File: Save changes (Y/N)?" or similar instead of immediately presenting the user with a filename prompt. An affirmative response would bring up the file save dialog, while negative would skip saving and clear the buffer. An "Esc" response here could back out of the whole operation and just return you to the editor with the contents unchanged. You could even append "/C" to the "Y/N" prompt to denote cancel (so "C" and "Esc" would both be understood as "Cancel"). I see from the source code that no check is made for an IO error, so perhaps if the save operation failed, one could also be returned to the editor with the contents intact.

 

Speaking of buffer edits: I tried some of the example programs (lots of fun and very impressive) and I was asked if I wanted to save the file before loading another even though no edits had been made. The aforementioned buffer edits flag could avoid this (since the only way to clear the edit flag after making changes to the buffer is a successful save operation or deliberately abandoning the buffer to create a new file without saving).

 

That's just my suggestion, anyway. FastBasic is so good as it is that some small refinements to the UI would be absolutely worthwhile.

I made the changes, now ESC cancels the NEW, LOAD or QUIT command, and CONTROL-C gives the old behavior of discarding current file. Also, on save error, the prompt is repeated to try again. But I had to add more optimizations to the code to keep the integer IDE under 8KB, currently it is at 8182 bytes .

 

The new release is 3.1, available on github, with mostly bugfixes and optimizations:

 

-Fixes in the IDE compiler:

-- Fixes parsing of long lines with many ":".

 

-Changes in the cross-compiler:

-- Accept ATASCII end of lines in the cross-compiler.

-- Adds a new optimization pass to remove redundant I/O channel settings, producing shorter code for PRINT.

 

-Fixes in the IDE:

-- Prompt to save file only if there are unsaved changes.

-- Allow to cancel New / Quit / Load commands with "ESC", to cancel only the saving of current file, use CONTROL-C.

 

Have fun!

[+David_P]

You have 10 bytes to spare in the IDE... slacker.

 

[flashjazzcat]

The new release is 3.1, available on github, with mostly bugfixes and optimizations:

Excellent news. I will try it out as soon as I'm able.

[+Philsan]

Thank you Daniel!

 

When I type FB PROGRAMNAME.BAS I get this message: "".bas"==".asm" non atteso." (I think Italian "non atteso" means "not expected").

[dmsc]

Hi!

 

Thank you Daniel!

 

When I type FB PROGRAMNAME.BAS I get this message: "".bas"==".asm" non atteso." (I think Italian "non atteso" means "not expected").

Sorry, I messed up the last release, didn't properly test the windows cross compiler.

 

There is now a new release 3.2 with this fixed, download from https://github.com/dmsc/fastbasic/releases

 

Note that new cross-compiler is more capable than before, you can mix BAS files with ASM files and compile them together to one XEX.

 

For example, type in a file "prog.bas":

 ? "Starting..."
 a = 10
 b = usr(@MyProc, a)
 ? b

Now, in a file "myproc.asm" type:

 .global MYPROC
 .proc MYPROC
   pla
   tay
   pla
   tax
   tya
   rts
  .endproc

You can compile both with the command "fb prog.bas myproc.asm", you get a compiled "prog.xex" and a label file "prog.lbl" (useful for debugging in Altirra).

 

 

Have fun!

[Wrathchild]

Just wondering about the choice to diverge the call/return mechanism of existing the Basic USR call?

 

1) The top byte on the stack would tell the ASM routine how many parameters were passed, this is missing.

2) The routine would store the 16-bit integer return value in FR0 ($D4.w)

 

By missing the parameter count and adopting the A,X return means that existing Basic examples can't be used 'as-is', e.g. here, and have to be adapted to the new conventions.

 

As a good many Basic programmers might not want to dabble with the Assembler, I feel that penalises them and should be left compatible.

 

Additionally, my local CC65 is an older V2.13.2 and I work on Windows.
When doing CC65 (CA65/LD65) work, I run a batch file up front which has:

 

set PATH=C:\cc65\bin;%PATH%
set CC65_INC=C:\cc65\include
set CC65_LIB=C:\cc65\lib

 

As binary releases typically don't include the asminc folder, I got the error "proc.asm( 8 ): Error: Cannot open include file `atari.inc': No such file or directory"
To get around that, I copied the 4 needed files (atari.inc, atari_antic.inc, atari_gtia.inc and atari_pokey.inc) to the FastBasic folder and when I run fb-int.bat from there, the cl65 command got past the include error.

When I placed these includes into a sub-folder (asminc) and then modified the batch file to add to the CL65 command "--asm-include-dir %fbpath%asminc" then the error returned. (-Wa "-I fbpath%asminc" didn't work either)

Therefore I found I could get around that by setting the environment variable CA65_INC to point to the folder.

 

However, the next error was "ld65.exe: Error: Wrong data version in `D:\Emulators\a800win\FB\fastbasic-int.lib'"
Of course this is down to the mismatch of the pre-built lib in your distro compared with my local CC65 install but I can rebuild that from the FB sources.

 

Therefore my suggestion would be to update the documentation to state which (minimal) version of CC65 should be used.

Edited February 23, 2018 by Wrathchild

[dmsc]

Hi!

 

Just wondering about the choice to diverge the call/return mechanism of existing the Basic USR call?

 

1) The top byte on the stack would tell the ASM routine how many parameters were passed, this is missing.

2) The routine would store the 16-bit integer return value in FR0 ($D4.w)

 

Yes, I changed the USR interface im FastBasic because it is difficult to count the number of arguments in the interpreter - the interpreter simply pushes the arguments in the stack without counting them.

 

And, FastBasic does not use the FR0 variables for the integer interpreter, it is used for the floating point stack, so using them for USR would mean saving the values and restoring afterwards, making the code more complicated and slow.

 

 

 

By missing the parameter count and adopting the A,X return means that existing Basic examples can't be used 'as-is', e.g. here, and have to be adapted to the new conventions.

 

As a good many Basic programmers might not want to dabble with the Assembler, I feel that penalises them and should be left compatible.

 

Additionally, my local CC65 is an older V2.13.2 and I work on Windows.

When doing CC65 (CA65/LD65) work, I run a batch file up front which has:

 

 

Sorry, that cc65 version is ancient, from March 2010, so I can't support it (as you discovered), many things have changed (3000 commits from that version to current!), and many bugs have been fixed.

 

The cross compiler manual USAGE.md (included in the ZIP file) states that you need 2.16 or newer, and the main README states that to compile FasBasic you need "the version from cc65.github.io". I could change the wording to make it more prominent, pull-requests accepted!

 

Note that newer CC65 are easier to install, as don't need the CC65 environment variables and search the include directories automatically, you can download the newer version and install it besides your current one without problem.

 

Thanks for trying FastBasic, have fun!

[Wrathchild]

Classic case of RTFM, I'd not spotted that in the FB release and dived right in but then only looked at the README.md on githib, apologies.

Indeed I should update my CC65, for most of my work over the last few years, e.g. ports to 5200 cartridge, I've managed to get by with using MADS.

[+Philsan]

There is now a new release 3.2 with this fixed, download from https://github.com/dmsc/fastbasic/releases

 

New batch files now work!

 

I have a question: what are the differences between new and old batch files?

Edited February 23, 2018 by Philsan

[dmsc]

Hi!

 

New batch files now work!

 

I have a question: what are the differences between new and old batch files?

Old batch file was really limited, only called the compiler and linker. New one:

- allows to pass options to the compiler: "-h" for help, "-n" for disabling optimizations, "-d" for debugging the parser, "-v" for version.

- works installed on any folder,

- generates the ".lbl" file with labels,

- allows to pass assembly files to be linked with the basic program.

[+Philsan]

Thank you.

 

Could you please update this code I put starting at line 46?

It makes an ATR with xex file and all files found in atr folder.

echo Making ATR.
set imagename=%~d1%~p1%~n1.atr
set diskdir=%~dp1\atr
copy %xexfile% %diskdir%
dir2atr -b Dos25 720 %imagename% "%diskdir%"
if %errorlevel% neq 0 exit /b %errorlevel%
Altirra.exe /pal /bootrw %imagename%

[dmsc]

Hi!

 

Thank you.

 

Could you please update this code I put starting at line 46?

It makes an ATR with xex file and all files found in atr folder.

echo Making ATR.
set imagename=%~d1%~p1%~n1.atr
set diskdir=%~dp1\atr
copy %xexfile% %diskdir%
dir2atr -b Dos25 720 %imagename% "%diskdir%"
if %errorlevel% neq 0 exit /b %errorlevel%
Altirra.exe /pal /bootrw %imagename%

 

If you put the code just after the line that calls CC65, before the "EXIT /B", it could work, but perhaps it is easier to simply write the name of the ATR in full:

echo Making ATR.
set imagename=myimage.atr
set diskdir=C:\my\dir\atr
copy %xexfile% %diskdir%
dir2atr -b Dos25 720 %imagename% "%diskdir%"
if %errorlevel% neq 0 exit /b %errorlevel%
Altirra.exe /pal /bootrw %imagename%

I searched google as to how to set "imagename" from "xexfile", changing the XEX extension to ATR, but I'm not sure how it's done. Also, why do you need the ATR in the same command? I think it is a lot easier to do a new batch file that calls "fb.bat" and then builds the ATR, that way you don't need to modify the supplied one.

[popmilo]

A new release of FastBasic is available, this is Release 3.

 

Love it !

 

Didn't have time to examine it fully, could you say if it's enough for coding arcade games ?

[dmsc]

Hi!

 

Love it !

 

Didn't have time to examine it fully, could you say if it's enough for coding arcade games ?

Thanks!

 

I think that it has most of what is needed, if not, we just need to add it!

[popmilo]

Hi!

 

 

Thanks!

 

I think that it has most of what is needed, if not, we just need to add it!

Ok will give it a try

[dmsc]

Hi!

 

I published a new release 3.3, with a few bugfixes:

 

Enhancements to the language (requested by @vitoco):

- Fixes abbreviation of SOUND to "S.", and adds a "SOUND" with only one parameter to silence one sound voice.

- Adds STR$ function, with integer and floating-point arguments.

 

Fixes to the IDE:

- Detect byte-code parsing overflows on very big and complex lines, the parser shows the last correctly parsed position in the line on error.

- Turn off al sounds before returning to the editor.

- More simple optimizations to keep the size of the integer-IDE under 8k.

 

Fixes to the cross-compiler:

- Allows end-of-line characters inside strings, this fixes compilation of sources in ATASCII that have the $0A (CONTROL-J) character inside strings.

 

As always, full sources, ATR disk image and cross-compiler for Linux, Windows and macOS in the github page: https://github.com/dmsc/fastbasic/releases

 

Have fun!

[vitoco]

Love it !

 

Didn't have time to examine it fully, could you say if it's enough for coding arcade games ?

 

I just finished a tenliner for NOMAM using only the IDE in Altirra and a text editor in Windows. I'll write the docs and submit it in the following days. BTW, I had to put some PAUSE to slow it down and make it playable!!!

 

I've been testing FastBasic for some weeks converting my old tenliners, and found some bugs that dmsc solved quickly and I also requested some missing features that were added.

 

FastBasic IS nice, but the string management is limited. Currently there are no substrings or string slices, but MOVE is enough most of the time. You have to get used to some differences from TurboBasic XL, like the string structure with the first byte as the current length (max 255) so you have to skip it in ADR() function, and the comma instead of a semicolon after ?#6. A very different thing is the new DATA statement, which is used to initialize arrays, so there is no READ or RESTORE and you cannot use it as the old style of DATA to set up a game level.

 

But there are many wonderful enhancements, like ELIF in IF-ELIF-ELSE-ENDIF conditionals that allows you to specify a "case" structure, and SOUND with only 1 parameter to shut up only one voice.

 

FastBasic is a work in progress. Almost every week something has been optimized or a feature has been added.

 

Thanks dmsc!

Edited February 26, 2018 by vitoco

[Inky]

I took a look at the manual.. Kinda looks like Applesoft basic I remember from high school in many ways. I'll give this a try later tonight.

[Geister]

I'm looking at your FastBasic and I don't know if the problems I'm having are the fault of the emulator, the configuration of the emulator, or the BWDOS that you have on the disk.

 

I can load FastBasic and load basic code into the editor, but running anything causes memory errors, weird graphics artifacts, or the inability to load anything from a second disk.

 

First, is BWDOS compatible with other DOSes on the Atari. I'm not familiar with this DOS and it throws errors if I try to read from disks formatted in DOS 2.x. (this is with a DOS 2.0 disk mounted as D2: on Altirra.

 

Second, if I load and run the Pmdemo, the bottom half of the border appears purple and I'm not sure that the behavior of the sprite is as intended. It just bounces in a bow-tie path at the top of the screen.

 

Finally, if I load the Carrera3.bas program and run it, it ends with a memory error. (Is there a way to free more memory on Altirra?) How much memory does this program require?

Edited March 4, 2018 by Geister

[vitoco]

BWDOS is compatible with Sparta DOS. In my experience, I couldn't add a virtual folder as D2:, but H: host device worked. As FastBasic do not require BWDOS, you can extract any of the IDEs (FB.COM or FBI.COM), put it in a DOS 2.5 formated and initialized ATR and boot from there. I used the "Explore disk..." option in Altirra to extract FBI.COM (the integer-only version) from the ATR.

 

I haven't tried the included demos, but remember to boot without Atari BASIC cartridge/ROM to get all the RAM. Carrera3 uses almost all RAM to build the screen frames used by the game.

 

One more thing: There is no BREAK key check. That means that you cannot stop a running loop in your code and return to the IDE to make changes to the code. If you press RESET, you'll loose all unsaved source code. I had to include some key check in the inner loop of my game to perform an END statement and return to the IDE.