FastBasic - Summer Release

[Geister]

Thanks for the tips. I may try to get everything moved to SpartaDos which was pretty compatible with everything. i was using older DOS versions because I was investigating Atari Pascal and Advan Basic which a pretty married to old DOS's which is part of why I will probably dismiss them after playing with them for a while. Portable is best.

 

To my knowledge, I had Basic out on Altirra. But it has fooled me before by dropping a configuration without warning. I'll have to check again.

 

It's a shame that Advan Basic is so tied to Dos 2.x because it has a LOT of nice features.

[dmsc]

Hi!

 

Thanks for the tips. I may try to get everything moved to SpartaDos which was pretty compatible with everything. i was using older DOS versions because I was investigating Atari Pascal and Advan Basic which a pretty married to old DOS's which is part of why I will probably dismiss them after playing with them for a while. Portable is best.

 

To my knowledge, I had Basic out on Altirra. But it has fooled me before by dropping a configuration without warning. I'll have to check again.

 

It's a shame that Advan Basic is so tied to Dos 2.x because it has a LOT of nice features.

As @vitoco said, FastBasic is compatible with any Atari DOS, only requirement is that MEMLO is less than $2000.

 

If you use SpartaDOS, remember to load the IDE with "X FB.COM" or "X FBI.COM", this gives you 8K more memory for your program. I normally prefer BW-DOS as a "native" DOS, because it runs my Atarii 800XL without any modification, uses very little RAM and is compatible with programs that use RAM under the ROM.

 

About your other questions:

- PMTEST.BAS : This is a ery simple player/missile test, the expected output is a little "ball" bouncing in the screen, the background changes color to indicate how much CPU time is left in each frame. If you run it in a PAL atari, you see all background purple, but in NTSC only about 3/4 of the screen are purple, meaning that you have less CPU time available. Also, when the ball bounces, there are more calculations in the loop, so the purple part shrinks.

- CARRERA3.BAS : This example is too big to run inside the IDE, you should compile to disk with CONTROL-W and then run it from DOS.

 

Have fun!

[Geister]

I got my test program to compile under Fast Basic. It worked very well at about the same speed as Advan Basic and Turbo Basic XL I have to get the code updated for printing the elapsed time to see if there are any differences.

 

With Advan Basic, I had to link in the fast floating point libraries to get comparable performance to Turbo or Fast Basic.

 

What I really like about Fast Basic is the programming environment seems more natural, like programming in Atari Basic but with advanced features that seem more like Visual Basic. I like named subroutines the freedom from line numbers.

[dmsc]

Hi Geister!

 

I got my test program to compile under Fast Basic. It worked very well at about the same speed as Advan Basic and Turbo Basic XL I have to get the code updated for printing the elapsed time to see if there are any differences.

 

With Advan Basic, I had to link in the fast floating point libraries to get comparable performance to Turbo or Fast Basic.

 

What I really like about Fast Basic is the programming environment seems more natural, like programming in Atari Basic but with advanced features that seem more like Visual Basic. I like named subroutines the freedom from line numbers.

Thanks!

 

Please, if you found any bug or missing feature, report it here or by PM so I can address it.

[dmsc]

Hi!

 

A new release is available, with some bugfixes and optimizations:

- Fixes floating-point STR$ function.

- Makes the IDE process much larger source lines without "long line" errors.

- Allows joining lines in the editor by pressing DELETE at the end of one line.

- Many simplifications to the editor, making the IDE smaller.

 

Thanks to the optimizations to the editor, the new FBI.COM (the integer-only IDE) is only 7973 bytes, and the code can parser much bigger lines, needed for the ten-liners

 

Thanks to Vitoco and Philsan for all the testing, enjoy!

 

As always, download the new release (Native IDE and cross compilers for Linux/Windows/macOS) from https://github.com/dmsc/fastbasic/releases

[vitoco]

Thanks to you!!!

 

BTW, as this is a minor version update (3.4), I guess that it cannot be called "Autumn Release"...

[+Larry]

Hi dmsc-

 

You've sure done a lot with this, and surely looks good. If you ever want to add another useful feature, please consider $tring Arrays. Only Basic XL and XE have those (+ the pretty much unused Atari Microsoft Basic). If you are doing something that requires lists, they are extremely handy. And doing substring gyrations are a poor substitute. Anyway, on my wish list.

 

