fastbasic FastBasic 4.5 testing release

[snicklin]

8 hours ago, dmsc said:

My suggested syntax is:

' Imports fast-drawing code:
#IMPORT "draw.lib"
...

The assembly code should be like this:

	.export FB_FASTLINE

	' Use temporary variables from FastBasic interpreter:
	.importzp tmp1, tmp2, sptr
	' Access FastBasic Stack
	.import	stack_l, stack_h
...

 

Thanks so much for this. Perhaps there could be another sample file (or a separate manual) just for stuff like this?

 

With regards to what you were saying with respect to adding functionality that will allow you to use separate source files..... EXCELLENT! I was wondering about this. I am creating a test project in FB, just to learn FB and its capabilities. With the number of PROCs that I have, my code is getting long and needs splitting up. And yes, my variable names have clashed before. This functionality will be loved by many, I am sure.

 

Just a couple of questions regarding this...

1) If you have three files, Main.bas, IncludeProcs1.Bas and IncludeProcs2.Bas, will the Proc's in the first IncludeProcs1.bas file be able to use Procs from IncludeProcs2.bas ?

2) If there are Proc's that are unused by Main.bas, will they take up space in the final executable?

 

[snicklin]

Sorry for overloading this thread. I'm aware that I am doing it, but I got a lot of response before and my times (and limited coding hours) when in Australia are different to those in a lot of other countries.

 

I've tried to create a really stupid adding routine in Assembly to see if I can use it. Forget for now whether it actually adds up, it won't do that properly.

 

This is my Assembly which I compiled with: ca65 Dummy.asm

	.export FB_SPECIALADD

	.importzp tmp1, tmp2, sptr ;  Use temporary variables from FastBasic interpreter:
	.import	stack_l, stack_h ; Access FastBasic Stack

	.code
.proc FB_SPECIALADD
    sta     MULTB2 ; Parameter 2: Byte2
    ldx     stack_l, y ; Parameter 1: Byte1
    stx     MULTB1
    iny ; Remove parameters from stack
    sty sptr
    ; Call our machine code:
    LDA MULTB1
    ADC MULTB2 ; I know this code here will not add properly...
    STA tmp2
    LDA #0
    STA tmp1
    RTS
.endproc

MULTB1:
 .byte 0
MULTB2:
 .byte 0

Compile works fine. Then I try to interact with this from FastBasic and use this... 

.import "Dummy.o"

? "Hello there"
? "I am now going to add two numbers, 3 and 7"

X=USR(@FB_SPECIALADD,3,7)

This compiles with an error of:

Unresolved external 'FB_SPECIALADD' referenced in:
  C:\Users\Steve\Desktop\FastBasic4.5\Test.asm(36)

 

[+DjayBee]

From dmsc's example I guess that the FB_ is only used in the assembler code, but must be omitted when using it in Fastbasic. 

 

Try 

X=USR(@SPECIALADD,3,7)

[dmsc]

Hi!

 

So many posts, I will try to reply to all that were kept hanging  

23 hours ago, Wrathchild said:

An issue with live might be linking with libraries from different releases of the cc65 tools?

Different ways around that, maybe adopting a naming convention.

As I don't use the CC65 libraries, only the tools, this is not really a problem if the object file format does not change. Also, I currently distribute my own versions of the CA65, LD65 and AR65 tools: https://github.com/dmsc/fastbasic/tree/master/cc65  , this means that FastBasic can always benefit from the latest fixes.

 

23 hours ago, vitoco said:

My proposal was to use only FastBasic libraries in the form of PROCs. If the routine is assembly, it must be wrapped by a PROC with the proper USR call. This might add some overhead, but it's for simplicity.

Yes, that is already possible, and with separate compilation of different BAS files you could have your USR calls all in a separate file, this would be very convenient.

 

20 hours ago, danwinslow said:

So you meant FB source code in separate files like include files?

Yes, but not like include files - the problem with include files is that you need to parse the include file together with the main file. My idea is simpler, you can "link" many BAS files compiled together.

 

20 hours ago, danwinslow said:

They are? Has CC65 changed drastically lately? Not sure what I'm missing here, but I had to write my own relocation routines to load externally created .o files at runtime, even when created using CA65. You seem to be saying it will all be compiled/linked together, which of course will 'relocate' it. I was talking about a dynamic linking system, such as .dll or .so. At any rate, I'm out, because I don't understand what either of you guys are actually talking about. Love FB though.

No, I was writing here about cross-compiling a final executable, not loading the libraries on run-time. The output of the compiler is a "linked" executable, with all the relocation already done. For run-time loading, CC65 has a relocatable output format (O65), but IMHO that is far beyond the scope of a simple language like FastBasic  

 

Have Fun!

[dmsc]

Hi!

