Created English translation of the Extended Turbo Basic (Turex.com) documentation

[Brad Nelson]

Thanks, Mr. Fish. And by pure coincidence, I just ran across that program on the FastBasic main disk (Fedora.com). It came in at 42 minutes and 33 seconds on the Atari800WinPlus emulator. You had mentioned FastBasic in the first page of this thread so I took a look.

[Brad Nelson]

A fun thing about it is I've read that Ostrowski wrote it in TB, and then had it compile itself, to produce the executable we use to compile programs!

 

 

Mark, considering the computational metaphysics of that could be enough to fry the M5 Unit.

 

 

I know there is a little documentation on these matters on a wiki somewhere (I haven't been able to find it since), but it's not complete.

 

 

By coincidence, I ran across that today. It had, I think, three entrees, I can't find it again either.

 

[Geister]

12 hours ago, MrFish said:

There was a whole thread about it here, with all different kinds of optimizations and languages used (and for different machines).

 

Graphics 8 Fedora Hat

 

I have seen that thread in the past and as I stated then, I'm not looking for optimizations of the code as the idea is to test the languages and floating point systems for each computer and language.  Optimizations would be like modifying a prime number program by pre-calculating all primes and putting them in a table to print at runtime.  Sure it would be fast, but what does it tell you about the computer?  Nothing!

The idea is to compare the capability of a group of computers from the same era.  Maybe it's for bragging rights, maybe it's curiosity, but that's what I was going for. 

 

I also don't want to compare apples and oranges.  Run the code on a PC in Altirra in fast mode or in C# on an I9 CPU?  I already know it will be faster.  Probably blindingly so.  

 

The real test for me is to find the best out of a group of contemporary machines using the tools available at the time.  Or even the tools available now.  The thing that caught my attention was the mention that several people were trying to convert the code to run on a TI.  I was given to understand that even Extended Basic on the TI couldn't plot and draw screen graphics like this program does.  Maybe I was misled.  I'll have to go through the thread again.

[Brad Nelson]

In an earlier post on this thread, Mark had a conversation with Mr. Fish about his use of programs/tools. Mr. Fish mentioned FastBasic, a BASIC I'd never really scratched the surface of. But it looks interesting. And it certainly is indeed fast and I gave myself an introduction to it last night.

 

Earlier in this thread, I had posted a simple "Speed Test" program that I had found somewhere. It's very basic. I was getting times of around 2.5 seconds in Turbo-BASIC XL and 4 seconds in Basic XE. I re-wrote it for FastBasic and got a time of 30 jiffies. That is indeed fast BASIC.

 

I've freely note that I'm a dabbler and not the advanced programmer that many of you are. But I suppose there is room for all skill levels when talking retro computing. It was an interesting immersion into FastBasic without the use of "gotos" and "gosubs." (I'm still suffering withdrawal symptoms.) I know as well as anyone how that can lead to spaghetti programming. But it was really my first experience at a more "structured" approach. There are, I would say, benefits to each. Not that I need that kind of speed for anything I do. But certainly learning new programming techniques is well worth it if you do.

 

For now (mostly), Turbo-BASIC XL does a marvelous job. Still, I was amazed how simple it was in FastBasic to make a completely self-contained "XEX" file that could be run by anyone. Nice feature.

[markmiller]

@Brad Nelson - Re. using goto's gosub's

 

An interesting thing I saw with TB is it's possible to write a whole program without using Goto or Gosub. The way it allows you to do branching is fairly similar to how modern languages have been doing it, using constructs like for-next, while loops, etc., and branching to labels and procedures.

 

The reason the old 8-bit Basics had line numbers was because of the way the screen editor worked. It only knew about the line of code where you pressed the Return key. It wouldn't know where the line was supposed to go relative to your other code. The interpreter would figure this out from the line number used with it. FastBasic doesn't need line numbers, since it uses structured programming, and a full-screen editor. Code is sequenced by the editor, not the interpreter. TB uses the old style of screen editing. So, even though the language is structured such that it doesn't need line numbers, it still uses them, due to the way code is given to it.

[markmiller]

Speaking of FastBasic, I've tried to make sense of the AtariWiki page on it.

 

FastBasic - AtariWiki

 

It tries to distinguish FB from Atari Basic in how they operate, and I'm able to see that a little, but its description is confusing. The way I'm reading it is while FB and AB both tokenize their code, AB does it "one line at a time," while FB "tokenizes each line, but keeps it in memory. This takes up more memory, but it executes faster this way." (I'm summarizing.) It seems to say that once AB executes a line of tokenized code, it throws it away. This is not true! Besides that, I'm thinking, "What's the difference between them? AB also tokenizes everything, and keeps it all in memory."

 

If I had to guess, it seems what it's actually describing is that FB first translates the code you enter into tokens, and then JIT-compiles the tokenized code to machine code, as the program runs, because it says something about translating to machine code during a run. If this is true, the way I make sense out of the rest is that it caches frequently used machine code, not tokenized code, so it doesn't have to be recompiled. Do I have this right? It sounds like a modern VM (like for Java and .Net). Maybe that's the point.

[Brad Nelson]

Quote

The reason the old 8-bit Basics had line numbers was because of the way the screen editor worked. It only knew about the line of code where you pressed the Return key. It wouldn't know where the line was supposed to go relative to your other code.

 

Thanks for the explanation, Mark. So much of what we use and enjoy are legacies passed down to us. And perhaps some of this stuff has outlived its usefulness. But given the subject of "retro," that aspect might not apply. Perhaps"outdated" could even be considered a plus.

 

I should mentioned I've done my share of scripting in HyperCard which has no line numbers and most things are function-based (of a sort). I forgot about that. I wrote an entire suite of "stacks" to manage my business. I still use them today (via an emulator).

 

So it's not as if you have to drag me kicking and screaming to the (at least) 1990's. But beyond mere skill level, there is just a different compositional mindset when one has line numbers (and gotos and gosubs) as opposed to everything being procedure-based. I intend to try to take a few short TBX programs and translate to FastBasic just as an exercise in learning procedure-based programming (while fully acknowledging that I can do that all right now in TBX, but it's too easy to cheat if one has line numbers at one's disposal).

 

But it should be pointed out that you can pretty much use (from what I can see) FastBasic as you would Turbo-BASIC XL (for shorter stuff, anyway). You just have to structure it so that there is no need to jump around willy-nilly with gotos and gosubs.

 

I've read some other threads around here. And many like to use Visual Studio for non-line-number-based programming. (I'm sure there's a proper word for that. I just don't know it.) I've used that to gain an introduction to Python. But I do make extensive use of Notepad++ for longer projects in BASIC. I need to school myself in better use of Notepad ++ because I've seen that there are some plug-in one can use to automate certain things. It would be nice if you could open a "listed" BASIC program and automatically remove the line numbers. If that feature is already there, then egg-on-face. But let me know.

[Brad Nelson]

Quote

because it says something about translating to machine code during a run. If this is true, the way I make sense out of the rest is that it caches frequently used machine code, not tokenized code, so it doesn't have to be recompiled. Do I have this right?

Mark, when running a "speed test" program on FastBasic, I noted that the "Ctr+R" (that is, "Run") result from within FastBasic was exactly as fast as the "Ctr+W" (that is, compiled) XEX file run complete outside of FastBasic. That is, "running" the code in FastBasic is the same speed (for this small program, anyway) as the XEX one compiled (and saved) with another step. If I'm reading that right, that does sound as if FastBasic is "translating to machine code during a run." I can't draw any technical conclusions. But that is the behavior I've seen.

Edited November 4, 2023 by Brad Nelson

[+MrFish]

On 11/2/2023 at 12:18 PM, Brad Nelson said:

integrating it tighter into TB would to nice

In what way?

 

[dmsc]

Hi!

22 hours ago, markmiller said:

Speaking of FastBasic, I've tried to make sense of the AtariWiki page on it.

 

FastBasic - AtariWiki

 

It tries to distinguish FB from Atari Basic in how they operate, and I'm able to see that a little, but its description is confusing. The way I'm reading it is while FB and AB both tokenize their code, AB does it "one line at a time," while FB "tokenizes each line, but keeps it in memory. This takes up more memory, but it executes faster this way." (I'm summarizing.) It seems to say that once AB executes a line of tokenized code, it throws it away. This is not true! Besides that, I'm thinking, "What's the difference between them? AB also tokenizes everything, and keeps it all in memory."

 

If I had to guess, it seems what it's actually describing is that FB first translates the code you enter into tokens, and then JIT-compiles the tokenized code to machine code, as the program runs, because it says something about translating to machine code during a run. If this is true, the way I make sense out of the rest is that it caches frequently used machine code, not tokenized code, so it doesn't have to be recompiled. Do I have this right? It sounds like a modern VM (like for Java and .Net). Maybe that's the point.

 

What FastBasic does it compiling your full program from text into a bytecode, this is executed in a small interpreter. This is similar to other interpreted programming languages today - think Java, Python or Lua. But it does not use any JIT compiling, the interpreter is just as fast as possible.

 

What makes this approach faster than traditional BASIC interpreters is that the bytecode already encodes the execution flow of the program, so the interpreter does not need to "search variable" or "search a line number", etc.

For example, if you typed " A = 1 + 2 * PEEK(123 + X) ", FastBasic translates this into: "LOAD X ; PUSH ; LOAD #123 ; ADD ; PEEK ; PUSH ; LOAD #2 ; MULT ; PUSH;  LOAD #1 ; ADD ; STORE A " - this is similar to a Forth program.

 

The reason FastBasic does not compile directly to assembler is that the 6502 is an 8 bit processor, and FastBasic uses 16 bit variables, so almost all operations need multiple assembly instructions to execute - this makes the assembly code very large, and one of the goals of FastBasic is to be as small as possible.

 

Also, on floating point benchmarks FastBasic is slow - this is because it uses the Atari math pack in ROM that is very slow. You can accelerate it a lot by replacing it with a newer mathpack, for example the Altirra mathpack. 

 

Have Fun!

 

[markmiller]

2 hours ago, MrFish said:

On 11/2/2023 at 10:18 AM, Brad Nelson said:

integrating it tighter into TB would to nice

In what way?

Not saying Brad has had experience with Action!, but I'm thinking he's saying "Like the way Action! works," since you can get to the compiler easily from the Monitor, execute your program, and then get back to the editor, all from within the Action! environment. You have to jump through some hoops to get to the TB compiler, then the linker (if you want), and then you have to reboot to get back to the interpreter. I believe he's saying it would be nice if those pieces had a "flow" to them, so if you want to compile your program from the interpreter, there's an easy process for doing that.

 

Mac/65 has the same feel to it. You can edit, assemble, and debug all within one package. You don't have to go to DOS to load the different parts.

 

I say, though, "What do you expect from a type-in program?"  TB does an excellent job for that.

 

If TB were an all-in-one package, like Action!, there wouldn't be much memory left for programming, assuming extended memory wasn't used.

 

Thinking through it, I can see why Action! chose the monitor structure for getting around the system, rather than sticking options into each part of it to get to the other parts. The monitor approach allows more control for the programmer. You could still have the parts loaded from disk each time they're used (I think that's more realistic).

[markmiller]

@dmsc - Very interesting reading how FastBasic structures things. At one point, I was working on porting a stack machine I'd seen written in Java to TB, and I had the thought that at some point, I'd like to get it written in assembly, so it would run as fast as possible. Reading that the approach FB takes is faster in some ways than the traditional Basic interpreter is encouraging, since I thought once I got the stack machine in assembly, I'd like to write a language using it!

[+MrFish]

1 hour ago, markmiller said:

Not saying Brad has had experience with Action!, but I'm thinking he's saying "Like the way Action! works," since you can get to the compiler easily from the Monitor, execute your program, and then get back to the editor, all from within the Action! environment. You have to jump through some hoops to get to the TB compiler, then the linker (if you want), and then you have to reboot to get back to the interpreter. I believe he's saying it would be nice if those pieces had a "flow" to them, so if you want to compile your program from the interpreter, there's an easy process for doing that.

 

Mac/65 has the same feel to it. You can edit, assemble, and debug all within one package. You don't have to go to DOS to load the different parts.

I see what you're saying; but, neither Action nor Mac/65 are interpreted languages. So, with TBXL, it's more than just an editor you're returning to. I suppose some kind of monitor for TBXL might be helpful. I was always running DOS off of a RAMDisk; so, jumping into DOS (or whatever else I put on the RAMDisk) was instant.

 

The compiler or runtime can be run directly from the interpreter, though; you just can't get directly back into the interpreter after running either of those.

 

BTW, I'm pretty sure the linker was created by someone other than Frank, some years after his interpreter and compiler/runtime system was out. So, any concerns regarding the user friendliness shouldn't be aimed at Frank or TBXL as a system/concept. It is a useful addition, though.

 

[Brad Nelson]

In what way?

 

Mr. Fish, I was just messing around with FastBasic yesterday. A simple "Control+W" will allow you to save your program to XEX format.

 

With TBX, there's some disk swapping involved. You have to leave the main program and boot a separate program. Etc. You need to remember to include the RUNTIME file and rename things so that they auto-boot. And when you do finally create a compiled program, it seems like there's just a 75% chance that it will run. The process is just all very convoluted. FastBasic does it in a way I would call easy and integrated. Hit a key combination. Boom. You have an EXE file.

Edited November 5, 2023 by Brad Nelson

[Brad Nelson]

You can accelerate it a lot by replacing it with a newer mathpack, for example the Altirra mathpack. 

 

DMSC, I had run into that same recommendation elsewhere online. But there were no instructions on how to do it. If it's not too time-consuming, could you or someone else list the instructions for that? Thanks in advance. And note that I'm not using the FastBasic Windows app. I'm just running it off an ATR disk. I suppose swapping math packages involves, at the very least, using the FastBasic app for Windows. But I'm not sure. If it involves using the FastBasic Windows app, I probably won't be trying that app for a while, so don't bother if that's the case.

Edited November 5, 2023 by Brad Nelson

[Brad Nelson]

Reading that the approach FB takes is faster in some ways than the traditional Basic interpreter is encouraging, since I thought once I got the stack machine in assembly, I'd like to write a language using it

 

And I volunteer to design the logo and packaging for that, Mark.

 

I haven't done much with FastBasic, but it does seem to be pretty fast. Someone (on this thread or another) linked to a BASIC 10-Liner site. (By the way...this stuff is brilliant. And whoever wrote Patrol – based on Moon Patrol – is a genius.)

 

It looked like he had used Turbo-BASIC XL for most of it and FastBasic for a few others. The Patrol program was written in FastBasic. The insight to gain from this: Those are two very capable program...especially in the right hands.

Edited November 5, 2023 by Brad Nelson

[Brad Nelson]

The compiler or runtime can be run directly from the interpreter, though; you just can't get directly back into the interpreter after running either of those.

 

MrFish. The following is from the manual for Turbo-BASIC XL. I wasn't aware there was a way to do some of this from within the interpreter of TBXL. If there is, that would be cool.

 

-----

 

To begin, insert the Turbo-BASIC XL Compiler disk into your drive and turn your computer on. When it has finished loading you will be in Turbo-BASIC XL. Type DOS to get to the DOS 2.5 menu. Choose DOS Option 'L', Load Binary File and load the file COMPILER.COM. After a short while, you will see a screen full of German. If you do not read German, do not worry, that is what this article is for! At any time that you are on this screen, you may reboot your system by hitting Control-R or you may return to DOS by hitting Control-D. You will be asked if you really want to do this. If you do, don't forget to 'J' for Ja and not 'Y' for Yes!!

 

To compile your programs, remove the Turbo-BASIC XL Compiler disk from the drive and insert the disk with the program you want to compile. (If you have two drives, insert your disk with the program to compile in Drive 2 and the blank DOS disk in Drive 1.) Press the number 1 key (Number 2 if you have two drives). A complete listing of all the files on that drive will appear on the screen with one highlighted in inverse video. Using the arrow keys, highlight the file you want to compile and hit Return. That's all there is to it! At the top of the screen, you will see the line numbers fly by as the program is compiled. When it is finished, you will be prompted for a file name to save your compiled program under. It has to have an extender of CTB (for Compiled Turbo Basic). The program will not let you use any other extender. At this time, if you have one drive, you should remove your disk with your original program on it and replace it with your blank DOS disk. If you want your compiled program to be an AUTORUN file, you should name it AUTORUN.CTB. Then the file will automatically load and run at bootup time.

 

There is one more step that you must do to get a completely runnable compiled program. Go back to DOS and copy the file RUNTIME.COM from the Turbo-BASIC XL Compiler disk to the disk with your compiled program on it. Rename the RUNTIME.COM file to the name AUTORUN.SYS. Your disk is now ready to go. The Turbo-BASIC XL Compiler does not compile to runnable code, you must run the RUNTIME.COM file to run your compiled program.

[+MrFish]

25 minutes ago, Brad Nelson said:

I wasn't aware there was a way to do some of this from within the interpreter of TBXL. If there is, that would be cool.

Yeah, you can just use the BRUN command from the interpreter to start either the compiler or the runtime.

 

[+MrFish]

1 hour ago, Brad Nelson said:

With TBX, there's some disk swapping involved. You have to leave the main program and boot a separate program. Etc.

You don't have to swap disks if you keep the compiler and runtime on the same disk with the TBXL interpreter.

 

1 hour ago, Brad Nelson said:

You need to remember to include the RUNTIME file and rename things so that they auto-boot.

Renaming the runtime is only necessary if you want to make an autobooting disk for your program. If you just want to run your program to test it, you simply BRUN the runtime and then supply the name of your compiled TBXL program at the command prompt for loading.

 

1 hour ago, Brad Nelson said:

And when you do finally create a compiled program, it seems like there's just a 75% chance that it will run.

Where did you get the idea there's a 75% chance your program will run? There are generally a few situations that will cause problems. By and large, most programs will run, and the few programs that don't can usually be remedied pretty easily.

 

1 hour ago, Brad Nelson said:

FastBasic does it in a way I would call easy and integrated. Hit a key combination. Boom. You have an EXE file.

I'm not trying to convince anyone not to use FastBASIC. It was created as an evolution of BASIC's from the past -- such as TBXL. I'm merely trying to clear up some misconceptions about using TBXL.

 

[+MrFish]

Another thing people might not know: there is a version of DOS 2.5 that has been modified to include a menu item for returning from DOS directly back to your TBXL program in the interpreter. Using this in conjunction with the MEM.SAV option of DOS 2.5 will preserve any code that you'd been working on; so there's no need to reload the interpreter and reload your program if you need to use DOS and want to return to TBXL and your program.

 

Both copies of TBXL on my website (NTSC & PAL) include this verison of DOS 2.5 on the disks. These disks also have the compiler, runtime, and linker included.

 

[markmiller]

3 hours ago, MrFish said:

The compiler or runtime can be run directly from the interpreter, though; you just can't get directly back into the interpreter after running either of those.

Oh...right. You can BRUN the compiler, or RUNTIME.EXE. Slipped my mind.

 

Yes, once you run the compiler, it gives you the option to (R)eboot (which would return you to the interpreter, but you'd have to reload any code you were working on), or quit to (D)OS.

 

Interestingly, I see you can run RUNTIME.EXE with no compiled file set up to autorun. It just gives you an error, and displays its menu: (D)os, (R)un, or (L)oad. From there, you can get to DOS, or Load a compiled .CTB file, which it will then run. If you press the Break key while running, it'll give you the same menu. If you hit Run after that, it will re-run your program. But yeah, it doesn't give you a way back to the interpreter.

 

My thinking on that is the runtime is really meant for distributing your compiled program. You're not packing TB with it. So, no point in offering a reboot option. Though, it would be nice to have that if you're testing, especially since the mapping between the interpreter and the compiler is so unreliable.

 

Now that I look at it more closely, I see the linker is using the TB runtime. Once you run it, it gives you two options, to either link another file, or press Esc to exit. If you exit, it goes to the TB runtime menu: (D)os, (L)oad, or (R)un. If you hit Run, it re-runs the linker.

 

I noticed you can't BRUN the linker (my emulator crashes if I try that).

[Brad Nelson]

Thanks, MrFish. That saves some steps. And I think someone (Us? Me? Mark? Whomever?) needs to take up the task of updating, expanding, and revising the TBXL manual.

 

One quirk of BRUN-ning "RUNTIME.COM" is that it won't work on anything but the "D1:" drive. That seems hard-wired. Let me know if you or anyone else has found a workaround for this. This would facilitate not having to swap disks and to, for instance, just being able to run it from the "H:" drive...or the "D2:" drive, for that matter.

[markmiller]

46 minutes ago, MrFish said:

You don't have to swap disks if you keep the compiler and runtime on the same disk with the TBXL interpreter.

Agree. The image I got from AtariWiki is like this. It has TBXL as AUTORUN.SYS, along with the DOS files, and RAMDISK.COM (so DUP.SYS and MEM.SAV end up on D8:), and COMPILER.EXE, and LINKER.EXE, plus two runtime files (one for dynamic, and one for static linking).

 

So, I boot with this disk, and put my program disk in D2:. I like doing it that way, because I frequently have multiple versions of the same program on disk, and I'd run out of disk space quickly if I did everything on the TB disk.

[Brad Nelson]

Another thing people might not know: there is a version of DOS 2.5 that has been modified to include a menu item for returning from DOS directly back to your TBXL program in the interpreter.

 

Wow. That is really nifty, MrFish. A real time-saver. It would also be nice if, having BRUN "RUNTIME.EXE" to launch a program, the "Return to TBXL" menu in DOS would return you to the TBXL interpreter instead of whatever compiled program you had just run via BRUN-ning RUNTIME. That may not be technically feasible but just wondered.

[markmiller]

On 11/1/2023 at 10:09 PM, Brad Nelson said:

I wanted to double-check. Indeed, Basic XE no longer allows the "Fast" command. XL does.  Ironically, it seems that XE still needs it.

Like with Microsoft Basic II, Basic XE has an extension disk that you boot with the cartridge. You don't have to have it to run Basic XE, but you lose some capabilities.

 

I checked the manual, and the FAST command is on the extension disk.

 

It says:

 

Quote

You can boot without the extensions disk if you want. One of two things will happen, depending upon whether the disk you boot with has the extensions file on it (instructions for copying the extensions disk and file are below).

 

If the boot disk does not have the extensions file on it, or if you boot without a drive, you can still use BASIC XE. However, the following will not he available:

 

BSAVE, CALL, DEL, EXIT, FAST, LOCAL, LVAR, MOVE, PROCEDURE, RENUM, RGET, RPUT, SORTUP, SORTDOWN, the fast math routines, and all P/M commands except HITCLR.