-Larry

[dmsc]

Hi!

 

Hi dmsc-

 

You've sure done a lot with this, and surely looks good. If you ever want to add another useful feature, please consider $tring Arrays. Only Basic XL and XE have those (+ the pretty much unused Atari Microsoft Basic). If you are doing something that requires lists, they are extremely handy. And doing substring gyrations are a poor substitute. Anyway, on my wish list.

 

-Larry

String arrays is in my list, I even have a working testing version with those. Problem is that currently they use too much memory (256 bytes for each assigned array element). So, I'm trying to implement dynamic string memory, with strings using memory according to the actual length, but it is not finished yet

 

Attached is the test version, use string arrays as:

 DIM ar$(100)
 ar$(10) = "Some Text"
 ar$(30) = "More Text"
 for i=0 to 99
   if ar$(i) <> ""
     ? i ; ":"; ar$(i)
   endif
 next i

One think I want to know is the use-case for string arrays, so I can provide useful syntax for the operations.

fastbasic-test.atr

[+Larry]

Terrific!

 

I'll dig out some Basic XL/XE programs that I've done and post a couple of partial examples.

 

-Larry

[Geister]

MS Basic String handling like in Basic Xl/XE would be nice along with advanced string functions like LEFT$(), MID$(), and RIGHT$(). Equally valuable would be an actual string concatenation operator like STR1$ = STR1$ + STR2$, or a function like STR1$ = CONCAT$(STR1$, STR2$).

 

Apart from its slowness, the greatest weakness of Atari Basic was string handling.

[vitoco]

Apart from its slowness, the greatest weakness of Atari Basic was string handling.

 

Atari BASIC does not have string functions other than STR$() and VAL(), but I couldn't say that the way it handles substrings is weak. Is it possible to specify string slices both as a rvalue (read) or lvalue (write, left side of an assignment).

 

For instance, that is the way PUR-80 tenliners for this year's contest manages animations.

[flashjazzcat]

The weakness was really the complete absence of string arrays, but it's easy enough to work around that.

[Timothy Kline]

Hi!

 

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.

 

I'm coming into this late, and haven't programmed ANYthing in long enough time that I'm having to re-learn everything— so forgive me if this is a moronic question, but, am I correct in understanding that the 6502 stack doesn't have a counter so we can know how far down we've pushed toward the stack's cap after passing a value to it?

 

I ask because I'm not clear on what you meant when you said that the interpreter pushes the argument in the stack, but without counting them. If the 6502 has a counter for its stack, is there a problem with utilizing it as needed? Or, is there a distinction here between arguments going into the stack and other values that get STA'd, for example?

 

Like I said, I'm starting all over again here, programming-wise, so forgive me my complete cluelessness. I'm curious because I figure that if I have to relearn programming, I'm going 6502 assembly this time, although BASIC is pleasant enough, definitely— which is why this particular point caught my attention and made me ask about it: sounds like something I need to know as I learn machine coding the 6502.

 

--Tim

[+Philsan]

String arrays is in my list, I even have a working testing version with those. (...)

 

 

Thank you!

At the time, I didn't like the fact that Atari Basic lacked strings handling.

Many type-in listings for other machines didn't work.

A compatibility with popular C64 Basic strings handling would be nice.

[Geister]

 

Atari BASIC does not have string functions other than STR$() and VAL(), but I couldn't say that the way it handles substrings is weak. Is it possible to specify string slices both as a rvalue (read) or lvalue (write, left side of an assignment).

 

For instance, that is the way PUR-80 tenliners for this year's contest manages animations.

Yes, the Atari can do some clever tricks with strings, but sometimes you just want to carve up text with the least finagling, and Atari string handling is all about the finagling. In a Microsoft style Basic (nearly every other Basic in existence), you can have arrays of strings containing mixed data with delimiters and use string functions like instr$(), left$(), and mid$(), etc$(), to pull apart the string and extract data. It's the closest you can get to having structs without adding structs to Basic.

 