17 hours ago, snicklin said:

Oh this is great, you have something already in place! If that first 123 parameter was a word/integer, how would the FastBasic know that it was that and not a byte?

FastBasic always passes parameters as integers (16 bit values), so this is not a problem really. If you want to pass a string, a floating-point value or an array, you have to pass the address of it (with "ADR()" or "&").

 

17 hours ago, snicklin said:

I think you typo'd there, but it was a '1'. I was thinking that you might need to have a handle for each library. So that you could tell FB which library that you are referring to when trying to access "FastPlot" for example. I guess that with unique naming, this isn't an issue. But if people are sharing libraries online, in theory there could be one person who supplies a library that seems different to another library, but they both reimplement the same named command. For example, "FastLocate" might be in a text library, but could also be in a graphics library.

Ah, I find that too much complication ? 

 

I would recommend using a prefix for all the procedures of a "library", like "Text_FastLocate" and "Gr8_FastLocate", that way you don't have name clashes, and the compiler and language is simpler.

 

17 hours ago, snicklin said:

Great point, I did yes, but then again, the answer that was supplied was a great way of moving forwards now, rather than waiting for a new release. 

And currently, yo *can* distribute object files and libraries, you only need to alter the command line a little.

 

16 hours ago, snicklin said:

Thanks so much for this. Perhaps there could be another sample file (or a separate manual) just for stuff like this?

That would be an "FastBasic internals" manual. I prefer not to write something until *after* it is really used, as all the pitfalls can be ironed out. The elephant in the rooms is: FastBasic ns not used too much - there is only 17 downloads of the v4.5.2 ATR from github, so I don't think that people will start writing libraries for FastBasic yet. First, just try to get the user community bigger!

 

And, for functionality that really adds value to the language, that can be added directly to the main language.

 

16 hours ago, snicklin said:

With regards to what you were saying with respect to adding functionality that will allow you to use separate source files..... EXCELLENT! I was wondering about this. I am creating a test project in FB, just to learn FB and its capabilities. With the number of PROCs that I have, my code is getting long and needs splitting up. And yes, my variable names have clashed before. This functionality will be loved by many, I am sure.

I will work on this - but I don't promise any deadlines, as I have other projects that I want to do.

 

16 hours ago, snicklin said:

Just a couple of questions regarding this...

1) If you have three files, Main.bas, IncludeProcs1.Bas and IncludeProcs2.Bas, will the Proc's in the first IncludeProcs1.bas file be able to use Procs from IncludeProcs2.bas ?

Yes, there is no restriction to that.

16 hours ago, snicklin said:

2) If there are Proc's that are unused by Main.bas, will they take up space in the final executable?

You can try this already, and the answer is no, the cross-compiler removes unused proc's  (and DATA) from your program.

 

Have Fun!

 

[dmsc]

Hi!

14 hours ago, snicklin said:

Sorry for overloading this thread. I'm aware that I am doing it, but I got a lot of response before and my times (and limited coding hours) when in Australia are different to those in a lot of other countries.

 

I've tried to create a really stupid adding routine in Assembly to see if I can use it. Forget for now whether it actually adds up, it won't do that properly.

 

This is my Assembly which I compiled with: ca65 Dummy.asm

	.export FB_SPECIALADD

	.importzp tmp1, tmp2, sptr ;  Use temporary variables from FastBasic interpreter:
	.import	stack_l, stack_h ; Access FastBasic Stack

	.code
.proc FB_SPECIALADD
    sta     MULTB2 ; Parameter 2: Byte2
    ldx     stack_l, y ; Parameter 1: Byte1
    stx     MULTB1
    iny ; Remove parameters from stack
    sty sptr
    ; Call our machine code:
    LDA MULTB1
    ADC MULTB2 ; I know this code here will not add properly...
    STA tmp2
    LDA #0
    STA tmp1
    RTS
.endproc

MULTB1:
 .byte 0
MULTB2:
 .byte 0

Compile works fine. Then I try to interact with this from FastBasic and use this... 

.import "Dummy.o"

? "Hello there"
? "I am now going to add two numbers, 3 and 7"

X=USR(@FB_SPECIALADD,3,7)

This compiles with an error of:

Unresolved external 'FB_SPECIALADD' referenced in:
  C:\Users\Steve\Desktop\FastBasic4.5\Test.asm(36)

 

There are a few problems with this:

• You need to pass the "dummy.o" or the "dummy.asm" file to the command line compiler, the line ".import" that you added is simply a comment (comments starts with a "'" or a "."):

fb test.fb dummy.o

• As you are using "USR", the calling convention (the way parameters are passed) is *much* simpler, the parameters are already in the 6502 stack.

 

The correct code for dummy.asm would be:

	.export FB_SPECIALADD

	.code
