TURBO BASIC build inside the XL

[ndary]

I uploaded another PAGE to my small on-going web site project

 

http://ataripal.googlepages.com/turbobasicxl

 

enjoy

ndary

[+Philsan]

Thank you!

[atarixle]

oh, what honor:

one of my favorite examples is the BOSS-X which is a Desktop Operating system for the ATARI computer that was programmed in Turbo Basic.

[Chrodegang]

I uploaded another PAGE to my small on-going web site project

 

http://ataripal.googlepages.com/turbobasicxl

 

Nice

Edited September 30, 2007 by Chrodegang

[peteym5]

Building it inside an XL or XE is cool. However I am wondering if the ML source code is available for Turbo Basic is floating around somewhere. I Personally would look into adding commands, take advantage of expanded memory, make it compatible with Sparta-DOS, etc.

 

Turbo Basic is much better than Atari Basic in speed and function, plus it can be compiled for more speed. I also once owed Basic XE, which also ran faster than Atari Basic, Its advantage was using expanded memory for your Basic Code. It also had some sweet features like Print Using and String Arrays. However, it did lack a full compiler to let your code be intendant from the cartridge.

 

The only thing that can run faster than a Compiled Turbo Basic is using direct Assembly. I know a few did comment about the Compiler fully compile to machine language. Once thing you have to take into account, is that all your numeric variables are the Ataris' floating point and need to be calculated inside the Floating Point routines in the Ataris' Rom. The are no Integers or single byte variables here. You also have an option of writing a few ML routines called from the USR statement in Basic to add even more speed.

[Marius]

The only thing that can run faster than a Compiled Turbo Basic is using direct Assembly.

 

 

I doubt that. Basic is a HIGH LEVEL language, even when it is compiled. Since it uses a RUNTIME package, it is not really compiled, like an assembler will compile it. And even REAL basic compilers, do not compile to a very compressed and fast code.

 

The fastest language next to Assembler is Action I guess.

 

Turbo Basic is really a great language, but it is a BASIC. And compared to lower level languages, basic is, and always be a slower alternative. Compiled or not.

 

But don't get me wrong: I really like Turbo Basic.

 

Marius

[peteym5]

Actually when you compile something that still requires a runtime is compiled to machine language. The Runtime contains routines that perform the same functions as the interpreted mode. If you wanted to compile a large to 100% machine language without no runtimes, it probably will not fit into the 64k ram.

 

One reason why even compiled TurboBasic is slower than machine language is because all the math is done via the floating point package. That is 6 bytes per variable in Binary Coded Decimal. In Assembly have an option of doing your math one byte at a time and can be 1,2, or more bytes depending on what you need to store. That is unless you need to do decimal or fraction type calculations. Versions of Microsoft Basic like QBasic and Visual Basic lets you define your variables as Single or Double for floating point. Byte, Short, Integer, or Long for whole number calculations. String for Strings. The only Basic on the Atari that had floating or integer was Microsoft Basic. If Turbo Basic had just an option to make your variable Floating, Integer, or Byte variables when you only need to use whole numbers, it would speed things up quite a bit.

 

Like I say, you can write a few ML routines. I made a few that manipulate the Player/Missile graphics, moving rectangles of characters onto a character mapped screen, and generate sound effects. I even experimented with scrolling routines. Using ML for things that take too long to do in Basic alone and does not require floating point calculations. My Jungle/Pitfall type thing is planned to be total ML and using Turbobasic to do transitional testing.

 

Visual Basic and Qbasic run at higher speeds on the PC because it always runs compiled, takes advantage of the Floating Point co-processing (has been a part of the main processor since the Pentium/ '586.)

[+Larry]

Actually when you compile something that still requires a runtime is compiled to machine language. The Runtime contains routines that perform the same functions as the interpreted mode. If you wanted to compile a large to 100% machine language without no runtimes, it probably will not fit into the 64k ram.

 

(snip...)

 

Well good -- we're on one of my very favorite subjects, BASIC compilers.

 

I used to wish for "stand-alone" .exe files for TBXL compiled programs, and someone developed a linker. After the linker does its magic, you have one executable file. Nice!

 

I'm not an expert on TBXL, but I have been told that it does produce ml code. (As you mention) the runtime is large, but frequently that is a common tradeoff in order to keep the compiled code from becoming even more massive as well as provide efficient code for common tasks. A "library" of core routines. But the TBXL compiler does produce fast code. Unless you "diddle" with the code, it is the fastest "regular" compiler. ADVAN may be faster (?), but it is pretty unconventional if you are used to Atari BASIC or TBXL. The MMG/Datasoft compiler actually produce assembler code that is assembled in the third or fourth pass of the compiler, so if you want to massage the code, it presents the opportunity. It also offers the choice of floating point or integer compiler packages.

 

I also thought that the TBXL compiler used TBXL's faster math routines? But a 6502 is just not ever going to set the world on fire with its multiplication/division.

 

Here is a question that I've never been able to find a suitable answer for. What is P-Code (as in ABC from Monarch) and can someone provide an example of how it works? I understand the concept, but I can't grasp what the "intermediate" (P-Code) would be like.

 

And the math routines raise another question. What XL/XE Operating Systems use built-in "fast math" routines? I know that the CSS UltraSpeed Plus OS does, but I'm not aware of any others.

 

IF a math co-processor is ever released for the 8-bit, that would speed some operations up quite a bit. Maybe even the 65C816, IF one ever becomes commonly available for the Atari. (I wish for an accelerator every Christmas, but thus far, I've evidently been too naughty...)

 

-Larry

[+Larry]

I uploaded another PAGE to my small on-going web site project

 

http://ataripal.googlepages.com/turbobasicxl

 

enjoy

ndary

 

Hi Nir-

 

I'm not sure about the mounting of the TBXL board(s).

 

I presume that on the TBXL board, there is a 24-pin header to plug into the normal rom position on the board. But then it appears that the eprom is plugged into a board. Are there two boards? Could you please explain this a bit.

 

Thanks,

Larry

[+Philsan]

Turbo-Basic XL solves the Atari Basic rev. B infamous bug?

After having loaded TBXL there are no more lock-ups?

Edited October 1, 2007 by Philsan

[+Larry]

Turbo-Basic XL solves the Atari Basic rev. C infamous bug?

After having loaded TBXL there are no more lock-ups?

 

What infamous bug? The lockup bug was prevalent in the original release "A" along with a couple of less vicious ones; the 16-byte bug was the major bug in "B" which otherwise cleared up the major bugs in "A". But I'm not aware of any major bug in "C". Have you ever really seen this bug, and if so, do you know how to reproduce it?

 

I've never encountered any bugs in TBXL or Rev. "C".

 

-Larry

[+Philsan]

Excuse me! My mistake!

The Atari Basic *rev. B* lock-ups!

Edited October 2, 2007 by Philsan

[ndary]

The eprom you see on the picture is probably an additonal OS upgrade for the atari (maybe ARGS os). i am sure Chrodegang can share more light on it

 

Ndary

[+Larry]

The eprom you see on the picture is probably an additonal OS upgrade for the atari (maybe ARGS os). i am sure Chrodegang can share more light on it

 

Ndary

 

Ah! I think I see now. My "X-ray vision" shows

 

Left pins/connectors 24-pin header

Middle 28-pin eprom

Right top/bottom the logic chips

 

Thanks,

Larry

[drac030]

I've never encountered any bugs in TBXL or Rev. "C".

 

There are some. For example:

 

Atari BASIC:

 

1) you can type in the DIM instruction without arguments, like: 10 DIM: DIM: DIM

 

2) NOTE and STATUS accept numeric dimension as a parameter: STATUS #1,A(0) is accepted, but the value isn't assigned correctly to the array element.

 

