Current BASIC Options?

[Daedalus2097]

This may have been answered before, but I wanted to check to make sure I understand the situation fully. I'm looking to dabble in BASIC on my 800XL after decades of not touching it. In the meantime I've been coding other stuff in various languages, but most hobby stuff would be in Blitz Basic on the Amiga. Now, I'd like to refresh/re-do my old Atari programs from back in the day, but also convert some of my newer programs for the Atari (with necessary adjustments of course). These would be mostly simple turn-based games with the option of a computer opponent.

 

What I would like from a BASIC that the original Atari BASIC I used couldn't do:

- String arrays (with strings as each element, rather than a character as each element like Atari BASIC)

- Compilation for speed

- Procedures that support recursive calling (so stack, local variables etc.)

- Perhaps slightly better graphics support - sprites etc.

 

I'd prefer to use the real hardware (stock other than an SIO2SD solution) if possible but emulation or cross compilation aren't entirely ruled out. From what I read, there are two main options: Turbo Basic XL and FastBasic. Do either (or both) of these tick all the boxes above? Are there any other options I should look at? Am I expecting too much?

 

Thanks!

[Preppie]

FastBasic is a great option but it doesn't have proper strings, it has procedures but not the type you're after.  Speed is great and it also has some better graphic support (with the writer improving them as we speak).

 

Unfortunatly, I don't know of a BASIC that covers all your needs.

 

 

[thorfdbg]

8 hours ago, Daedalus2097 said:

- String arrays (with strings as each element, rather than a character as each element like Atari BASIC)

- Compilation for speed

- Procedures that support recursive calling (so stack, local variables etc.)

- Perhaps slightly better graphics support - sprites etc.

 

I'd prefer to use the real hardware (stock other than an SIO2SD solution) if possible but emulation or cross compilation aren't entirely ruled out. From what I read, there are two main options: Turbo Basic XL and FastBasic. Do either (or both) of these tick all the boxes above? Are there any other options I should look at? Am I expecting too much?

There is also Basic++, which is also significantly faster than Atari Basic. There is Basic XL and Basic XE, both from Oss and thus essentially the same development team than Atari Basic. But no - none of these options fit your above check list. Atari Basic, TurboBasic and Basic++ do not have string arrays. Microsoft Basic does. None of them are compiled, though TurboBasic has a compiler, and there are multiple compilers available for Atari Basic and its variants (e.g. the ABC compiler). Recursive calling: Well, GOSUB is recursive, but none of the variants has argument parsing and local variables. Better graphics support you find in TurboBasic, sprite support you find in Basic XE and Basic XL.

[Daedalus2097]

Okay, thanks for the answers guys, that helps me get a better view of what's doable. Separate compilers aren't a problem - it's good to know they exist.

 

As for the recursive calling, I can always roll my own rudimentary stack system and use GOSUB, but it would have been nice to have a ready-to-go system. The main use case I was thinking of was AI routines - I'm sure I can make them well enough behaved to work within strict parameters.

 

I'll have a play with each of them and see how I get on. One more question: If I do end up putting something together, is there a main repository of Atari 8-bit software that people upload their homebrew stuff to?

 

Thanks!

[777ismyname]

Given your wants, Advan BASIC is the closest thing available. It has string arrays, excellent graphics commands (including PM movement in the VB, as well as DLI tools), a compiler (and an optimizing compiler), etc. It is *MUCH* faster than Atari BASIC, to the point old Atari BASIC games are silly fast. It is also considerably faster than TBXL and BASIC XL/XE. Fast Basic is my favorite. It is overall the fastest Atari BASIC flavor, though Advan trades even blows with it in many tests.

[777ismyname]

A couple or three download resources, amongst many:

https://atariwiki.org/wiki/Wiki.jsp?page=Basic

http://seriouscomputerist.atariverse.com/pages/language/language.basic.htm

http://www.atarimania.com/pgemainsoft.awp?type=U&system=8

[Daedalus2097]

Awesome, thanks for that!

[Ray Gillman]

Thanks this was an amazing link.
https://atariwiki.org/wiki/Wiki.jsp?page=Atari Basic Differences
 

Compares all the basics very nicely.  I noted that BasicXE has the string arrays but I believe is also limited to 256 chr strings?
TurboBasic has too many great commands to just pass on.  BLOAD, INKEY$, DO LOOPS, NAMED PROCEDURES, MANY DISK COMMANDS, PAUSE TIMER and more plus it's own compiler.

The strings are easy to create a routine to simulate an array with a huge string.  