.proc FB_SPECIALADD
    pla
    pla
    sta     MULTB2 ; Parameter 2: Byte2
    pla
    pla
    sta     MULTB1
    ; Call our machine code:
    LDA MULTB1
    ADC MULTB2 ; I know this code here will not add properly...
    LDX #0
    RTS
.endproc

MULTB1:
 .byte 0
MULTB2:
 .byte 0

This standard USR usage is explained in the compiler manual: https://github.com/dmsc/fastbasic/blob/master/compiler/USAGE.md

 

The "advanced" usage of the stack pointer would be for an "internal" FastBasic routine, that is not currently supported. See for example how internally FastBasic executes and ADD and a SUB: https://github.com/dmsc/fastbasic/blob/master/src/interp/addsub.asm

 

Have Fun!

 

 

 

[snicklin]

5 hours ago, dmsc said:

Hi!

 

So many posts, I will try to reply to all that were kept hanging  

I would just like to say a big "Thank you". I will leave you in peace.... for now!

[snicklin]

I'm back  I am just trying to make a rather silly procedure that gets the screen memory address to test using the passing of addresses. This is the code I would like to program... at this point in the code, SCREENADDR has not been used. I understand why the compiler has a problem with this.

 

 

 @GetScreenAddress &SCREENADDR

 

In order to get it to work, I do this:

 

 SCREENADDR=0

 @GetScreenAddress &SCREENADDR

 

The small issue here is that I am wasting memory by assigning zero. Is there any way that I can do something similar to the following code? I just want to inform the compiler that SCREENADDR is an integer.

 

 LET SCREENADDR

 @GetScreenAddress &SCREENADDR

[vitoco]

16 minutes ago, snicklin said:

 SCREENADDR=0

 @GetScreenAddress &SCREENADDR

 

The small issue here is that I am wasting memory by assigning zero. Is there any way that I can do something similar to the following code? I just want to inform the compiler that SCREENADDR is an integer.

I think that your problem is not related to the datatype, but to the fact that a variable should be previously defined to the parser when it found that you are using it. AFAIK, the only way to define a variable to the parser is with an assignment, and then the parser assigns a memory location to it. When you "use" a variable, the parser just replaces it with that memory location. Of course this is a simplification...

 

[snicklin]

5 minutes ago, vitoco said:

but to the fact that a variable should be previously defined to the parser when it found that you are using it.

 

Yes, that is the way that I've seen this. It is definitely to do with how it is compiled. I thought that there might be a way of tricking the compiler to tell it that a variable is a number. If I could declare it without assigning, that would be great. Perhaps it could be a compiler improvement?

[dmsc]

Hi!

18 hours ago, snicklin said:

Yes, that is the way that I've seen this. It is definitely to do with how it is compiled. I thought that there might be a way of tricking the compiler to tell it that a variable is a number. If I could declare it without assigning, that would be great. Perhaps it could be a compiler improvement?

First: the reason the parser/compiler needs a variable definition - via an assignment - before usage is that the compiler does not know if the text references a variable, a DIM array or a DATA array. But as this is BASIC, you don't need to "declare" a variable explicitly, it is declared on assignment. I recommend to include the assignment.

 

If you don't want to initialize the variable, what I do as a simple "solution" is to reorder my code using procedures. So, the assignment of the variable can be put before the usage.

 

In the future, perhaps I would add an extension using DIM:  "DIM myvar" would declare the variable without producing any code.

 

Have Fun!

[+Stephen]

4 minutes ago, dmsc said:

Hi!

First: the reason the parser/compiler needs a variable definition - via an assignment - before usage is that the compiler does not know if the text references a variable, a DIM array or a DATA array. But as this is BASIC, you don't need to "declare" a variable explicitly, it is declared on assignment. I recommend to include the assignment.

 

If you don't want to initialize the variable, what I do as a simple "solution" is to reorder my code using procedures. So, the assignment of the variable can be put before the usage.

 

In the future, perhaps I would add an extension using DIM:  "DIM myvar" would declare the variable without producing any code.

 

Have Fun!

Another reason I like that requirement, is it helps in debugging.  If you make a typo in the variable and don't require its use, a new variable would get created.  Gives me terrible nightmare flashbacks to the "OPTION STRICT" bullshit from VB6 days.

[snicklin]

13 hours ago, dmsc said:

what I do as a simple "solution" is to reorder my code using procedures. So, the assignment of the variable can be put before the usage.

As you may have seen above in the build step, I concatenate all of the files into one big one and compile that. I've now put my main source code (rather than libraries) at the end of these concatenated files and it works well! Thanks.

[funkheld]

i find the programs boring.
There is no connection to the outside with rs232 or tcp.

In fact, there is nothing fundamentally new, but rather small defects are always eliminated that are actually not noticeable.

 

