Jump to content
IGNORED

Turbo Basic XL versions?


Philsan

Recommended Posts

I think the interpreter might be AUTORUN.SYS, so perhaps go ahead and rename it TB.COM or similar. Test with X AUTORUN.SYS first and see what happens.

 

I asked about extended RAM only because without it, the SDX SIDE driver will cause MEMLO problems.

 

TBXL 1.5 is the version I used back in the 90s with SDX.

  • Like 2
Link to comment
Share on other sites

  • 3 years later...
On 9/29/2007 at 5:09 PM, dwhyte said:

 

I've included the TurboBasic 2.0 & 2.1 in the attached file. Not sure of the actual differences between 1.5 and 2.0... 2.1 is a Turbo2000 version with a little minidos in it... Other than that they're basically the same as 1.5...

Turbo_Basic_XL_2.0.atr.zip 59.61 kB · 482 downloads

version 2.0 leaves just over 34K fre(0) where version 2.1 leaves under 31.5K fre(0) big diff still trying to figure out what the difference is ;) 

Link to comment
Share on other sites

59 minutes ago, flashjazzcat said:

dwhyte tells you in the post you just quoted what takes up the extra space in v.2.1 over v.2.0: apparently a built-in mini DOS.

Thanks for that info - mini dos seems hardly worth nearly 3K of program space in my way of thinking.

I think I figured out another part of the puzzle.  From the above Turbo_Basic_XL_2.0.atr.zip  package if you get into Turbo 21 and exit to dos you can Quit back into Turbo 21 and your source code is still in memory untouched.  If you Dos out of Turbo 2.0 the code in the interpreter gets flushed when 2.0 loads lacking the Quit back to Basic option.

Edited by Ray Gillman
Link to comment
Share on other sites

  • 2 years later...
On 9/29/2007 at 8:44 AM, TXG/MNX said:

Hi,

 

There are 2 versions official

 

1 version for the 800 (48Kb) and the XL 1.5 for the XL/XE (64Kb)

 

Then there is also a version combined with spartados 3.x custom made.

 

This version you show is the normal 1.5 XL only copies automaticly the runtime.obj and compiler to the ramdisk so it works much faster....

 

Turbobasic is pretty good only the compiler s*#$*&* because not all code can be compiled and you always need to load the big runtime.obj first.

 

A compiler that would compile to 100% machine language would rule...

 

Re. the compiler - I'm finding that out, unfortunately. My issue seems different. I've been using 1.5. No complaints with the interpreter. My code compiles fine, but it doesn't run. It runs fine in the interpreter, but the compiled version errors out on an array reference. I've checked my index values (using debug print statements in the compiled version), and they're fine.

 

It is nice, though, that the runtime stops with a recognizable error number, and line number, so I can see what it's balking at, but it's still disappointing. Seems like a problem with the runtime, actually. I'm compiling my program as an EXE using the linker.

Edited by markmiller
  • Like 1
Link to comment
Share on other sites

Following up on my last comment, I now think the compiler is the problem, not the runtime. I got my program to work, but only by realizing that the compiler has some bugs in it.

 

It's touchy about array references. I had to not embed one array reference inside another, and not use more than a couple array references in an expression.

 

So, don't do:

 

A=ARR1(ARR2(IDX))

 

Do this instead:

 

B=ARR2(IDX):A=ARR1(B)

 

ARR(IDX-1)=ARR(IDX) is fine, but don't do something like:

 

ARR(IDX-1)=ARR(IDX-1)-ARR(IDX).

 

Instead do:

 

VAL1=ARR(IDX-1):VAL2=ARR(IDX):ARR(IDX-1)=VAL1-VAL2.

 

I can have as many references to non-array variables as I want in an expression, and it works.

 

Another thing I found out is it appears to have a bug that's touchy about mixing or changing priority on boolean operators.

 

If I did:

 

IF COM$(8,8)="D" AND (COM$(9,9)=":" OR COM$(10,10)=":")

 

the compiled program would execute it like this:

 

IF COM$(8,8)="D" AND COM$(9,9)=":"

 

and just ignore the rest of the expression. To make this work, I had to do:

 