Philsan has an excellent point also, Portability of code between Basics is a desireable feature as I learned when a gentleman asked me to help him port a horse handicapping program from Microsoft Basic to the Atari. It was an exercise in frustration with Atari string handling and lack of string arrays, which the program used heavily. I thought it would be an easy port because there were no graphics, but I finally had to admit that it would take far longer than I had time for, and may not have fit in free memory in its final form. It might have been cheaper to simply sell a copy of MS-Basic with every copy of his program.

 

Ideally, you'd want a basic with the best of both worlds. I don't really know what PUR-80 ten liners are, but guessing from the title I would surmise it is packing as much functionality into ten lines of "pure" Atari Basic as possible. What does that have to do with the features of a Basic that seeks to expand upon what Atari Basic can do in terms of features and execution speed?

 

dmsc, while I'm wishing, how about a "PrintUsing()" feature for doing formatted printing? You don't have to get into regular expressions (I hate those anyway).

 

Also, what is the deal with procedure arguments? Are they not supported or it is try it at your own risk?

Edited March 25, 2018 by Geister

[FifthPlayer]

In a Microsoft style Basic (nearly every other Basic in existence), you can have arrays of strings containing mixed data with delimiters and use string functions like instr$(), left$(), and mid$(), etc$(), to pull apart the string and extract data. It's the closest you can get to having structs without adding structs to Basic.

 

You can do all of this in Atari Basic as well. Personally I prefer Atari Basic's double-subscript syntax to slice strings over separate functions such as left$(), mid$(), etc. To me it is cleaner.

[dmsc]

Hi!

 

I'm coming into this late, and haven't programmed ANYthing in long enough time that I'm having to re-learn everything so forgive me if this is a moronic question, but, am I correct in understanding that the 6502 stack doesn't have a counter so we can know how far down we've pushed toward the stack's cap after passing a value to it?

 

I ask because I'm not clear on what you meant when you said that the interpreter pushes the argument in the stack, but without counting them. If the 6502 has a counter for its stack, is there a problem with utilizing it as needed? Or, is there a distinction here between arguments going into the stack and other values that get STA'd, for example?

 

Like I said, I'm starting all over again here, programming-wise, so forgive me my complete cluelessness. I'm curious because I figure that if I have to relearn programming, I'm going 6502 assembly this time, although BASIC is pleasant enough, definitely which is why this particular point caught my attention and made me ask about it: sounds like something I need to know as I learn machine coding the 6502.

 

--Tim

The 6502 has a stack-pointer register that is decremented and incremented each time you push or pop something to the stack. But each time you call a subroutine the stack-pointer is modified, as the return address is pushed, so it is not easy to track how many values you pushed without knowing the original stack-pointer value.

 

A possible workaround would be to store the stack-pointer value when processing the start of the USR call and then just before the call subtract the new value from the original and divide by two. All in all, I'm not convinced that all that extra code is needed, as I don't think that USR calls with variable number of arguments is used a lot. It's simpler to use the rule: "to convert an USR routine from AtariBasic to FastBasic, sremove the first PLA (or 104, $68) from the code."

[dmsc]

Hi all!

 

MS Basic String handling like in Basic Xl/XE would be nice along with advanced string functions like LEFT$(), MID$(), and RIGHT$(). Equally valuable would be an actual string concatenation operator like STR1$ = STR1$ + STR2$, or a function like STR1$ = CONCAT$(STR1$, STR2$).

 

Apart from its slowness, the greatest weakness of Atari Basic was string handling.

I plan to add string handling functions, but possibly only to he floating-point version to keep the small size of the integer-only IDE. I really want to keep the base implementation under 8kB, and currently I have only 219 bytes left

 

But, I don't like the "RIGHT$", "MID$" and "LEFT$" function names, I think that the syntax is confusing for assignments and too long, like ' MID$(A$,3,2)="TEST" '.

 

One possibility is using a square-bracket syntax, like: ' A$[3,5] = "TEST" : ? A$[1] ', I think that would be more natural, but incompatible with other basics.

 

 

Thank you!

At the time, I didn't like the fact that Atari Basic lacked strings handling.

Many type-in listings for other machines didn't work.

A compatibility with popular C64 Basic strings handling would be nice.

One question, does C64 basic allows assigning to MID$, as ' MID$(A$,2)="hello" ' ?

 

 

