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

[Brad Nelson]

Quote

You could then be in Basic, and type EN."D:DIR"

 

Very nice. In this case, I type RUN "H:CAT (No need for the trailing quote). It's fairly succinct and easy to do. So I guess that hearkens back to the proverbial "Back in the day." The CAT2 program I attached runs in both Atari Basic and Turbo-BASIC XL. The difference is that Atari Basic will choke on TB's "input" syntax but not vice versa. 

 

Quote

It really feels like TB takes some steps toward what Atari Basic should've been.

 

I agree. On a related point, I find that programming is a humbling thing. It gives you a taste of "The more you know, the more you know you don't know." Even in these "simple" languages, there is a lot of depth.

 

Somebody wrote TB and in a time when the market for such a thing was probably small and crowded by other languages. I have to believe this kind of stuff was a labor of love. Considering that Wiki lists it as, "...was developed by Frank Ostrowski and published in the December 1985 issue of German computer magazine Happy Computer," that had to be so.

 

Of course, at least some of these efforts could have also worked as padding one's resume as a programming when out looking for a job. And that's certainly a win-win situation. I've tried several of the other BASICs. All have their good point. But TB is just so straightforward and easy. It doesn't hurt that it is (I believe) completely compatible with any Atari Basic program you might want to run. It's a little late in the day, but it would have been nice to have a more in-depth TB manual. Looking through that manual now, having things such as "CLS" and "RENUM" make TB a pleasure to work with.

 

Yes, an interesting story on Atari Basic. As you certainly know, TB is supposedly fast in large part because they did a proper (and faster) implementation of the floating-point library.

 

Quote

It vacuums up content on the internet, and uses a probability model to arrange it in a mostly sensible manner. Factual correctness is not its thing.

 

"Vacuums up." Couldn't have said it better. I'm not a particular fan-boy of A.I. But I like to keep up on what's going on. This A.I. stuff will no doubt get better and is quite usable for certain tasks now. But if you're willing to work within the limitations, I find it can help you to an answer when a Google or DuckDuckGo search goes cold. But it's often a pretty hilarious process.

[+Philsan]

On 11/1/2023 at 5:57 AM, markmiller said:

Some issue of Compute! Magazine had "scripts" you could run (immediate mode code) in Atari Basic that would do some DOS functions, like get a disk directory. I used to use these a lot. It turned out they were pretty easy to implement. All of the code for each function fit on a single line. As I remember, you entered the code in DOS, using the Copy function (from E: to D:). The code was entered as text, and saved to a file, like "DIR". You could then be in Basic, and type

EN."D:DIR"

This would ENTER the one line of code from disk, and run it on the spot, giving your disk directory (though, you had to hardcode the drive number it would access. Since I had one disk drive, anyway, this was fine).

 

The structure of these "scripts" was: open a channel, call an XIO function on it, and then close the channel. Maybe some of them DIMensioned a variable, and had an INPUT statement to get some parameter(s) for, say, deleting a file, or renaming a file, which would be passed to the XIO call. I forget.

 

We talked about it in a thread.

Here is my post with three similar solutions: https://forums.atariage.com/topic/304678-basic-command-for-disk-directory/?do=findComment&comment=4500196

 

 

[Brad Nelson]

Thanks, Philsan. Those are interesting programs.

[markmiller]

8 hours ago, Brad Nelson said:

"...was developed by Frank Ostrowski and published in the December 1985 issue of German computer magazine Happy Computer,"

That was the remarkable thing about it, that the whole thing, including the compiler, was published in a computer magazine, and, at least for the interpreter, was written with such skill, being 100% compatible with Atari Basic, while making additions, and optional bug fixes.

 

I first encountered TB programs around 1989/90, after I bought my 130XE, and a modem, since I got these programs off of BBSes. They'd come as boot disks (so, they were probably .DCM (Disk Commander) images), which I'd have to decompress onto a blank disk. I'd boot them up, and up would come the "Happy Computer - Turbo Basic" splash screen, and then the program would come up. I didn't start working with TB until probably a couple years ago, once I looked at some benchmark tests comparing its speed to other versions, like Atari Basic, Basic XL/XE, etc.

 