IF COM$(8,8)="D"

   IF COM$(9,9)=":" OR COM$(10,10)=":"

      ... do stuff ...

   ENDIF

ENDIF

 

What's disappointing is all of this stuff failed silently. I got no error messages from the compiler. In fact, it finished saying "no errors". The compiled program just acted weird when I tried to run it...

 

What's strange is the interpreter has handled everything I've thrown at it just as I expect. However, the interpreter and compiler were written by Ostrowski. It kind of makes me wonder, "What gives?..."

Edited by markmiller
  • Like 2
Link to comment
Share on other sites

a AND b OR c is somewhat ambiguous especially if using short circuit logic or lazy logic. There is no need to even test for c if a AND b are TRUE. AND has a higher precedence than OR and the statement is checked left to right.  
 

Your IF statement is this:  a AND (b OR c) vs (a AND b) OR c.   
 

The compiler could still be wrong with your original code depending on the test cases but not enough data is presented to conclude that for this construct.  ?

  • Like 1
Link to comment
Share on other sites

Re: TurboBASIC compiled troubles with string arrays...

 

Hmm... That may explain why my sorting subroutine didn't work in compiled TurboBASIC for Push It! V.1.7. Thankfully by then I had sped the rest up with a machine language subroutine and the sort was unnecessary at that point. I may look at it again someday.

Link to comment
Share on other sites

8 hours ago, kheller2 said:

a AND b OR c is somewhat ambiguous especially if using short circuit logic or lazy logic. There is no need to even test for c if a AND b are TRUE. AND has a higher precedence than OR and the statement is checked left to right.  
 

Your IF statement is this:  a AND (b OR c) vs (a AND b) OR c.   
 

The compiler could still be wrong with your original code depending on the test cases but not enough data is presented to conclude that for this construct.  ?

I understand the precedence rules. AND is higher than OR. The interpreter also used this precedence, but it paid attention to my use of parentheses around the OR expression. By putting parentheses around the OR I was saying, "Look at this expression as a single term for AND." It would likely execute the left-hand term for AND first. If it's false, it should ignore the rest of the expression. However, I found through my own code that the interpreter does not! Even if the first term is false, it continues with the other tests in the expression. This is wasteful, and unlike any other language I've used.

 

The reason I know this is I had code like this in the original version of my code (which I later changed):

 

IF LEN(COM$)>3 AND COM$(4,4)="A"

 

For a 3-character string, the interpreter gave me an out-of-bounds error on this line, because the left-hand test was false, but it continued with the right-hand array reference, anyway.

 

Referring to the original statement, I was using the code to parse a filename spec. So, it accepts if the user types something like "D:FILENAME" or "D2:FILENAME" (the ":" changes place by one character). It accepts if there's a "D" at location 8, and if there's a ":" at either location 9, or 10.

 

The problem with the compiled version was if I input "D2:FILENAME", it executed my error-handling code for if the input was a bad file spec., since it ignored the parentheses around the OR, and didn't see a ":" at location 9. As far as I'm concerned, it wasn't a bug in my code. I was clearly communicating my intent.

Link to comment
Share on other sites

On 6/20/2022 at 10:51 AM, markmiller said:

My code compiles fine, but it doesn't run. It runs fine in the interpreter, but the compiled version errors out on an array reference.

It is knowing BUG in BASICs for Atari, translate from Polish:

http://atariki.krap.pl/index.php/Turbo_BASIC_XL

and about DIM/COM error in compiler:

http://atariki.krap.pl/index.php/Turbo_BASIC_XL_Compiler

especially this one:

A bug in handling numeric arrays (both one-dimensional and two-dimensional), causing them to malfunction after compilation.

        Alternative method: when using numbers in the range 0-255, text arrays can be used. The equivalent of two-dimensional number arrays can be obtained by projection with an assumed step. This solution was proposed by Fox.

  • Like 2
Link to comment
Share on other sites

Interesting for this subject to come up; I've been spending a lot of time with the compiler for my slot machine game over the last 6 months or so -- off and on.

 

I've had some of the same problems, and some additional ones; but, interestingly, I've found a solution that seems to be working for a while now.

Initially, I had (by way of loose programming) been operating in the 240+ range with the variable name table (supposedly expanded to 256 with TBXL).

