FastBasic 4.6 cross-compiler tips, tricks, quirks, and oddities?

[+yetanothertroll]

Looking for repeated strings to turn into DATA Byte ROM? This Windows cmd.exe line might be helpful,

 

G:\My Drive>find ".byte" G:Projects\8-bit\FBStats.asm | find """" | sort
        .byte <((.ident (.concat ("fb_var_", name)) - __HEAP_RUN__)/2)
        .byte   10, " free RAM", 155
        .byte   10, " reading ", 34
        .byte   10, " samples, "
        .byte   10, "Histogram "
        .byte   13, " values total"
        .byte   13, "Remedian ???", 155
        .byte   14, "Press any key "
        .byte   15, ", closing file "
        .byte   16, "Invalid number ", 34
        .byte   16, "Normal EOF, N = "
        .byte   16, "NUL marker, N = "
        .byte   16, 34, ", closing file "
        .byte   17, " statistics from "
        .byte   17, "Unexpected error "
        .byte   18, "to exit to system "
        .byte   2, " ]"
        .byte   2, "C:"
        .byte   21, "General statistics - "
        .byte   25, "Cannot process more than "
        .byte   3, " / "
        .byte   3, "=? "
        .byte   30, "MainState = 255", 155, "Closing file ", 34
        .byte   31, " data points processed so far!", 155
        .byte   4, " .. "
        .byte   4, " = S"
        .byte   4, " =? "
        .byte   4, "e = "
        .byte   4, "N = "
        .byte   4, "S = "
        .byte   5, " -> S"
        .byte   5, " Mode"
        .byte   5, " S = "
        .byte   5, "BREAK"
        .byte   5, "Mean "
        .byte   54, "Enter filename, BREAK or Ctrl-3 to exit,or Enter for ", 34
        .byte   6, " Mean "
        .byte   6, "Ctrl-3"
        .byte   6, "Error "
        .byte   6, "GMean "
        .byte   6, "HMean "
        .byte   6, "Sample"
        .byte   7, " Error "
        .byte   7, "Median "
        .byte   7, "Running"
        .byte   8, " Pressed"
        .byte   8, "Header ", 34
        .byte   8, "Ignore ", 34
        .byte   8, "No modes"
        .byte   8, "Range [ "
        .byte   8, "Samples "
        .byte   9, " samples", 155
        .byte   9, "Finalize "
        .byte   9, "Graphics "
        .byte   9, "Kurtosis "
        .byte   9, "Mean     "
        .byte   9, "Opening ", 34
        .byte   9, "R.M.S.   "
        .byte   9, "R.M.S.=? "
        .byte   9, "Skewness "
        .byte   9, "Std Dev  "
        .byte   9, "Variance "

G:\My Drive>

 

I've already gotten the easy stuff. An open question is, when is it worth it to "factor" a repeated substring out of two or more longer otherwise unique strings? I guess I have a PRINT " samples, "; and a PRINT " samples" in there. Is it worth turning them into DATA SCSamples() BYTE ROM = " samples" PRINT $(&SCSamples); ", "; and PRINT $(&SCSamples)  or no? How about the "Samples " and "Sample" strings, turn "Samples " into (presumably) PRINT $(&SCSample); "s "; or no? Also, PRINT CHR$(34) does beat out DATA SCDQ() BYTE ROM = 1, 34 PRINT $(&SCDQ) but what about PRINT $(&SCDQ); ? Or even DATA SCDQNL() BYTE ROM = 2, 34, 155 for when printed lines end with a double-quote?

Edited July 19 by yetanothertroll
Not typos this time, but thinkos, multiple

[dmsc]

Hi!

On 7/19/2024 at 7:43 PM, yetanothertroll said:

Looking for repeated strings to turn into DATA Byte ROM? This Windows cmd.exe line might be helpful,

Constant strings (as in  PRINT "HELLO WORLD" ), are always stored in ROM when you compile for a cart output, so you don't need DATA for this. If you want to reuse a string, you could use its address, but using a DATA could make the code bigger.

 

On 7/19/2024 at 7:43 PM, yetanothertroll said:

I've already gotten the easy stuff. An open question is, when is it worth it to "factor" a repeated substring out of two or more longer otherwise unique strings? I guess I have a PRINT " samples, "; and a PRINT " samples" in there. Is it worth turning them into DATA SCSamples() BYTE ROM = " samples" PRINT $(&SCSamples); ", "; and PRINT $(&SCSamples)  or no? How about the "Samples " and "Sample" strings, turn "Samples " into (presumably) PRINT $(&SCSample); "s "; or no? Also, PRINT CHR$(34) does beat out DATA SCDQ() BYTE ROM = 1, 34 PRINT $(&SCDQ) but what about PRINT $(&SCDQ); ? Or even DATA SCDQNL() BYTE ROM = 2, 34, 155 for when printed lines end with a double-quote?

 

The optimizer will optimize ' PRINT CHR$(34) ' to ' PRINT """"$9B; ', this is shorter.  But you can always just write that!. In FastBasic, you can put any character inside a string using double quotes (this is compatible with TurboBasicXL), and using the "$" notation:

 