The real attraction of BasicXE is the EXTEND command which gives more memory space to work with larger programs up to 100K with FRE(0) AND FRE(1)
That and passing parameters and local variables has some fun potential.

 

[dmsc]

Hi!

Quote

FastBasic is a great option but it doesn't have proper strings, it has procedures but not the type you're after.  Speed is great and it also has some better graphic support (with the writer improving them as we speak).

 

Why you say that FastBasic does not have proper strings? The only limitation is that strings are maximum 255 bytes of length, but it supports all string operations: extracting characters, extracting sub-strings (slicing), concatenation, LEN, VAL, ADR, and also supports string arrays.

 

Next version (I know, I should make a new release) will also support DATA string arrays, those allow storing big arrays of immutable strings efficiently (as DATA's use the least memory in the program).

 

About procedures, I'm planning to add named parameters to procedures, but it will increase the size of the IDE beyond 8kb.... so that would be for a new major version. Even then, I won't plan to support recursive calling with automatic stack parameters - our little 6502 is not built for that  , as the stack is really small.

 

Have Fun!

Edited November 23, 2019 by dmsc

[dmsc]

Hi!

Quote

Thanks this was an amazing link.
https://atariwiki.org/wiki/Wiki.jsp?page=Atari Basic Differences
 

Compares all the basics very nicely.  I noted that BasicXE has the string arrays but I believe is also limited to 256 chr strings?
TurboBasic has too many great commands to just pass on.  BLOAD, INKEY$, DO LOOPS, NAMED PROCEDURES, MANY DISK COMMANDS, PAUSE TIMER and more plus it's own compiler.

The strings are easy to create a routine to simulate an array with a huge string.  

Good table, I think but it needs adding more entries: AdvanBASIC, Altirra Basic, BASIC++, FastBasic.

 

Also, for TurboBasic XL, size on RAM is 5.5k, size on disk is 18k and number of variables is 256.

 

Have Fun!

Edited November 23, 2019 by dmsc

[Preppie]

2 hours ago, dmsc said:

 

Why you say that FastBasic does not have proper strings?

My apologies, I juest re-read the manual and it does support string elements.  I'm even more impressed now

Edited November 23, 2019 by Preppie

[Ray Gillman]

4 hours ago, Preppie said:

My apologies, I juest re-read the manual and it does support string elements.  I'm even more impressed now

When I say something is not proper I usually mean I encountered an error of some sort.  Sometimes it is as silly as I LIST some basic code out and ENTER load it into the others to see what works.  What is interesting is how the variable name MOD will LOAD into turbobasic and works but, if you ENTER it simulating typing it in - it throws an error through the interpreter and I wind up changing it to MMM$ or something to work around the name matching a keyword in Turbobasic that was not a keyword in Atari Basic.

 

[dmsc]

Hi!

22 minutes ago, Ray Gillman said:

When I say something is not proper I usually mean I encountered an error of some sort.  Sometimes it is as silly as I LIST some basic code out and ENTER load it into the others to see what works.  What is interesting is how the variable name MOD will LOAD into turbobasic and works but, if you ENTER it simulating typing it in - it throws an error through the interpreter and I wind up changing it to MMM$ or something to work around the name matching a keyword in Turbobasic that was not a keyword in Atari Basic.

This is a limitation in the way the TurboBasic XL parser works - as it is a modification of the original Atari BASIC parser.

 

The FastBasic parser do not have keywords as such, so you can use variable names that are the same as operator names; you can write very confusing code that way:

 

 

The output of that program is:

 

Have Fun!

 

[Preppie]

8 minutes ago, dmsc said:

The FastBasic parser do not have keywords as such, so you can use variable names that are the same as operator names

But not the same as statement names.

 

eg.  done=1

 

This will result in an 'unclosed loop' error as the parser assume the first 2 letters of the done variable is the start of a DO...LOOP statement.

 

This frustrated me a few times while using the IDE but the cross compiler brings up better error reports so it's much easier to spot.

 

[dmsc]

Hi!

28 minutes ago, Preppie said:

But not the same as statement names.

 

eg.  done=1

 

This will result in an 'unclosed loop' error as the parser assume the first 2 letters of the done variable is the start of a DO...LOOP statement.

 

This frustrated me a few times while using the IDE but the cross compiler brings up better error reports so it's much easier to spot.

Well, that is actually a bug plus a misfeature.

 

The parser is designed to allow for the "tenliner" code style, so omitting spaces is supported in all possible places. But, your example shows an actual bug due to the cleverness of the parser.

 

When it encounters the line "DONE=1" it starts by parsing the "D" and "O", so a "DO" statement is recognized, and a DO-LOOP is created in the loop stack. But then the parser expects an end of line, so it pull back and try to parse the line again. This time, it creates the variable "DONE" and parses an assignment statement. But (and here is the bug), the DO-LOOP is not pulled from the loop stack, producing the error you saw (and with no line number information, as the parser state was erased).

 

The above bug also happens with "REPEAT", "WEND", "LOOP" and "PROC", but those cases are not as common as the "DO". I added an explicit check for "DO" and "REPEAT", so this is fixed in current unreleased version, you can now have variables like "DONE" and "REPEATED", see the two byte fix at https://github.com/dmsc/fastbasic/commit/f2aa27435da4af77beab4bcbfbe2ec2938a4383c

 

Have Fun!

[777ismyname]

10 hours ago, Ray Gillman said:

When I say something is not proper I usually mean I encountered an error of some sort.  Sometimes it is as silly as I LIST some basic code out and ENTER load it into the others to see what works.  What is interesting is how the variable name MOD will LOAD into turbobasic and works but, if you ENTER it simulating typing it in - it throws an error through the interpreter and I wind up changing it to MMM$ or something to work around the name matching a keyword in Turbobasic that was not a keyword in Atari Basic.

 

Ray, if you haven’t already you should check out Altirra Extended BASIC. It is TBXL compatible and also includes a subset of BASIC XE stuff. It also includes an inbuilt help system by typing %H in immediate mode. 
 

EXTEND is a a cool mode. I’ve played around with it for years in emulation, putting multiple screens and flipping through them. Now that I *finally* have a machine with more than 64KB, I can’t wait to put it to use in the real world  If I could only find my cartridge  I did find the extensions disk a few days ago.

 

I will try to remember later on Sunday to post a small program I wrote in Fast Basic that shows off some of its string handling. dmsc has done an amazing job with Fast Basic. The only thing I have really missed using Fast Basic is the lack of use of the Break key. Then again, it has pushed me to save my work more often - which is a good thing. If we’d only had these awesome tools in the 80s  

[777ismyname]

@dmsc, we need a cartridge version of Fast Basic  That would be the incentive I need to buy an EPROM burner and get some cartridge shells.

[baktra]

I would put one extra variable to the equation. Shipping the final product to the "customers". How easy is to do it.

I don't have experience with all of BASICs mentioned above.

 

dmsc's FastBASIC has cross-compilation, you can ship .xex or .atr.

TBXL has AUTORUN capability, you can ship auto-booting .atr. TBXL source code is available, so you can adjust the startup experience. TBXL has a compiler too, however it doesn't compile every program.

 

My favorite would be dmsc's FastBASIC and its cross-compilation capability. It has potential for growth, is actively developed, and you can develop with all niceties provided by PC or Mac. It is using CC65/CA65 behind the scenes, so you might want to take a look at those too.

 

Edited November 24, 2019 by baktra

[Ray Gillman]

Is there a way to decompile a compiled CTB file to get the source code back?  I have come across some and wonder what is the best way to turn a small binary file into readable code without having to use an A65 interpreter - I'm going to wind up working more with ASM files than BAS I can just tell.  /SMH

[baktra]

5 hours ago, Ray Gillman said:

Is there a way to decompile a compiled CTB file to get the source code back?  I have come across some and wonder what is the best way to turn a small binary file into readable code without having to use an A65 interpreter - I'm going to wind up working more with ASM files than BAS I can just tell.  /SMH

I don't think so. The CTB files hold compiled machine code, so the information needed to get the source code back is lost.

[+DjayBee]

6 hours ago, Ray Gillman said:

Is there a way to decompile a compiled CTB file to get the source code back?  I have come across some and wonder what is the best way to turn a small binary file into readable code without having to use an A65 interpreter - I'm going to wind up working more with ASM files than BAS I can just tell.  /SMH

Look there for ABC- and TBXL-decompilers (as part of ABC Compiler & Decompiler.zip):

https://atariage.com/forums/topic/200885-need-info-about-the-abc-basic-compiler-from-monarch-data-systems/?do=findComment&comment=2957529

Edited November 25, 2019 by DjayBee

[Ray Gillman]

Anyone have experience working with TurboBasic 1.5 and 2.11?  The Ostrowski gem?  Is the upgrade to 2.11 worth giving up like 2,548 bytes of workspace?  (34,021 - 31,473)
---- update ----
I found this write up in German and translated it 

Hello, everybody,

have been asked to explain the different versions of Turbo-BASIC XL.

We can find them on the Atriki from our polish friends:
http://atariki.krap.pl/index.php/Turbo_BASIC_XL

used in: http://www.DeepL.com

following declaration:
"
A variant of the BASIC language for small Atari, which was developed in 1985 by the German programmer Frank Ostrowski and distributed by the magazine Happy Computer as a public domain program. There are two official versions:

Turbo-BASIC 1.4 - for 400/800 computers with min. 32 KB RAM. This version has a built-in DOS 2.0 - the interpreter is "glued" in the DOS.SYS file.
Turbo-BASIC XL 1.5 - for XL/XE computers. This version partially loads into the RAM under the ROM of the operating system, which gives the user program more memory (slightly more than 33k - manually ?). FRE(0) returns the result of 34021 bytes).