I had suspected it might be a problem, but only tested out the theory recently, because I'd found other temporary means of getting around it.

I've found over the recent several months of compiling, that if I don't get above the 215 range in the variable name table, everything that works in 

the interpreter will work in the compiler. I haven't taken time to test this idea specifically enough to say this is what has fixed the problems I've been

having; but experience has made it something that works so far. I'm hesitant to make any claims, in part too, because I'm also utilizing the basicParser,

which could be pushing the compiler to do some additional things it doesn't like -- beyond what working with one-to-one source would do.

 

Ultimately, not having more space available in the variable name table is going to result in moving everything over to Fast Basic, though. Porting will be

pretty direct anyway -- aside from lack of multi-dimensional arrays; and of course they'll be a speed gain, and additional features available in Fast Basic.

Since Fast Basic was designed with TBXL in mind, this will be a natural progression.

 

  • Like 1
Link to comment
Share on other sites

8 hours ago, Sikor said:

It is knowing BUG in BASICs for Atari, translate from Polish:

http://atariki.krap.pl/index.php/Turbo_BASIC_XL

and about DIM/COM error in compiler:

http://atariki.krap.pl/index.php/Turbo_BASIC_XL_Compiler

especially this one:

 

 

Hmm. I feel like making a contribution to the wiki re. what I found, but I can only competently do it in English. Would they mind? :)

Link to comment
Share on other sites

On 6/22/2022 at 2:33 PM, Sikor said:

It is knowing BUG in BASICs for Atari, translate from Polish:

http://atariki.krap.pl/index.php/Turbo_BASIC_XL

and about DIM/COM error in compiler:

http://atariki.krap.pl/index.php/Turbo_BASIC_XL_Compiler

especially this one:

 

 

I noted this on the compiler page:

 

Quote

As a curiosity: the Turbo BASIC XL compiler was written in Turbo BASIC XL.

Neat. I take it once the compiler was written, Ostrowski used it to compile itself, and that's what was published. I only wish the compiler source was available.

 

I heard recently that TASC, a Basic compiler Microsoft published for the Apple II (standing for The AppleSoft Compiler) was written in Applesoft Basic. Though, I read it went through a few passes to compile a program, since it was published in 1981, and memory was limited.

 

The TBXL compiler is surprisingly fast. Many years ago, I remember compiling a large Applesoft Basic program I wrote, using the Einstein compiler, and it took something like an hour to finish! The program was about 800 lines of code. Though, it compiled to disk. TBXL compiles to memory. That helps!

 

Following up on what TXG/MNX said about it, I take it what's going on is Ostrowski recycled the runtime out of the original interpreter, the compiler sets up fixed addresses for all variables, and instead of interpreting tokens, translates the tokenized code into JSR calls into the runtime, with the compiled program either taking a little direction from the runtime re. branching into itself, or not consulting the runtime for that, and just inlining the internal branch code.

Link to comment
Share on other sites

  • 1 month later...

Another difference I noticed between the interpreter and the compiler seems to have to do with length of procedure code, but I'm not sure.

 

I'm working on a project, and one of my experiments had me writing a long procedure with many lines of code (I don't remember how many, maybe 100). In the interpreter, everything worked fine. I think the compile went fine as well. When I went to run it, I got an Error 28 (ENDPROC with no corresponding EXEC) before I could even interact with it. It happened long before it should have, because the program startup initializes a bunch of variables, and takes input from the user before it should've ever gotten to this spot in the code. I was mystified.

 

The line number it gave me pointed to an ENDPROC, but I looked through the code leading up to it, and everything looked good. It had a corresponding PROC. The program itself had an END statement at the end of execution (so it wouldn't run into a PROC without an EXEC). I didn't know what to make of it. I figured my procedure was too long for the compiler to handle.

 

I ended up getting rid of the experiment, because it was too slow. I got rid of the "problem" procedure along with it, went with a different approach, and when I tried to compile again, everything went fine. Though, in the version I last compiled, it has a couple procedures with many lines of code in it. So, I'm not sure if that was even the issue. It was just weird. Maybe it has to do with what MrFish talked about. My project is getting rather large, with many variables.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...