Will print:

 

About the space it takes - using a variable uses 2 bytes for the variable, and the code uses two bytes to store the value, and two bytes each time you read it. For 2 uses, this is 8 bytes, so you need a string of at least 7 bytes to break even. BUT: the 2 bytes for the variable are in RAM, all the rest is in ROM, so using a variable to share strings will always use more RAM than without.

 

Have Fun!

 

[+yetanothertroll]

4 hours ago, dmsc said:

[good stuff]

 

About the space it takes - using a variable uses 2 bytes for the variable, and the code uses two bytes to store the value, and two bytes each time you read it. For 2 uses, this is 8 bytes, so you need a string of at least 7 bytes to break even. BUT: the 2 bytes for the variable are in RAM, all the rest is in ROM, so using a variable to share strings will always use more RAM than without.

 

Have Fun!

 

Hang on, doing this uses RAM?

 

 Data SCPressAny() Byte ROM = "Press any key "

...
 Print $(&SCPressAny); ' "Press any key ";

 Get Z

...

 Print $(&SCPressAny); ' "Press any key ";

 Get Z

...

Print $(&SCPressAny); "to exit to system "; ' "Press any key to exit to system ";
 
 Get Z

 

In other news, I think I have a handle on missile graphics. In a fractal viewer, I combine all four players into one cursor steered by the arrow keys, a numeric keypad if the driver's loaded, and a joystick, to allow zooming in and out, recentering, etc. The missiles use random shape and color changes to highlight the pixels actively being calculated. Any resemblance to a certain series of movies is not at all purely coincidental. Next I'll use what I learned from this for using the sprites for labelling graphs in GR.6, or maybe even GR.8, instead of having GR.7 chew up RAM even though only the left and right edge areas should need more than one bit per pixel.

 

It appears all the basic functionality for my stats application, without all the bells and whistles I really really want to add like the graph overlays, fits in an 8KB cart, just barely. But the math is mathing, even if all the PROC calls must be slowing it down quite a bit. Remedian was much easier to implement than expected, even suspiciously so. No wonder the authors made such an effort to mathematically prove that it really does work, but so far it really does! 😄

Matrix4.bas FBStats.bas

[+yetanothertroll]

It's time to try building 16KB cartridge images. The attached appear to work so far, but I haven't gone too nuts with the data tables and even moar floating point madness and such yet. Instead of modifying the existing fastbasic-cart.cfg, since I still want to be able to build normal 8KB carts in other projects, I made a fastbasic-cart16.cfg and atari-cart16-fp.tgt and atari-cart16-int.tgt files to use it. I did notice that atari-cart-int.tgt pulls in the fp library, not int,

 

# Atari 8-bit computers, integer-only for cartridge output
include atari-int
config fastbasic-cart.cfg
library fastbasic-cart-fp.lib
extension .rom

 

Is there a reason for this? When I switched it to fastbasic-cart-int.lib in atari-cart16-int.tgt, it appeared to work, but then I haven't exactly tried to whip up a full regression test suite for it 🤷‍♂️

 

So far so good!

atari-cart16-int.tgt atari-cart16-fp.tgt fastbasic-cart16.cfg

[+yetanothertroll]

@dmsc Help! Fre() appears to report the P/M graphics area as part of "free" memory in programs compiled to 8 or 16KB cart or to .XEX,

 

' P/M test program, cribbed from dmsc's pmtest.bas

i = Fre()

graphics 0          ' Setups graphics mode
pmgraphics 2        ' And P/M mode

Print "Fre() "; i; " "; Fre()

Print "PMAdr(-1) "; PMAdr(-1); " PMAdr(0) "; PMAdr(0)

Print "Fre() "; Fre()

i = (Fre() - 32) / 2

Print "Dim Foo("; i; ")"