Yes, the Atari can do some clever tricks with strings, but sometimes you just want to carve up text with the least finagling, and Atari string handling is all about the finagling. In a Microsoft style Basic (nearly every other Basic in existence), you can have arrays of strings containing mixed data with delimiters and use string functions like instr$(), left$(), and mid$(), etc$(), to pull apart the string and extract data. It's the closest you can get to having structs without adding structs to Basic.

 

Philsan has an excellent point also, Portability of code between Basics is a desireable feature as I learned when a gentleman asked me to help him port a horse handicapping program from Microsoft Basic to the Atari. It was an exercise in frustration with Atari string handling and lack of string arrays, which the program used heavily. I thought it would be an easy port because there were no graphics, but I finally had to admit that it would take far longer than I had time for, and may not have fit in free memory in its final form. It might have been cheaper to simply sell a copy of MS-Basic with every copy of his program.

 

Ideally, you'd want a basic with the best of both worlds. I don't really know what PUR-80 ten liners are, but guessing from the title I would surmise it is packing as much functionality into ten lines of "pure" Atari Basic as possible. What does that have to do with the features of a Basic that seeks to expand upon what Atari Basic can do in terms of features and execution speed?

 

dmsc, while I'm wishing, how about a "PrintUsing()" feature for doing formatted printing? You don't have to get into regular expressions (I hate those anyway).

 

Also, what is the deal with procedure arguments? Are they not supported or it is try it at your own risk?

About "print using", this is not easy to implement, as FastBasic uses the math-pack FASC function to convert floating point to decimal, so it has no control over the format returned. A simpler function to implement is TAB(), as ' PRINT "Hello"; TAB(20); "World" ', that would allow to print lists more easily.

 

And about procedure parameters, those are not supported (yet?), the parser is not powerful enough at this time to address parameters without storing the values in variables, so for example one possible implementation would change:

PROC test, x, y
  POS. x, y
  ? "X";
ENDPROC

Into the equivalent:

PROC test, x, y : test_y = y : test_x = x
  POS. test_x, test_y
  ? "X";
ENDPROC

The idea is that each parameter should define a "local" variable that is filled at procedure start. But, now we have another problem: the parser should ensure that the procedure is called with the correct number of arguments, or the execution would fail. So, you must define the procedure before calling it. All in all, not that simple for this "small" basic.

 

You can do all of this in Atari Basic as well. Personally I prefer Atari Basic's double-subscript syntax to slice strings over separate functions such as left$(), mid$(), etc. To me it is cleaner.

Ye, I tend to agree, this is why I proposed the square brackets syntax instead.

 

Thanks for all the suggestions!

[+Philsan]

One question, does C64 basic allows assigning to MID$, as ' MID$(A$,2)="hello" ' ?

 