3) IF CHR$(1)=CHR$(2) is always true

 

4) 1^44 is two

 

There are also some bugs in the syntax control.

 

Turbo BASIC XL:

 

1) %GET, %PUT and -MOVE aren't accepted when typed in lowercase

 

2) DEC() works wrong when the argument contains lowercase characters

 

3) Ctrl/R at the end of the text string works just like the semicolon.

 

4) the syntax control accepts text array as an argument to the GET keyword, which can only assign values to numeric variables

[+Larry]

There are some. For example:

 

(snip...)

 

OK, but those look pretty trivial compared to the original bugs in Rev A and B.

 

I've never had a program lock up or do something really weird with Rev C or Turbo (although I do seem to remember that TBXL is kind of picky about loop nesting).

 

How is your 65816 Basic coming (probably waiting for a 65816...)?

 

-Larry

[peteym5]

TURBO BASIC is superior to the original Atari Basic and I prefer it over Atari Basic or Basic XE. One bug I do recall is accessing Arrays when compiled, it did something really weird. I got around it by peeking and poking tables. Using Turbo Basic would certain get around the bugs from Rev A, B, & C, because it is a different version of Basic now. I rarely used most of those buggy statements in TurboBasic and was not aware of them until it got mentioned here. I have to check them out in my Emulator.

[peteym5]

I tried to test to see if I can duplicate some of those Turbo Basic Bugs. DEC not being able to interpret lowercase characters: As far as I know most people write Hexadecimals with numbers+uppercase A-F and probably something the original authors of TB probably also assumed. I could not duplicate the CTRL-R bug at an end of a string. Printing two strings with the last character being CTRL-R (Hoz Line) printed them on seperate line. %GET, %PUT and -MOVE: I tried this and it did give an error, probably because the first character is not alpha. These bugs appear to be present in both 1.5 and 2.11. Anybody know of the real difference between 1.5 and 2.11?

[carmel_andrews]

Didn't know that there were any bug's in atari basic (rev. c)

 

I thought that rev. c = debugged

 

You can't compare Atari basic with turbo basic anyway...remember, when atari basic first came into being memory storage was a premium, hence why Atari and SMI/OSS kept to the stated 8k rom space, even rev c AB is still 8k rom

 

whereas turbobasic has somewhat larger work area (over 16k), so you expect it to have more 'features' then standard atari basic

 

a fairer comparison would have been turbo basic and basic a/basic xl/basic xe from oss

[+Larry]

This is a very nice hack, and one I'm planning to try this winter (my "slow season" away from my garden).

 

Has anyone else successfully done this -or- plans on trying to duplicate it?

 

Thinking ahead, an issue I see is that the TBXL + Compiler eprom would probably be better replaced (and project simplified?) by one with TBXL, only or TBXL + something else. Reason? The linker to make stand-alone .exe complied files would be nicer, I believe.

 

Any thoughts would be appreciated, and if anyone wants to jump on-board on this project, that would be great.

 

-Larry

[a8maestro]

Here is a question that I've never been able to find a suitable answer for. What is P-Code (as in ABC from Monarch) and can someone provide an example of how it works? I understand the concept, but I can't grasp what the "intermediate" (P-Code) would be like.

 

Near as I can tell...P-Code is just the original basic tokens, with all rems removed, line numbers(and gotos, gosubs) converted to address jumps or jsrs, and numerics as integers only.

 

Then there is the runtime module to execute the tokens, possibly with faster code for some of the stuff.

 

Hence "compiling" rather than "assembling" in the atari world. "Compiling" seems to be a stopgap between text based BASIC and full on assembly.

 

PS. This seems to be true for "C" compiling as well. Full on Assemblers were available for "C", though I think they had bugs too.

 

Rick.

Edited October 28, 2007 by a8maestro