Dim Foo(i)

Print "&Foo "; &Foo; " "; i; "*2 "; &Foo + (i * 2)

Dim Bar(1)

Print "&Bar "; &Bar; " "; 1; "*2 "; &Bar + (1 * 2)

Print "Fre() "; Fre()

Print
Print "OK"

Get Z

End

 

Using Fre() to calculate array sizes causes much of Foo() and all of Bar() overlap the P/M graphics area,

 

 

Is there a way to tell Fre() I intend to use the sprites and not to consider the P/M memory as up for grabs?

 

[dmsc]

Hi!

4 minutes ago, yetanothertroll said:

@dmsc Help! Fre() appears to report the P/M graphics area as part of "free" memory in programs compiled to 8 or 16KB cart or to .XEX,

 

Yes. I modeled the PMGRAPHICS command based on the Altirra BASIC implementation, that also does not account the P/M memory for the calculation of the FRE memory. This gives you the flexibility to do your own accounting, depending on if you are using the missiles or only the players.

 

But, PMGRAPHICS *do* check the free memory before setting the mode, so you should first allocate all the memory you need, and then use the PMGR. command - this will give you an out of memory error if there is not enough memory for the P/M.

 

Internally, FRE() is compiled to "DPEEK(@MEMTOP) - DPEEK(@@BASIC_TOP)", if you need to know the available memory after the PMGR., you can do:

 

? FRE(), DPEEK(@MEMTOP)-DPEEK(@@BASIC_TOP)  ' Those should be the same number
PMGR.2
? PMADR(0) - DPEEK(@@BASIC_TOP) ' Free memory up to the first player
? PMADR(-1) - DPEEK(@@BASIC_TOP) ' Free memory up to the missiles

 

The above will only work in the cross compiler, in the Atari IDE you should use the numeric constants, but be aware that the address changes between the IDE and the cross compiler:

 

Have Fun!

 

[+yetanothertroll]

Cool, this gives me an alternative to something like,

 

Dim SmallArray(2)

Dim BigArray%((PMAdr(-1) - Adr(SmallArray) - 32) / 6)

 

or even, if I'm only using one player, use player 3,

 

Dim BiggerArray%((PMAdr(3) - Adr(&SmallArray) - 32) / 6)

 

...although I just can't seem to resist finding some excuse, any excuse, to use the missiles and all four players 😄

 

Another idea is to use Fre() to dynamically select between, say, GR.6 and GR.8 and between PMG.1 and PMG.2, then DIM from what's left over

 

Matrix4.bas PMTest2.bas

[Piotr D. Kaczorowski]

Dear All,

 

I'm new to Fast Basic, and I've tried some snippets. It's a cool language for the Atari.

 

I’m looking for snippets that provide the following:

- A program that prints parameters from the command line. For example, I'd like to write a "copy <file1> <file2>" program and need to obtain the command line arguments.

- An example with assembler/machine code inside.

- Maybe a small game example?

 

I also created the #fast-basic channel on Atari 8-bit Programming Discord server - persistent invitation: https://discord.gg/GTapZjCsgp

 

Best,

Peter

Edited July 27 by Piotr D. Kaczorowski

[dmsc]

Hi!

5 hours ago, Piotr D. Kaczorowski said:

Dear All,

 

I'm new to Fast Basic, and I've tried some snippets. It's a cool language for the Atari.

 

I’m looking for snippets that provide the following:

- A program that prints parameters from the command line. For example, I'd like to write a "copy <file1> <file2>" program and need to obtain the command line arguments.

Use @fenrock here wrote some code for command line parsing at https://github.com/markjfisher/fb-args . I did not add this functionality to the language proper because I try to keep FastBasic as small as posible.

 

5 hours ago, Piotr D. Kaczorowski said:

- An example with assembler/machine code inside.

There is a very small example of using USR in the testsuite: https://github.com/dmsc/fastbasic/blob/master/testsuite/tests/testusr.bas

 

For the cross-compiler (that allows you to use proper assembly) there is also an example in the manual: https://github.com/dmsc/fastbasic/blob/master/compiler/USAGE.md#linking-other-assembly-files

 

5 hours ago, Piotr D. Kaczorowski said:

- Maybe a small game example?

 

There are a few samples included in the source, the Joyas game is a small full game: https://github.com/dmsc/fastbasic/blob/master/samples/int/joyas.bas

 