MID$

  TYPE: String Function
  FORMAT: MID$(<string>,<numeric-1>[,<numeric-2>])

    Action: The MID$ function returns a sub-string which is taken from
  within a larger <string> argument. The starting position of the sub-
  string is defined by the <numeric-1> argument and the length of the
  sub-string by the <numeric-2> argument. Both of the numeric arguments
  can have values ranging from 0 to 255.
    If the <numeric-1> value is greater than the length of the <string>,
  or if the <numeric-2> value is zero, then MID$ gives a null string value.
  If the <numeric-2> argument is left out, then the computer will assume
  that a length of the rest of the string is to be used. And if the source
  string has fewer characters than <numeric-2>, from the starting position
  to the end of the string argument, then the whole rest of the string is
  used.

  EXAMPLE of MID$ Function:

    10 A$="GOOD"
    20 B$="MORNING EVENING AFTERNOON"
    30 PRINT A$ + MID$(B$,8,

    GOOD EVENING

All infos here: C64 Programmer's Guide

[dmsc]

Hi!

 

 

MID$

  TYPE: String Function
  FORMAT: MID$(<string>,<numeric-1>[,<numeric-2>])

    Action: The MID$ function returns a sub-string which is taken from
  within a larger <string> argument. The starting position of the sub-
  string is defined by the <numeric-1> argument and the length of the
  sub-string by the <numeric-2> argument. Both of the numeric arguments
  can have values ranging from 0 to 255.
    If the <numeric-1> value is greater than the length of the <string>,
  or if the <numeric-2> value is zero, then MID$ gives a null string value.
  If the <numeric-2> argument is left out, then the computer will assume
  that a length of the rest of the string is to be used. And if the source
  string has fewer characters than <numeric-2>, from the starting position
  to the end of the string argument, then the whole rest of the string is
  used.

  EXAMPLE of MID$ Function:

    10 A$="GOOD"
    20 B$="MORNING EVENING AFTERNOON"
    30 PRINT A$ + MID$(B$,8,

    GOOD EVENING

All infos here: C64 Programmer's Guide

 

So, the answer is no, it does not support assigning to the middle of a string, making the interpreter simpler.

Edited March 25, 2018 by dmsc

[Geister]

Typically, most languages do not support treating a string function as the string itself, so you cannot assign a string to a string function anymore than you'd do something like ABS(4/3)=42. It's semantically nonsense.

 

Instead, you'd do something like A$ = LEFT$(A$, 2) + "HELLO". If you wanted to preserve the rest of the original string, you'd have to use the LEN() function to figure out where the addition of the "HELLO" placed you in the original string and concatenate something like RIGHT$(A$, 4 + LEN("HELLO"))

[vitoco]

As FastBasic is a work in progress, I think it's useful to discuss and give ideas and some feedback for new features like string arrays and string functions.

 

STR$() was added to FastBasic because I requested it for my tenliners (and because it wouldn't require too much extra code as PRINT was already doing that conversion internally).

 

I've only used LEFT$(), MID$() and RIGHT$() standard functions in Visual Basic and found them useful, but the way they work requires to do many memory manipulation. Big machines have "unlimited" RAM and MHz, but our Ataris don't. I'd like to manipulate strings in a way that it is not required to copy bytes on each assignment, because that would slurp the RAM and it is slow.

 

I like the way Atari BASIC allows us to modify some chars inside the string using slices, without having to copy all to a buffer and back again to the variable. At least that is what I think most BASIC implementations do using standard sting functions.

[vitoco]

@dmsc:

 

Please, please, please don't allow string concatenation using addition sign. I feel that it is error prone. Someone might say that it depends in the context, but when automatic cast is allowed, all becomes dark. I had to force a datatype using explicit functions to make the "+" sign work as expected, and most of the times in SQL's procedural language scripts or queries. Annoying!

 

Since FastBasic is Atari-oriented, I'd like to add an optional parameter to the STR$() function: As graphics modes 1 and 2 allow 4 colors for text based on bits 6 and 7 of the internal code of each byte, it could be great that STR$() function could convert a number to a text string with those bits already set. Or to add an offset in order to get both ATASCII bytes for PRINT and internal bytes for MOVE as required.

 

[Geister]

@dmsc:

 

Please, please, please don't allow string concatenation using addition sign. I feel that it is error prone. Someone might say that it depends in the context, but when automatic cast is allowed, all becomes dark. I had to force a datatype using explicit functions to make the "+" sign work as expected, and most of the times in SQL's procedural language scripts or queries. Annoying!

 

Since FastBasic is Atari-oriented, I'd like to add an optional parameter to the STR$() function: As graphics modes 1 and 2 allow 4 colors for text based on bits 6 and 7 of the internal code of each byte, it could be great that STR$() function could convert a number to a text string with those bits already set. Or to add an offset in order to get both ATASCII bytes for PRINT and internal bytes for MOVE as required.

 

That is a good point as using that format can be confusing. A alternative could be using the ampersand as some languages do,

 

You are also correct that MS-BASIC does not preserve the original string but replaces it with the result of the expression. It may be more memory intensive, but there are many 8-bit basics that use the functions including MIcrosoft Basics, the Advan Basic Compiler and Basic XL/XE all of these are excellent Basics that do not require an X86 CPU and unlimited memory to operate.

[+Larry]

Terrific!

 

I'll dig out some Basic XL/XE programs that I've done and post a couple of partial examples.

 

-Larry

 

Haven't forgotten about this. But having a little trouble locating the particular programs I was referring to. I should be able to find them -- else I'll make up some new ones. Basic XL/XE also had the Left$, Right$, Mid$. One neat little feature that I recall is the Basic XL/XE used a ";" (semicolon) after the string name to denote it was a string array.

-Larry

 

Edit: Found the disk I was looking for -- now I have to make sense of what I was doing to explain the examples. It was a disk cataloging system that I wrote in Basic XE in the late 80's and early 90's.