The thing that really surprised me, once I started looking at the mechanics of most Basics (this was about a year ago), is that the way a typical Basic interpreter handles branching, whether GOTO, FOR-NEXT, or GOSUB, is by starting at the beginning of the program's code, and doing a linear search through it for the target! From what I've found, this was true regardless of what computer it was implemented on. It was just how it was done. So, the general recommendation was if you had a loop you wanted to execute quickly, put it at the top of your program listing. (I didn't know about this when I was younger.)

 

TB optimizes branching somehow. I read that Basic XE has an optimization (I think when you use a command called FAST) where it can use hard addresses for branch points, thereby eliminating the search.

 

I didn't know this until I started using TB, that Ostrowski also wrote GFA Basic for the Atari ST, which was a kind of godsend, because ST Basic, distributed by Atari with many new STs, was awful, from what I've read. It was a really buggy port of DR-Basic, from Digital Research. Doing a little research on this history, I see that Atari fixed some of the bugs in later versions of ST Basic, but by then people had ditched it, and bought something like GFA, or STOS.

 

Funny thing was when I bought my Mega STe in 1992, it didn't come with ST Basic. I remember looking for it. All I got with it were some system utilities.

[+MrFish]

25 minutes ago, markmiller said:

being 100% compatible with Atari Basic, while making additions

And provides 1,747 more bytes of RAM than Atari BASIC.

 

[Brad Nelson]

I read that Basic XE has an optimization (I think when you use a command called FAST) where it can use hard addresses for branch points, thereby eliminating the search.

 

I think you've summarized that rather well. And if I recall correctly, Basic XE had that "fast"ness built in whereas you needed to use that command explicitly in Basic XL. I've played around in Basic XE a bit and I think the reason we possibly don't hear more about it (it looks to be a great program) is that it came out at the same time as Turbo-BASIC XL. TB was free. XE was $79.95. Here's a bit from the AtariWiki page on Basic XE:

 

OSS released Basic XL in 1984, adding many new features as well as the FAST command. FAST cached line numbers that were the target of jumps (GOTO and FOR/NEXT loops), addressing one of the two major reasons for the notoriously slow performance of Atari BASIC. The main addition to Basic XE, compared to Basic XL, was a solution to the other big problem in Atari BASIC, the low-performance math code.

 

The Wiki page on Turbo-BASIC XL has a bit more to say about the nitty-gritty of the reasons for the slow-down. I can't say I understand the half of it. But the bottom line is, they made it faster!

 

I don't know when I ran across TB. But certainly its speed benefits and extended command set made it attractive. And like I said, I'm more of a dabbler. When I try to mess with Action! or Fast Basic I just hit the bad side of a learning curve. I can't just get up and go. These programs (certainly with good reason for the expert program) have been "structured" and "refined" into a not-too-comfortable pair of shoes for the casual (or even intermediate) user.

 

TB walks a nice line. If you really want to do programming that is a little more structured, you can. If you just want to hash something else, the program does not get in your way. I like that.

[markmiller]

1 hour ago, MrFish said:

And provides 1,747 more bytes of RAM than Atari BASIC.

 

I've heard this is because it turns off the OS ROM, and loads itself in lower memory. So, it also has its own OS.

[Brad Nelson]

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

 

I used a simple program (don't remember where I found this) that does timing (Enter D1:, etc., to run it). I got 4.18 seconds in XL (without "Fast") and 3.78 seconds with "Fast." In Basic XE, the time was 7.04 seconds. This was all done in the same Altirra emulator. Why would a newer version be slower? I have no idea.

 

Also, I was whining earlier about the TB manual. But I forget there is a fairly good succinct one called Turbo Basic : Turbo Compiler put out by the Western New York Atari User Group.

SPDTST.LST

Edited November 2, 2023 by Brad Nelson

[markmiller]

35 minutes ago, Brad Nelson said:

The Wiki page on Turbo-BASIC XL has a bit more to say about the nitty-gritty of the reasons for the slow-down. I can't say I understand the half of it. But the bottom line is, they made it faster!

I take it the terms that seem confusing are the following:

 

Binary Coded Decimal (BCD) is a method of encoding numeric information that's pretty simple. Though, it requires an understanding of binary. Maybe that's beyond what you want to think about right now.

 

Anyway, a number like 19 in binary is 00010011.

 

In BCD, each digit of the decimal number is encoded in a 4-bit section of a byte, in its decimal place. So, 19 in BCD is 00011001, (reading from left to right, 0001 (binary) = 1 (decimal), 1001 (binary)= 9 (decimal)).

 

The way I interpret the term "unrolling" is it's an optimization technique typically called "inlining," where rather than executing a loop for a number of times, you literally repeat the code the necessary number of times to accomplish the task. Modern compilers do this optimization automatically, so the programmer doesn't have to think about it.

 

This is a bad illustration of "unrolling a loop," since you wouldn't optimize this specific code this way, but it follows the concept.

 

Instead of doing:

FOR I=1 TO 3:A=A+1:NEXT I

you do:

A=A+1
A=A+1
A=A+1

Each machine instruction takes a certain amount of time to execute, depending on the instruction. If you were to look in a manual for the 6502 processor, you would see clock ratings for each machine instruction, showing how much time it takes to execute.

 

In machine code, the basic logic in the second block of code takes up more memory than the loop, but the idea is you've taken out the cost to the CPU of executing the branch to carry out the loop (making the computer go back to previously executed code), and you've accomplished the same result. The article said Ostrowski did this with "small loops." So, the memory cost is not large, but what was probably going on is these small loops were being run many times to carry out one arithmetic function, like square root. The idea being "this small cost adds up." So, by eliminating it, you make the function run noticeably faster.

[+MrFish]

1 hour ago, markmiller said:

I've heard this is because it turns off the OS ROM, and loads itself in lower memory. So, it also has its own OS.

It actually just hides part of the interpreter in RAM that's under the OS ROM; but the OS ROM isn't deactivated; it's still the active OS. You basically end up getting all those extra functions it provides for free, in terms of available RAM -- and even some bonus RAM to boot.

 

Here's the memory map compared with Atari BASIC's memory map.

 

 

[markmiller]

@MrFish - Thanks. Looking at the memory map, I was wrong about "lower memory," as well. It actually resides in higher memory, "beneath" the OS.

 

Interesting. I was talking with a C-64 programmer about this a while back, and he said you could do the same thing with the 64's Kernal ROM. You could use its address space without turning it off. He talked about what I'd call "two-phase" memory access. I can't remember exactly what he said, something about "high" accesses the Kernal ROM, and "low" accesses the "RAM underneath." It looks like you can do the same thing with the Atari OS.

 

Just curious, anyone know how you set that up?

Edited November 2, 2023 by markmiller

[danwinslow]

Bit 0 of PORTB ( $D301 ) toggles the OS between ROM (the OS) and RAM (whatever gets put there).

[baktra]

2 hours ago, markmiller said:

@MrFish - Thanks. Looking at the memory map, I was wrong about "lower memory," as well. It actually resides in higher memory, "beneath" the OS.

 

Interesting. I was talking with a C-64 programmer about this a while back, and he said you could do the same thing with the 64's Kernal ROM. You could use its address space without turning it off. He talked about what I'd call "two-phase" memory access. I can't remember exactly what he said, something about "high" accesses the Kernal ROM, and "low" accesses the "RAM underneath." It looks like you can do the same thing with the Atari OS.

 

Just curious, anyone know how you set that up?

As far as I know, with C64, one could write to the RAM under ROM without switching the ROM off, because writes made it "through". For reading, the ROM had to be switched Off by commanding the MMU to do so.

[pirx]

On 11/1/2023 at 12:57 AM, markmiller said:

Re. ChatGPT

[...] It doesn't care about the content. It vacuums up content on the internet, and uses a probability model to arrange it [...]

just like us, just like us...

[Brad Nelson]

Quote

In BCD, each digit of the decimal number is encoded in a 4-bit section of a byte, in its decimal place. So, 19 in BCD is 00011001, (reading from left to right, 0001 (binary) = 1 (decimal), 1001 (binary)= 9 (decimal)).

 

Thanks, Mark. I'm familiar with binary but that's the first clear explanation of BCD that I've read. And I did read some of the Wiki page as well.

 

I understand the concept of optimizing code and certainly that some techniques take more processor cycles, and/or are more efficient, etc. Learning some facts about this can be very useful. And I understand that optimization is especially important in the more bare-bones 8-bit computers (and a fun challenge as well) and less so in modern computers that have gigabytes of memory and enormous processor power. And there is ample bloatware out there to give evidence of this.

 

As for the nitty-gritty of programming faster look-up of BASIC line numbers or optimizing the mechanics of for/next loops at the level of assembly language, this is where we run into the parable of The Blind Men and the Elephant.

 

Some people look at 8-bit computers and see memory tables. (Thanks Mr.Fish. That was interesting.) Others see binary code. Others see assembly. Others see BASIC for-next loops. Some, of course, see many parts. I find those other parts interesting and appreciate learning general-theory aspects. But I know it's too late in the day for me to become a MAC/65 ninja, although I have dabbled in the basics of that (and it seems much easier via Turbo Macro Pro on the C64 via instruction from Robin at 8-Bit Show And Tell)

 

Aside from old Hindu stories, what I like (ranging near the topic at hand) about Turbo-BASIC XL is its predictability. When something isn't working I know that 99.5% of the time it is my fault, not some strange quirk of the language (quite apart from the COMPILER which is so unreliable as to make it somewhat unusable).

 

I was spelunking in Basic XL/XE last night (mainly XL, because XE does seem to be problematic). I had run across a chart comparing features of various BASIC programs for the Atari. I saw that XL/XE does string arrays (it does) and even, apparently, "auto-dimensions" string arrays (that didn't work). So I wrote a simple program to test it. It didn't work. I couldn't see why. So I opened the same program in Microsoft Basic II and it worked perfectly. I then re-saved from MB and opened the same file in Basic XL. Now it worked.

 

My point is, I don't mess with computers in order to go insane or pull my hair out. Yes, sometimes when things go wrong, half the fun is treating it as a puzzle to figure out. But when the basic infrastructure of a program seems to be working against you, that's no fun. And that's my impression of Basic XL/XE, although XL seems (oddly) more capable. Heck, I couldn't get line renumbering to work in XE but it worked in XL. Why? Who knows. And I got the same results on two different emulators.

 

 

10 DIM CARD$(52)
20 FOR X=1 TO 13
30 READ Y$
40 CARD$(X)=Y$
45 PRINT CARD$(X);" ";
50 NEXT X
60 END
70 DATA "ACE","DEUCE","3","4","5","6","7","8","9","10","JACK","QUEEN","KING"

 

[Brad Nelson]

Quote

In machine code, the basic logic in the second block of code takes up more memory than the loop, but the idea is you've taken out the cost to the CPU of executing the branch to carry out the loop (making the computer go back to previously executed code), and you've accomplished the same result. The article said Ostrowski did this with "small loops." So, the memory cost is not large, but what was probably going on is these small loops were being run many times to carry out one arithmetic function, like square root. The idea being "this small cost adds up." So, by eliminating it, you make the function run noticeably faster.

 

Very interesting, Mark. I wish that Ostrowski was around to continue working on TB...or that some team would pick that up as a project. The COMPILER could use some work and integrating it tighter into TB would to nice.

 

And what you said about code optimization made me think of one of Dave's (Dave's Garage) videos wherein it was code assembled by C (some variation of the language) that actually proved faster than a hand-coded assembly language program. Apparently, these assemblers having gotten crazy-good at what they do these days.

[Geister]

15 hours ago, Brad Nelson said:

I read that Basic XE has an optimization (I think when you use a command called FAST) where it can use hard addresses for branch points, thereby eliminating the search.

 

I think you've summarized that rather well. And if I recall correctly, Basic XE had that "fast"ness built in whereas you needed to use that command explicitly in Basic XL. I've played around in Basic XE a bit and I think the reason we possibly don't hear more about it (it looks to be a great program) is that it came out at the same time as Turbo-BASIC XL. TB was free. XE was $79.95. Here's a bit from the AtariWiki page on Basic XE:

 

OSS released Basic XL in 1984, adding many new features as well as the FAST command. FAST cached line numbers that were the target of jumps (GOTO and FOR/NEXT loops), addressing one of the two major reasons for the notoriously slow performance of Atari BASIC. The main addition to Basic XE, compared to Basic XL, was a solution to the other big problem in Atari BASIC, the low-performance math code.

 

The Wiki page on Turbo-BASIC XL has a bit more to say about the nitty-gritty of the reasons for the slow-down. I can't say I understand the half of it. But the bottom line is, they made it faster!

 

I don't know when I ran across TB. But certainly its speed benefits and extended command set made it attractive. And like I said, I'm more of a dabbler. When I try to mess with Action! or Fast Basic I just hit the bad side of a learning curve. I can't just get up and go. These programs (certainly with good reason for the expert program) have been "structured" and "refined" into a not-too-comfortable pair of shoes for the casual (or even intermediate) user.

 

TB walks a nice line. If you really want to do programming that is a little more structured, you can. If you just want to hash something else, the program does not get in your way. I like that.

I think you are conflating OSS's Basic XL with Frank Ostroski's Turbo Basic XL.  They are not the same.  OSS was the company that Atari worked with to get a Basic in the Atari when MS-Basic for the Atari was delayed.  OSS wrote the Original Atari Basic, Basic XL, Basic XE and many of the Aftermarket DOSs  for the Atari such as OSA+.  

 

Turbo Basic XL was a complete surprise to me when I found it as the performance was amazing and the expanded features made it one of the top Basics for any 8 bit computer.  We are now spoiled for choice for Basic programming language versions with the addition of Altirra Basic and Fast Basic.  We also have the option of running Microsoft Basic, but who the hell cares?

[Geister]

On the subject of performance, I often use an old basic program I call "The Hat" for obvious reasons.  Back when I had my original 400 I typed this little program in and ran it and watched for 3 hours as my underpowered 400 wheezed through the program and took 3 hours to render the 3D image that resembled a hat.  Of course there was a typo in my copy of the program and as the last pixel was plotted Basic dropped to the Ready prompt and cleared the screen.  I fixed the program and re-ran the program and I've been converting the program to any language that has the floating point capabilities to  execute it.  Turbo Basic XL crushed this program in an hour without any changes.  I was really impressed. 

 

I've since  converted the program to Basic XE, Commodore Basic V2.0 and Commodore Basic V7.0 on the C128 (emulated).  Basic XE and Commodore Basic V7.0 were very similar to Turbo Basic XL in speed and Commodore Basic V2.0 made Plain Old Atari Basic look spritely. 

 

I've wanted to try a version of the program on a TI 99, but even with Extended Basic, TI doesn't have the tools to do 3D plotting.  I understand there are new tools available but I don't want to spend for them.

 

Maybe I'll get a TRS80 CoCo and try it?

Edited November 2, 2023 by Geister

[Brad Nelson]

Quote

I think you are conflating OSS's Basic XL with Frank Ostroski's Turbo Basic XL.

 

I was actually talking about both, Geister.

 

Quote

Turbo Basic XL was a complete surprise to me when I found it as the performance was amazing and the expanded features made it one of the top Basics for any 8 bit computer.  We are now spoiled for choice for Basic programming language versions with the addition of Altirra Basic and Fast Basic

 

Yep. Turbo-BASIC XL is a great program and came as a surprise to me as well. Regarding Microsoft Basic II, one of the first programs I bought for my Atari 800 (in the late 80's) was the first version of Microsoft Basic. I forget offhand if that came on a cartridge. (Update: It was on a floppy...must also have had an 850 drive.) I think it did. Certainly the later MBII came on cartridge with an extension disk. And it's a perfectly serviceable basic. If one wanted to get beyond the limitations of Atari Basic, it was one of the early ways to go. And I did.

Edited November 2, 2023 by Brad Nelson

[+CharlieChaplin]

6 hours ago, Brad Nelson said:

 

Very interesting, Mark. I wish that Ostrowski was around to continue working on TB...or that some team would pick that up as a project. The COMPILER could use some work and integrating it tighter into TB would to nice.

 

Alas, Frank Ostrowski already passed away.

 

[Brad Nelson]

Quote

 I often use an old basic program I call "The Hat" for obvious reasons.

 

That would be very cool to see that, Geister...in any version. TBXL would be idea, of course.

[+Stephen]

5 hours ago, Geister said:

On the subject of performance, I often use an old basic program I call "The Hat" for obvious reasons.  Back when I had my original 400 I typed this little program in and ran it and watched for 3 hours as my underpowered 400 wheezed through the program and took 3 hours to render the 3D image that resembled a hat.  Of course there was a typo in my copy of the program and as the last pixel was plotted Basic dropped to the Ready prompt and cleared the screen.  I fixed the program and re-ran the program and I've been converting the program to any language that has the floating point capabilities to  execute it.  Turbo Basic XL crushed this program in an hour without any changes.  I was really impressed. 

 

I've since  converted the program to Basic XE, Commodore Basic V2.0 and Commodore Basic V7.0 on the C128 (emulated).  Basic XE and Commodore Basic V7.0 were very similar to Turbo Basic XL in speed and Commodore Basic V2.0 made Plain Old Atari Basic look spritely. 

 

I've wanted to try a version of the program on a TI 99, but even with Extended Basic, TI doesn't have the tools to do 3D plotting.  I understand there are new tools available but I don't want to spend for them.

 

Maybe I'll get a TRS80 CoCo and try it?

Would be cool to see how fast a full 6502 version could be.  I don't mean cheating by plotting a table of points, but maybe the fastest way using lookup tables for the trig calculations.

[+MrFish]

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

 

[markmiller]

7 hours ago, Brad Nelson said:

I wish that Ostrowski was around to continue working on TB...or that some team would pick that up as a project. The COMPILER could use some work and integrating it tighter into TB would to nice.

Me too. The compiler is kind of a disappointment, for reasons I've already talked about. Though, I think what would improve the experience is thorough documentation on what works well with it, and what doesn't. That's what's been really lacking. 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.

 

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! Though, if you were to look at the Happy Computer listing, it's in machine code (the compiled version).  I really wish he had published his original TB source code for the compiler. I'd love to work on an English version of it.

 

I've read about how the approach Ostrowski took with it is not unusual. For example, Microsoft published an Applesoft Basic compiler for the Apple II that was written in Basic, commonly called TASC (The AppleSoft Compiler). It was also self-compiled.

 

I remember using the Einstein Basic compiler on the Apple IIe to compile a 200-line Applesoft program I'd written in high school. Maybe I'm remembering this wrong, but my memory is it took about an hour! That's a little more than 3 lines of code per minute! It accessed the disk a lot, though, and there was very little it couldn't handle. What I've seen is that TB's compiler is quite a bit faster. I've tried compiling a large program with it, and I think the whole process took about 10 mins., but maybe this is because of what the compiler doesn't handle.

[markmiller]

@Geister- Whenever I saw programs like that published in computer magazines, it was always for something like the IBM PC, or the Apple II, but never for the Atari. So, when I saw Francesco Fiorentini talk about "Samples of Surfaces in Space," by Francesco Petroni in RetroMagazine, and adapt it to Visual Basic (for DOS), I thought to heck with it. I'm going to write this for the Atari. I took Petroni's original GW-Basic code, and ported it to TB.

 

I used as much of the original GW code (including line numbers) as I could, so that readers could follow along with Petroni's article.

 

 

Since I was interested in reading what Petroni had to say, I translated his article into English, using Google Translate. His article was called "Graphics … without input, Part 2"

 

Grafica senza ... input seconda parte

 

I emulated GW-Basic's graphics display logic, using the original program's coordinate system, dynamically scaling the coordinates to the range of Graphics 24 (8+16), and I implemented "enough" of a clipping algorithm to make it work, since one of the designs plots coordinates that go off the screen in the original version (GW implemented clipping).

 

Even though I listed the code at the end, I realized later I had been rather sloppy. So, I cleaned up the logic, and posted a link to my revised source code on GitHub in the video description.

 

"Samples of Surfaces in Space" source code

 

That version runs a little faster than what you see in the video, and includes "design numbers" that the original GW program had. It was a good way to learn about TB.

Graphics without input by Fancesco Petroni - MCMicrocomputer, January 1985.rtf

Edited November 3, 2023 by markmiller
Inserted link to source code