dmsc / fastbasic Goto Github PK

Thank you for developing this great IDE! Your totally modern and alternative approach to BASIC really reinvents the whole idea of high-level programming for 8-bit. It doesn't have so much optimized commands as Turbo BASIC but anyway, the numberless coding for 8-bit is a fantastic improvement. I keep my eye close on this project and would like to express my big respect!

I've tried to make a complete application with it and find several things, which I miss during development.

1. Line delete and instant jump to a given line number. I really miss line copy and paste but the first two could be even more helpful because it takes the time to navigate between a far proc and a header section.
2. A documented memory location which can be tested from the working code to tell whether it's executed under IDE or as a stand-alone program. This could help placing program break conditions in the code without removing it each time before compilation.
3. Bitwise shift commands. This command is native to the processor and could improve execution time of frequently used power of 2 divisions and multiplications use3d in processing of graphics.
4. LOCATE command or equivalent function. It can be emulated via proc (which I've done along with area fill but it runs too slow.
5. Of course I also miss lot of familiar commands both from standard and Turbo basic and hope that sometimes the most popular of those will be implemented but I understand that it will make the IDE occupy more memory, so I'm not asking to implement everything.

And by the way, is there any chance that some time in the future you will implement stack-operated function calls? Currently I've found a way for processing recursive code, using global temporary variables for data interchange between procedures and some array-emulated stack, but it's so complicated and so slow that becomes impractical. Meanwhile, since we are playing by rules of not using line numbers, labels and non-conditional jumps, implementing stack and functions could be super-helpful for keeping the code structured and readable. Sometimes I still miss labels and good old GOTO.
Thanks.

The following produces a compilation error using release 3.6 in Windows 10:

data test() WORD = 1,0,-1,0,1

results in
parse error, expected: data word
data test() WORD = 1,0,<--- HERE -->-1,0,1

I have to remove the negative value to successfully compile.

In GRAPHICS modes 1 and 2, text can be PRINTed in any of the 4 playfield colors, but the text must be prepared to use them (inverse video and/or lower case in literals). This seems to be always true, except when numeric variables are converted to text (implicit STR) to be displayed, because the ATASCII value of the digits are always in the range from $30 to $39 (playfield 0).

The request is to add a constant based on current COLOR just before printing each digit (PUT).

This way, scores, levels and lives could be printed in its own color without having to convert each digit on each item or being forced to assign playfield 0 for the scores.

If this change is at PUT level (not in STR function), it could also be available to change the whole text to the desired color:

GRAPHICS 1
FOR X=0 TO 3
    COLOR X
    PRINT #6,"THIS IS COLOR ";X
NEXT

With this enhancement, the previous example sould display 4 lines of text, each of its own color.

This feature must not be restricted for texted GRAPHICS modes 1 and 2, because the display list might be of mixed modes. The default COLOR mode should be 0 and that should do nothing to text.

$ make
cl65 -g -tatari -Ccompiler/fastbasic.cfg --asm-define FASTBASIC_FP --asm-include-dir gen/fp -c -l obj/fp/actions.lst -o obj/fp/actions.o src/actions.asm
cl65: Don't know what to do with `obj/fp/actions.lst'
make: *** [Makefile:212: obj/fp/actions.o] Error 1

I know this probably isn't a bug and is working within the parameters of signed integers, but it is a problem that shows the need for an option to use unsigned integers.

I was testing some scrolling and hit a problem, I've condensed it down to the code in the attached file.

This drops memtop to reserve memory for the scroll, it then sets up the DL and then loops through memory and displays a character moving diagonally.

As long as PAGE<=64 everything works fine but if I wanted a larger area for my scrolled screen then it hits an issue with signed integers. If I set PAGE=68 the loop will have the following value:

FOR A=32014 TO -16640

This causes program flow to drop through the loop without executing it.

In order to work with memory (and therefore my scrolling screen) am I forced to use floating point to avoid issues with the sign flipping?

An option to use unsigned integers would solve this. Being able to select signed or unsigned as your default would be great.
TEST.TXT

Evolving the idea of implementing the bitwise shift operators I could suggest a syntax for such shifting:
First of all, I think logical shift is a lot more used and more abstract and common operation that arithmetic shift right because the latter can be implemented through the first but not vice versa.

Possible notation can be like this:
LSR v,n 'v: value, n: number of bits
LSL v,n 'v:value, n: number of bits
So, it's variable-modifying logical shift right or left.

Also, if 6502 can't do logical shift to variable amount of bits, this can be shrinked to just ope-operand command like LSR v / LSL v

Another approach is the opposite, self-containing function like LSR(v,n) / LSL(v,n), returning the result of non-destructive logical shift. The functional approach is of course more universal because it could be used in expressions.

And the third approach is just copying C language: through binary operators << and >>. I suspect that operators in basic are actually macros for functions in a generalized form, so I believe there's shoudnt' be much difference between making it either way and the operator approach should be the most powerful, intuitive and readable.

I am getting "expected: data type" error between the () and BYTE. I am following what is stated in the documentation.

DATA GAME_OPTION_SHOW() BYTE = " PLAY FOR HIGH SCORE ",
BYTE = " WIPE OUT 25 LINES ",
BYTE = " NEW SCREEN FOR EVERY LEVEL ",
BYTE = " WIPEOUT MORE LINES FOR NEW LEVEL ",
BYTE = " WIPE OUT 50 LINES ",
BYTE = " WIPE OUT 100 LINES ",
BYTE = " PLAY FOR HIGH SCORE WITH HIGHT "

I am printing from different string arrays on a single screen. It is for different playing options for a game I am porting into Fast Basic. After I tried to get 5 or more different options, the strings started to get scrambled. Look like they come from a different memory location or the program crashes. I want to do a similar set up like I've done with cartridge games using select and option or joystick to change parameters before starting a game.
I am using PRINT "(label)"; OptionXX$(index). I had to drop what I was doing to head to work. Using two different print statements to see if that works.

Some akin to dlopen in C - https://pubs.opengroup.org/onlinepubs/009696799/functions/dlopen.html
would be great to have.

The advantage over a RUN "Dx:Filename.ext" is that you would not unload the initial program, keeping any vars you have set.
If someone were to write a core application that was small - but contained all of the static vars required; and called modules via a dlopen-like method, it could become quite extendible.

Example of usage (though pretty nitch): BBS where the system is modular and would not require a sort of TSR to be present.
Maybe an adventure game where you could add in modules for different games
A text interpreter that called in modules to handle things differently

If this already exists; or there is some other way to handle this; I'd love to see it.

I see a few commands were removed from Atari Basic. If code is being ported over, there should be a list of in unsupported commands and functions. I see GOTO, GOSUB, and ON (variable) (GOTO GOSUB EXEC) no longer supported. I know the. ON statement can be done with block if. (Or RTS assembly trick).

I am attempting to take a few of my old Atari Basic Games, port over to Fast Basic, and provide as open source samples for help others learn the language.

Adds a key combination for jumping to any given line in the IDE, probably "CONTROL-G"

can't compile because there is missing obj/fp/pause.com file

The command line compiler could be used from the command line, as "FBC FILE.BAS"

Reported by janzh at AtariAge: https://atariage.com/forums/topic/318133-fastbasic-45-2021-release/?do=findComment&comment=4806423

I was wondering if you could add a way of incrementing an integer by 256.

I suspect this would be just like inc only you'd increment the hi byte instead of the lo byte of the integer.

I am working on compiling a program and seeing if it is possible to make a program run from a 16k cartridge instead of RAM. I have started a CFG file. I am not sure if I am not missing anything.

FEATURES {
STARTADDRESS: default = $8000;
}
SYMBOLS {
EXEHDR: type = import;
STARTADDRESS: type = export, value = %S;
}
MEMORY {
ZP: file = "", define = yes, start = $0094, size = $0040;
ROM: file = "", define = yes, start = $8000, size = $2000, type = ro, fill = yes, fillval = $ff;
RAM: file = "", define = yes, start = $0400, size = STARTADDRESS - ROM, define = yes;
CARTSTART: file = %O, start = $BFEA, size = $0002;
CARTLEFT: file = %O, start = $BFFC, size = $0001;
CARTBOOT: file = %O, start = $BFFD, size = $0001; fill = yes, fillval = $59;
CARTENTRY: file = %O, start = $BFFE, size = $0002;
VECTORS: start = $BFFA, size = 6, type= ro, file = %O;
}
SEGMENTS {
ZEROPAGE: load = ZP, type = zp, optional = yes;
EXEHDR: load = HEADER, type = ro, optional = yes;
MAINHDR: load = MAINHDR, type = ro, optional = yes;
JUMPTAB: load = MAIN, type = ro, define = yes, align = $100;
RUNTIME: load = MAIN, type = rw, define = yes;
CODE: load = MAIN, type = rw, define = yes;
DATA: load = RAM, type = rw optional = yes, define = yes;
BSS: load = RAM, type = bss, optional = yes, define = yes;
HEAP: load = RAM, type = bss, optional = yes
IHEADER: load = IHEADER, type = ro;
INTERP: load = INTERP, type = rw;
AUTOSTRT: load = TRAILER, type = ro, optional = yes;
CARTSTART: load = CARTSTART, type = ro;
CARTLEFT: load = CARTLEFT, type = ro;
CARTBOOT: load = CARTBOOT, type = ro;
CARTENTRY: load = CARTENTRY, type = ro;
}

It would be great if I could point the location of an arrays data at a specific page in memory to make character sets.

eg.

DATA FONT(),40960 BYTE = 0,0,0,etc

This would save on doubling up on memory due to having an array and then needing to move that data to the character set location. And it's a lot easier than creating external data files and loading them directly into memory.

Control-S saves your file, using the last name. Control-R runs your file. How about a control-shift R that saves and runs your file, along with a control-shift W to save and compile?

This isn't really necessary in normal programs but could be helpful for 10 liners. No idea what it would take to do it :)

I often find myself wanting to check a range of numbers (eg. check if a screen character is an enemy or a wall etc.) . The code usualy goes something like:

IF PEEK(S)>10 AND PEEK(S)<15......

It would save a fair bit of space if I could do:

IF PEEK(S)=11 TO 14

Compressed the lines are:

IFP.(S)>10ANDP.(S)<15
IFP.(S)=11TO14

This would save 7 bytes (8 if you could use a sign instead of TO). My current 10 liner uses this 6 times so that could be a saving of 48 characters.

There's probably a very good reason why this isn't possible, but it would be great if it could be done.

This code don't compile in the cross-compiler:

proc x: ? "x" : endproc : exec x : proc y : ? "y" : endproc : exec y

The compiler generates repeated labels for the line:

Compiling 'mult.bas' to assembler 'mult.asm'.
Assembling 'mult.asm' to XEX file 'mult.xex'.
mult.asm(30): Error: Symbol '@FastBasic_LINE_2' is already defined
mult.asm(30): Error: Symbol '.size' is already defined

I found I needed to add the OPTFLAGS the setting -std=c++14 for a build under cygwin to work, although this is an older installation of gcc 5.3.0

Hey there.

It seems that cross-compiled FB doesn't allow disk I/O, doesn't see the D handler or the like.

When I cross-compile a basic open/write/close in FB, and load the resulting com file in any way under any DOS, I get error 130. Tried under DOS 2.5 and BWDos.

If I take the same lines and put it through FB, FBI, run direct OR compiled, the code runs fine, no errors.

In other words, file IO works like a charm using the Atari editor/compiler, but doesn't work at all for me using the cross compiler. (all those ? ERR() commands are just because I wanted to see what was breaking things).

Code:

open #1, 8, 0, "d1:test.txt"
? ERR()
? #1, "Hello world!"
? ERR()
close #1
? ERR()

Run direct on the system, error codes are all 1.
Compiled and run on system, again all 1.
Cross-compiled, I get error 130, 133, and 1.

Hit a problem while writing a 10 liner.

There is no RUN command and no CLR command, so resetting arrays becomes a problem unless you write a routine to do it yourself (which uses extra space that 10 liners don't have)

here's what I mean in a nutshell:

for i=1 to 99
dim x(999)
next i

After a few loops this crashes with a memory error. In Atari or Turbo Basic I would just add a CLR command or even start the program again with a RUN.

Of course, in a sensible program this wouldn't be an issue - but 10 line coding tends to be a bit wild and loose.

The data test() bytefile "xxx" doesn't seem to be working, I looked through the test suite. using summer release 4.4. When running it generates a parse error and cursor is on the F of BYTEFILE.

Thanks.

The cross compiler (but not the native one) produces invalid code for any DATA inside a PROC.

Example:

exec x

proc x
  data y() = 1,2
  ? y(0)
endproc

Think I got a bug.

inc a(1)

This works as expected with WORD arrays but gives an error with BYTE arrays

Does fast basic have anything similar to instr, instr$? could not figure out if it had this or now.

I have been trying to Google search this issue. I am trying to like a Fast Basic program to some assembly code using FB (programnam.bas) (assembly.asm) at command prompt. I keep getting this error "The system cannot find the path specified." Using Windows 10.

Add a way to write the VDSLST pointer with a new DLI address from within another DLI. (and from a VBI).

• Depends on #21 for correct restoring of original DLI.

Now that we have DLI, it would be fun to also have VBI support.

See discussion from here: https://atariage.com/forums/topic/302613-fastbasic-43-with-dli/?do=findComment&comment=4470227

Also, VBI should support calling external ASM code (i.e, to support sound players).

The editor works fine up to 464 lines but on entering 465th line things start breaking down.

It starts entering empty space lines above the visible screen, so when you scroll up past what's visible on the screen there's blank space. The more line over 464 the more blank lines they are.

When you scroll up past the blank space you eventually start to see your code but the line numbers eventually start to go into the negative.

The code still seems to run ok, but the editor is more blank line than anything else if you have a big program.

I defined two DLIs in order to change between them as needed. It worked great and I got the effect I wanted.

My program crashed Altirra once, and I didn't do the forensics at the time because I thought it was related to the latest change, but after some days and many, many runs, it crached again, and this time I started Altirra's debugger, finding that the PC was stopped at a KIL instruction ($02).

The address was $9E5C, and that was in the middle of the bytecodes. I loaded the symbols and found that the bytecodes was close to one of the DLIs I defined, which it was located a $9E9F. The other DLI was located at $9F5C.

Then, it seems that a DLI was activated just in the middle of the DLI swap, where only one of the address bytes was updtated, pointing to an invalid address.

I'm not sure, but I think that a solution without the plain DLI command to deactivate the interrupt (and get a glich) or without preceding the activation of the next routine with a PAUSE 0 to get in sync with the vertical blank, it could be to emit the bytes for the pause within the (re)activation of a given DLI.

I mean, in the syntax file, instead of:

    # Activate DLI with given name
    emit { TOK_NUM, &VDSLST, TOK_SADDR, TOK_NUM, VT_ARRAY_BYTE } E_LABEL \
          emit { TOK_DPOKE, TOK_BYTE, 192, TOK_NUM_POKE, &NMIEN }

use:

    # Activate DLI with given name
    emit { TOK_0, TOK_PAUSE, TOK_NUM, &VDSLST, TOK_SADDR, TOK_NUM, VT_ARRAY_BYTE } E_LABEL \
          emit { TOK_DPOKE, TOK_BYTE, 192, TOK_NUM_POKE, &NMIEN }

(TOK_0 and TOK_PAUSE were added after the first emit).

The IDE needs a way to copy or move blocks of text to facilitate editing.

The joystick is the pointing device by excellence for Atari, could be great is there is some way in that the joystick could used to navigate across the sources in the editor.

It will allow to review the sources with jsA8E emulator that not have support for keyboard arrows: https://eahumada.github.io/AtariOnline/fastbasic.html?disk_filename=fastbasic.atr

I'm having a problem with FB and FBC crashing, although my program works fine when I use the cross compiler. So I'd like to rule out something before looking into it further.

Is page6 free for the user? I'm using it for a short assembler script but if FastBasic uses it then this could be the problem.

Also, how much memory does FastBasic leave for the user? I've ran ?fre() and I get:

Using FB = 29983
Using FBI = 31263
Using FBC = -28897
Using cross compiler = 31263

Is there really less than 31k for code/data? I thought they'd be more. Although the signed interger is clearly confusing me after compiling with FBC.

There are many commands that could be seen as the end of a line and yet we still need to use a colon to denote a new line/command.
eg.

endif (e.)
else (el.)
wend (we.)
next (n.)
etc

Would it be possible for the parser to do this 'auto new line'? and remove the need for many of the colons in 10 liners (I have over 200 colons in my current programme)

I tried creating a disk using mydos 3.01 and dos 2.5, then accessing it trying to save or load such as d2:.. from fb 4.4 i get error 140. What is wrong?

The manual states "POSITION row, column" but the behavior is col., row.

Apologies if I haven't read the manual properly :)

Does FB have multi-dimension arrays? I tried dim a(9,9) and it threw up an error. I checked manual and it says nothing about it that I can see.

The key() function returns the last key press but how do you reset it? How do you know if a key has been pressed once or multiple times?

Would it be possible to add an optional 4th parameter to MSET in order to to set every other byte or every 3rd byte etc.?

eg.
MSET address, length, value[,step]

Why do I want this? In order to scroll I need to change every 3rd value in the DL with something like this:

pause 0
for i=DLscroll to DLscroll+51 step 3
poke i,y
next

This is pretty slow and I actualy unroll the loop to get a bit of extra speed. If I could do this with the speed of MSET it would be way better, especially for 10 liners.

Cannot locate LOCATE :)

Since fastbasic is similar to TURBO BASIC XL, and TURBO BASIC XL is similar to GFA-BASIC, and GFA-BASIC is similar to X11-Basic, you might want to try out some of the sample programs from the collection: https://codeberg.org/kollo/X11-Basic_examples

I think at least some of them can be also ised with FASTBASIC to check its performance. Also there is a small tool which can remove the line numbers from ANSI BASIC programs and thus help adapt alien dialects.

e.g. this one can probably run without modifications:

https://codeberg.org/kollo/X11-Basic_examples/src/branch/master/All/console/maze.bas

Just to let you know. Have fun!

This is good or debugging programs, should work only on running programs from the IDE and not slow down the code.

Allow the assignment of a constant or array to more than one memory address/register, just like it does with WSYNC.

For example, to move two overlapped players to build a multicolor sprite using a single horizontal position array, instead of:
DLI SET mydli = xpos INTO $D002, xpos INTO $D003
it could be great to use:
DLI SET mydli = xpos INTO $D002 INTO $D003

This would save machine cycles during the interrupt by loading the value once, allowing to write longer DLIs without glitches.

In combination with WSYNC, the syntax could be something like this:
DLI SET mydli = xpos WSYNC INTO $D002 WSYNC WSYNC INTO $D003

Hi

You can add the command: CONST?

Add a way to generate a "STA WSYNC" to a DLI.

In the cross-compiler, it could be useful to allow DATA statements without an actual definition, this will allow accessing external DATA as arrays or including binary files.

Example syntax:

DATA Image() byte asm
GR.8
MOVE ADR(Image), DPEEK(88), 40*192
GET K

And, in an assembly file:

  .export fb_IMAGE
  .data
fb_IMAGE:
  .incbin "myimage.raw"

Any chance we could use inc/dec directly on memory

eg INC &1536 instead of poke 1536,peek(1536)+1

Any chance of an abbreviation for PEEK?

I use peek a lot, especially in my 10 liners, so even a single characters saved would be useful.

PE.
PK.
or even the less intuitive K. for a 2 character saving.

I am having a problem where any error, in even the smallest of test programs, crashes the FB compiler. This is using the prebuilt 4.5.2 binary for Mac, on an Intel Mac running 10.14 (Catalina) and also on an arm (m1) mac running 10.15 (Big Sur).

Pretty much any error in the code will trigger the crash in both the int and fp compilers, for example:

Graphics 5
z=5 boop

On Mac, I get the following output:

% fastbasic-int test.bas test.asm
Abort trap: 6

I don't experience this problem on a Windows 10 machine . On Windows I get the expected error:

test.bas:2:5: parse error, expected: '&', '!', 'EXOR', '*', '/', 'MOD', '+', '-', 'OR', 'AND', integer comparison operator
z=5 <--- HERE -->z

Am I doing something dumb? (Probably yes). I suspect this has more to do with permissions lockdown on Mac than on the fastbasic code. Sigh.

If there is anything I can do to help troubleshoot, debug, solve the problem, please let me know!

Debug output from fastbasic-int -d attached, in case that is any help!

Cheers

..b

error.log