In addition, several unofficial changes have been made:

Turbo-BASIC XL 1.6 by Thomas Richter
Turbo-BASIC XL .... by Torsten Karwoth
Turbo-BASIC XL 2.0 - Hack Version 1.5 with modified title text, with "(c) 1990 LASER Software". Other differences unknown.
Turbo-BASIC XL 2.0 & Turbo 2000 System (also known as TT-Basic XL 2.11) - Change of version 1.5 by Jiří Richter, the Czech author of Turbo 2000, 1988. It contains an integrated Mini-DOS for the Turbo system and a handler for the T:.
Turbo BASIC 3.2q - Version 1.4 adapted for cooperation with SpartaDOS 3.2, by Tom Hunt from 1992. BPUT and BGET commands are missing, but can be replaced by corresponding XIO calls. The interpreter package contains a handler for operating P:R: Connection together with a program for loading this handler from the BASIC level.

Turbo BASIC is loaded from a hard disk or tape into the RAM of the computer. Interpreter has more instructions than the original Atari BASIC, there is also a Turbo BASIC XL compiler.

The main advantage of Turbo BASIC XL is its speed, the programs are executed three to five times faster than in the Atari BASIC interpreter, which is mainly due to the fact that Turbo BASIC has its own very fast floating point procedure package, which works well in most applications.