Over the years, there have been a lot of games released as ten-liners in FastBasic, @vitoco has all his games with full explanation of the code in one page at: https://www.vitoco.cl/atari/10liner/index.html , about a third of the games are written in FastBasic, look at exceptional games like Patrol, Wazers, The Children, 1vas0r, Chase Me, Sweeper, Pac-10liner, and a lot of other good games.

 

And if you look at past ten-liner contest you will find some really good ones, like:

- Tetris https://bunsen.itch.io/tetris-atari-8-bit-by-eric-carr  Jumpman https://bunsen.itch.io/jumpman-by-eric-carr , Gunner https://bunsen.itch.io/gunner-atari-8-bit-by-eric-carr and Star Runner https://bunsen.itch.io/starrunner-by-eric-carr by Eric Carr , more at https://github.com/EricCarrGH/BASICProjects and here as @The Car

- Wizard of WASD https://angrydill.com/wasd/ by Randy Gill @AngryDill

- Rockfall https://bunsen.itch.io/rockfall-by-preppie and Runner by @Preppie

 

We sure need a big repo with all the games  

 

5 hours ago, Piotr D. Kaczorowski said:

I also created the #fast-basic channel on Atari 8-bit Programming Discord server - persistent invitation: https://discord.gg/GTapZjCsgp

 

I will look around 🙂

 

Have Fun!

 

[Piotr D. Kaczorowski]

@dmsc,

 

Thank you

[Piotr D. Kaczorowski]

GETCMD by @dmsc  in ATR image.

fb_getcmd.atr

Edited July 28 by Piotr D. Kaczorowski

[Piotr D. Kaczorowski]

FBC Integer version - 4.7-b1 CI build.  

 

Binaries are 1 KB smaller than ordinary files.  Not always FP is required.  

 

@dmsc, please include in the build the FBC compiler without FP module.

 

fbci.com.zip

fastbasic-fbci-makefile.tgz

Edited August 2 by Piotr D. Kaczorowski

[+yetanothertroll]

On 7/27/2024 at 4:50 AM, Piotr D. Kaczorowski said:

Dear All,

 

I'm new to Fast Basic, and I've tried some snippets. It's a cool language for the Atari.

 

I’m looking for snippets that provide the following:

- A program that prints parameters from the command line. For example, I'd like to write a "copy <file1> <file2>" program and need to obtain the command line arguments.

- An example with assembler/machine code inside.

- Maybe a small game example?

 

I also created the #fast-basic channel on Atari 8-bit Programming Discord server - persistent invitation: https://discord.gg/GTapZjCsgp

 

Best,

Peter

 