the fresh wind with rs232 and tcp is missing

greeting

[danwinslow]

4 hours ago, funkheld said:

i find the programs boring.
There is no connection to the outside with rs232 or tcp.

In fact, there is nothing fundamentally new, but rather small defects are always eliminated that are actually not noticeable.

 

the fresh wind with rs232 and tcp is missing

greeting

Funk - I find your complaining boring. The world is not about you. If you don't like this language, then just don't post. If it's no good, it will die on it's own.

Why don't YOU bring this 'fresh wind'? You can do do at least little programs.

 

greeting

[snicklin]

19 hours ago, funkheld said:

i find the programs boring.
There is no connection to the outside with rs232 or tcp.

In fact, there is nothing fundamentally new, but rather small defects are always eliminated that are actually not noticeable.

 

the fresh wind with rs232 and tcp is missing

greeting

As Dan mentions, it is your choice if you want to use this language or not. Not that I have tested it myself, surely you could use TCP using the OPEN command?

 

What I like with FastBasic is that people can write code that works together with it. My intention is to write a large FastBasic library with lots of pre-built code in it and then hopefully release it later. This will make the language even more exciting.

 

Imagine if you have a language with:

Pre-built tiling systems,

Compression/decompression,

Really easy to use PM graphics,

A database system,

Sample playing,

Yes, TCP connectivity!,

Software sprites etc etc. (Not that I am promising all these).

 

... But these are the more complex routines which we could provide a nice and easy interface to. I would never expect a language (on an 8-bit) to have all these features built-in, but it does not stop us from building these as optional libraries.

 

When I talk with Daniel/DMSC, it is with the aim that he can get the language to the point where it as easy as possible for people like me to create libraries. Small defects will not be noticeable to some people, but may be noticeable to others. We all program differently.

 

I love the idea that I can prototype some code in FastBasic and then rewrite it to be faster in Assembly Language when I am happy with it.

 

[funkheld]

i don't use the language any more.
had previously played with the cross, but this cc65 fails
I have little freedom.

 

greeting

[Gury]

??

[snicklin]

1 hour ago, funkheld said:

i don't use the language any more.
had previously played with the cross, but this cc65 fails
I have little freedom.

 

greeting

As there are not 3 million users on here testing FastBasic, could you explain your OS/hardware/emulator setup, which version that you use, what you did and what the error is?

 

You may have a unique setup that fails. This sounds like one of those little bugs that needs fixing.

[Elkino]

You can try FastBasic online here: 

https://eahumada.github.io/AtariOnline/fastbasic/fastbasic-mame.html

type:

JOYAS [ENTER]

[dmsc]

Hi!

On 4/3/2021 at 7:24 AM, snicklin said:

As you may have seen above in the build step, I concatenate all of the files into one big one and compile that. I've now put my main source code (rather than libraries) at the end of these concatenated files and it works well! Thanks.

Just a heads-up: current version in Github allows declaring variables in DIM statement, so this is now possible:

DIM X, Y, S$
? X, S$

This allows declaring variables without generating any code. Note that in FastBasic all variables are initialized to zero (or empty strings), so the above example prints "0".

 

This feature added exactly 11 bytes to the size of the IDE

 

Have Fun!

[snicklin]

2 hours ago, dmsc said:

Current version in Github allows declaring variables in DIM statement

 

Excellent! Sorry about the 11 Bytes though

[+Philsan]

20 hours ago, Elkino said:

You can try FastBasic online here: 

https://eahumada.github.io/AtariOnline/fastbasic/fastbasic-mame.html

type:

JOYAS [ENTER]

I noticed your page some days ago, thanks!

What is the key for RESET?

[Elkino]

20 minutes ago, Philsan said:

I noticed your page some days ago, thanks!

What is the key for RESET?

Great, I'm working on it. I just looking for it in the source code of the emulation, but seems that MAME don't have a warm reset, currently you need to refresh your browser is you want a fresh start. I wonder why the editor ask to save when you press CTRL+Q, and you can not press ESC to cancel and just exit.

 

I fixed some mappings, F7=Is the break key and cursor movement maps to CTRL+NUMPAD 8,4,6,2 y will add the detail of the mappings at the botton of the page. LEFT ALT is FIRE and arrows are joystick directions.

 

All keys are located near to the original Atari position.

 

Can be great is in the future exists some like Altirra.js or Atari800.js to publish small Atari XL/XE 8-bit apps on the web, as atari800 on MAME.js seems to be not have active development.

 

Edited April 6, 2021 by Elkino

[+Philsan]

Wouldn't be better to map fire to CTRL and cursor movement to LEFT ALT + arrows (like state-of-the art emulator Altirra)?

Moreover, notebooks don't have numpad.