Another important advantage of the interpreter is the backward compatibility with Atari BASIC, so that almost all programs written in this package run under Turbo BASIC XL (with few exceptions).

It would be nice if the knowledge carriers among you could make additions if necessary. Especially for the version 1.6 by Thomas Richter and for the version by Torsten Karwoth, for which unfortunately all documents have been destroyed by water damage.

Translated with www.DeepL.com/Translator

Edited November 26, 2019 by Ray Gillman

[777ismyname]

There is a Turbo BASIC Extended version out and about, also. It adds a graphics PUT/GET stuff kind of like old MS-DOS GW BASIC, and a few other goodies. 

[dmsc]

Hi!

11 hours ago, Ray Gillman said:

Anyone have experience working with TurboBasic 1.5 and 2.11?  The Ostrowski gem?  Is the upgrade to 2.11 worth giving up like 2,548 bytes of workspace?  (34,021 - 31,473)
---- update ----

[long list deleted]

I did a little research long time ago, and all the versions >1.5 are really only hacks over the original one, with new bugs.

 

If you want to add functionality to TurboBasic XL you can start with my disassembled and commented sources, at https://github.com/dmsc/turbo-dis , that source has some optional enhancements:

 

- Allows setting the load-address to any page instead of the default $2080, to produce versions for smaller or bigger DOS, and to gain 128 bytes more free ram.

- Fixes two small bugs in the interpreter: parsing of long lines after IF and handling of run-time FOR stack when deleting lines.

- Moves some code around to give a few bytes more RAM.

 

Adding new syntax is not difficult, but you have to grow the low-ram section, reducing the memory available to programs.

 

I don't plan to add more to that source because I think it is better to contribute to the excellent Altirra Extended Basic: fully open-source and not based on Atari BASIC; and I started writing FastBasic that is faster and smaller than TurboBasicXL

 

Have Fun!

[Ray Gillman]

On 11/25/2019 at 6:37 AM, DjayBee said:

Look there for ABC- and TBXL-decompilers (as part of ABC Compiler & Decompiler.zip):

https://atariage.com/forums/topic/200885-need-info-about-the-abc-basic-compiler-from-monarch-data-systems/?do=findComment&comment=2957529

Yes I know I have seen one before and the downside was, it uses generic variables like X Y Z A B C rather than meaningful variables.  Thanks!

Edited December 15, 2019 by Ray Gillman