If you want this file copy command to also have an interactive mode if, say, only <file1> is on the command line and you expect <file2> to be very similar to <file1>, it appears to be possible to "trick" Input into being a line editor, at least in OS-B. I haven't tried using AltirraOS or others. I'm using a mixed text/graphics mode so the text window cursor location is at 656, 657, and 658. After the cursor location is Poke'd back, at least one character needs to be printed or Input display a prompt to synch up the visible screen cursor.

 

  Print "X";
  CY = Peek(656)
  CX = DPeek(657)
  Print "?"; FTemp%(0);
  Poke 656, CY
  DPoke 657, CX
  Input F0$

  FTemp%(0) = Val(F0$)

  If FTemp%(0) = 0.0 Then Exit

  Print CX; " "; CY; " """; F0$; """ "; Str$(FTemp%(0))

 

Beware the full FBExps.bas program, it's full of equally quick and dirty stuff!

FBexps.bas

[Piotr D. Kaczorowski]

 

Another mod for FastBasic, that provides CMD arguments in the command line compiler.

 

 

 

cmdline.bas

[Piotr D. Kaczorowski]

@yetanothertroll, check the previous post and CMDLINE.BAS 

 

Best,

Peter

[dmsc]

Hi!

On 8/2/2024 at 1:25 PM, Piotr D. Kaczorowski said:

FBC Integer version - 4.7-b1 CI build.  

 

Binaries are 1 KB smaller than ordinary files.  Not always FP is required.  

 

@dmsc, please include in the build the FBC compiler without FP module.

 

If you think it is useful, I will include it in the next release. The reason I did not included it before is to limit the complexity of the package - and if you want to produce a really smaller binary you could use the cross compiler (that only includes actually used statements).

 

Have Fun!

 

[dmsc]

Hi!

On 8/2/2024 at 1:25 PM, Piotr D. Kaczorowski said:

FBC Integer version - 4.7-b1 CI build.  

 

Binaries are 1 KB smaller than ordinary files.  Not always FP is required.  

 

@dmsc, please include in the build the FBC compiler without FP module.

 

Done, see latest github commit.

 

Have Fun!

 

[Piotr D. Kaczorowski]

@dmsc

 

Thank you!

 

Quote

if you want to produce a really smaller binary you could use the cross compiler 

 

To improve things, I'm using a real Atari. This allows me to test different usability scenarios. My real Atari has a 65C816 processor running at 40 MHz and 16 MB of linear memory, which is more than sufficient to handle all tasks related to Atari systems using the Atari itself.

[+yetanothertroll]

On 7/27/2024 at 4:50 AM, Piotr D. Kaczorowski said:

...

 

- Maybe a small game example?

 

...

The definitely not small (32KB source code and counting!) statistics application that began as a small demo is becoming more and more game-like by the day. There's been that big main loop from day one, and now, to compensate for occasional failed cassette reads on real hardware thanks to an Atari OS bug, I really should add in "game" state save/reload support. That way, if tape X out of Y fails, you just have to retry tape X (ie, restart level X) instead of having to start over from scratch (ie, level one)

 

Not screenshots of the FB program,

 

[Piotr D. Kaczorowski]

@dmsc,

 

I've seen that during building scripts XEX files are changed to COM.  

 

It is better to change from XEX to EXE rather than to COM. In the case of longer code under SDX, you need to run the compiler as "X FBCI". If the COMEXE.SYS driver is installed beforehand, then files with the EXE extension are run as if they had the "X" prefix, so you only need to run "FBCI" instead of "X FBCI".  The compiler will be run in the "cartridge memory space free" and has more memory to compile the code.

 

Best,

Peter

[dmsc]

Hi!

5 hours ago, Piotr D. Kaczorowski said:

@dmsc,

 

I've seen that during building scripts XEX files are changed to COM.  

 

It is better to change from XEX to EXE rather than to COM. In the case of longer code under SDX, you need to run the compiler as "X FBCI". If the COMEXE.SYS driver is installed beforehand, then files with the EXE extension are run as if they had the "X" prefix, so you only need to run "FBCI" instead of "X FBCI".  The compiler will be run in the "cartridge memory space free" and has more memory to compile the code.

The problem is, I don't use SDX, I use BW-DOS 😛 .

 

And BW-DOS, XDOS, OS/A+, Sparta DOS and other command line DOS all work with ".COM" files, and the users would need to type the extra extension if it were ".EXE".

 

IMHO, it is SDX the one that is incompatible with the Atari standard - it would be easier for the SDX users if it simply used a different extension for the SDX executable files, and used "X" automatically for ".COM".

 

So, sorry but I won't change the default extensions 🙂 

 

Have Fun!

 

[Piotr D. Kaczorowski]

3 hours ago, dmsc said:

Hi!

The problem is, I don't use SDX, I use BW-DOS 😛 .

 

And BW-DOS, XDOS, OS/A+, Sparta DOS and other command line DOS all work with ".COM" files, and the users would need to type the extra extension if it were ".EXE".

 

IMHO, it is SDX the one that is incompatible with the Atari standard - it would be easier for the SDX users if it simply used a different extension for the SDX executable files, and used "X" automatically for ".COM".

 

So, sorry but I won't change the default extensions 🙂 

 

Have Fun!

 

 

Ok.  Understand.  Of course it's not a problem. 

 

>  SDX the one that is incompatible with the Atari standard

 

Can you write a bit more about this topic?

 

[Piotr D. Kaczorowski]

 

Quote

I use BW-DOS 😛 .

 

I downloaded latest 1.4 version yesterday and it would be my second after SDX DOS that I will be using. Looks pretty nice.  The first-order SDX is important to me because of its support for the 65C816.

 

[+yetanothertroll]

9 minutes ago, Piotr D. Kaczorowski said:

 

Ok.  Understand.  Of course it's not a problem. 

 

>  SDX the one that is incompatible with the Atari standard

 

Can you write a bit more about this topic?

 

 

Congratulations! You have just volunteered to translate the details of the SDX relocatable executable format to English and whatever other languages you may know!

 

https://forums.atariage.com/topic/155109-spartados-x-relocatable-executable-format/

[+DjayBee]

21 minutes ago, Piotr D. Kaczorowski said:

>  SDX the one that is incompatible with the Atari standard

 

Can you write a bit more about this topic?

 

Seems that you like open cans of worms. 🤣