Revision C BASIC Error that does not show in Rev A or Altirra BASIC

[+SoulBuster]

I returned to working on the Analog Magazine Disks and ran in to an error while typing in Dungeons and Dragons Housekeeper.

 

I use the 130XE setup w/576 mb memory and the XEGS OS along with Rev C BASIC in Altirra 4.01

 

The first screen shows the line of code in question with a REM.  The next screen shows what happens when the REM is removed.  This does not happen in Rev A or Altirra BASIC. If you take the last semicolon and and string (G$) off, this does not happen, as you can see in the third screen. Just wondering if anyone else has run across this?

[+SoulBuster]

Wow here is another one.

 

Altirra basic has a problem with this line and Rev C does not

 

First screen shows the line in Altirra BASIC with a REM, second without and third is Rev C.

[TGB1718]

It looks like the tokenizing process is exceeding the maximum number of variables it can handle on it's stack

during the process,  if you do the same thing with numbers instead of strings, it's ok, but just add one more variable

and it pops the same error.

 

Remove the offending variable and you can add a ':' and then add further statements on the line, so it's not a line length

error as indicated by the error number.

 

EDIT: BASIC XE also doesn't like it, at least you get a better error description

 

3020 PRINT #1;HH$;T$;JJ$;T$;KK$;T$;A$;T$;B$;T$;C$;T$;D$;T$;E$;T$;F$;T$;G$

Error - 14 at line 3019
Line Too Long or Complex

Edited December 20, 2022 by TGB1718

[+SoulBuster]

Interesting, I wonder why Rev A and Altirra do not have a problem with it?

[TGB1718]

23 minutes ago, SoulBuster said:

Interesting, I wonder why Rev A and Altirra do not have a problem with it?

Rev A -->>> Rev C fix some bugs, add some new ones  it's all down to testing (or lack of )

 

 

[reifsnyderb]

Is the Atari BASIC source code available?

[phaeron]

We have the source code to Atari BASIC in the Atari BASIC Source Book, rev. A I think. Not sure about rev.B/C, which might have been binary patches anyway.

 

The issue in the first case is a parser stack overflow. Atari BASIC uses a parser that evaluates the grammar by recursion through a soft stack, which means that repeated elements consume more of the stack. The specific issue is this part of the grammar for the PRINT statement:

 

<PEL>=<PES><PELA>#
<PES>=<EXP>|<STR>
<PELA>=<PSL><PEL>|&#
<PSLA>=<PSL>|&#
<PS>=,|;#

 

This is a list of print elements -- expressions or strings -- separated by lists of print separators. Problem is, evaluating this classically results in the parser stack gaining an additional three entries per print element due to the recursive descent. The parser stack is 64 elements of 4 bytes and overflows at ~21 entries. It seems that Atari BASIC rev. C has one less or uses one more parser entry than rev. A, resulting in the error.

 

As for Altirra BASIC, it's a reimplementation of Atari BASIC from scratch, so it often doesn't share the same bugs. In this case, it avoids this problem because it has a more hardcoded parser that uses looping instead of recursion for many structures, which avoids the excessive parse stack depths seen here.

 

The second issue is a compatibility issue due to additional keywords -- specifically CP being a statement alias for DOS inherited from BASIC XL/XE. No issue in execution, but this blocks the parser from allowing CP as a variable.

 

[+MrFish]

13 hours ago, phaeron said:

We have the source code to Atari BASIC in the Atari BASIC Source Book, rev. A I think.

It is Rev. A.

  

13 hours ago, phaeron said:

Not sure about rev.B/C, which might have been binary patches anyway.

I have 2 disks with Mac/65 source files, with this in the header of the first file.

 

10       .PAGE       'ATARI BASIC'
20 ;;
30 ;
40 ;COPYRIGHT (C) 1978,1979,1983
50 ;OPTIMIZED SYSTEMS SOFTWARE
60 ;CUPERTINO, CA.
70 ;
80 ;THIS PROGRAM MAY NOT BE REPRODUCED,
90 ;STORED IN A RETRIEVAL SYSTEM, OR
0100 ;TRANSMITTED IN WHOLE OR IN PART,
0110 ;IN ANY FORM, OR BY ANY MEANS, BE IT
0120 ;ELECTRONIC, MECHANICAL, PHOTOCOPYING,
0130 ;RECORDING, OR OTHERWISE WITHOUT THE
0140 ;PRIOR WRITTEN PERMISSION OF
0150 ;
0160 ; OPTIMIZED SYSTEMS SOFTWARE, INC.
0170 ; 10379 LANSDALE AVENUE
0180 ; CUPERTINO, CALIFORNIA 95014 (U.S.A.)
0190 ;
0200 ; Telephone:  (408) 446-3099
0210 ;

 

So, it looks like Rev. C, and appears to be the full source code (156 KB in 14 files -- tokenized).

 

Oddly, I have no idea where I got these disks. I initially assumed it was part of the OSS D-Day cache; but I see no such files from those posts, and I see nothing on AtariWiki.org.

[Note: It's late here; so, maybe I'm missing something... I just glanced over the files.]

 

[+kheller2]

It would be amazing if this were C, but I doubt it.  Reading up on Wilkinson’s Insight Atari articles it reads as if OSS has already fixed the bugs in one of the numerous “A” revisions they did for Atari (but that isn’t the one made into ROMs), someone read the published source code and tried fixing things that didn’t need fixing “B” and then finally someone fixed the fixes by NOPing them “C”.    This makes me wonder if there is a good A out there or if we could fix A properly.  

[reifsnyderb]

3 minutes ago, kheller2 said:

It would be amazing if this were C, but I doubt it.  Reading up on Wilkinson’s Insight Atari articles it reads as if OSS has already fixed the bugs in one of the numerous “A” revisions they did for Atari (but that isn’t the one made into ROMs), someone read the published source code and tried fixing things that didn’t need fixing “B” and then finally someone fixed the fixes by NOPing them “C”.    This makes me wonder if there is a good A out there or if we could fix A properly.  

Having a properly fixed version of Atari BASIC would be fantastic.  Revision D?

[+kheller2]

@MrFish can you upload those source files when you get a moment.  @Kr0tki maybe can make an Atari BASIC source distribution so we can compile various versions.  While not as interesting as the OS versions for sure, it still would be educational. 

[+kheller2]

There are some sources here: 

 

In the atarirom pack and the Basic Source zip.  I have not compared them but they are both from @re-atari

 

[+MrFish]

6 hours ago, kheller2 said:

It would be amazing if this were C, but I doubt it.  Reading up on Wilkinson’s Insight Atari articles it reads as if OSS has already fixed the bugs in one of the numerous “A” revisions they did for Atari (but that isn’t the one made into ROMs), someone read the published source code and tried fixing things that didn’t need fixing “B” and then finally someone fixed the fixes by NOPing them “C”.    This makes me wonder if there is a good A out there or if we could fix A properly.  

 

5 hours ago, kheller2 said:

@MrFish can you upload those source files when you get a moment.

 

I just had a quick look at things here this morning.

 

I converted all the Mac/65 tokenized files to text files. Comparing just the size of these text files (combined) to the Rev. A text file we have...

 

Rev. A text = 370 KB

Mac/65 text = 227 KB

 

So, it looks like they may not be complete (I doubt using Mac/65 could reduce the sources that much?). Maybe for a version to patch Rev. A?

 

Anyway, I'll upload here, so people who know exactly what to look for can figure out what they are.

 

The ZIP contains the original disks that I'm working from (Mac/65 tokenized files),

then the tokenized files pulled from the disks (*.m65),

and then the text file versions (*.mac).

 

Atari BASIC - Source.zip

 

[Mark2008]

1 hour ago, reifsnyderb said:

Having a properly fixed version of Atari BASIC would be fantastic.  Revision D?

just curious as to why?  in my view if writing code for Atari basic, I would want to make it compatible with revision C - I would want to keep the bug in the cart and workaround it in code, rather than do a fix through a patch to basic.

Simply because few people will ever change the rom in their computer, in my view.

 

 I guess my thoughts are about all the cool projects that didn't catch on, even veronica didn't get uptake.

 

Altirra basic's position as a default in the altirra emulator has given it some uptake...well, to me personally I view Altirra basic as essentially the next Atari basic..  I know it isn't a patch, but a rewrite, I am just talking in terms of adoption, it has gotten some traction, which is no small feat.

[_The Doctor__]

BASIC should be fixed, patched what have you. People can always use a cartridge or replace what is in their machine, just like Atari computer enthusiasts and users did back in the day. This is part of the experience.

 

Edited December 21, 2022 by _The Doctor__

[reifsnyderb]

48 minutes ago, Mark2008 said:

just curious as to why?  in my view if writing code for Atari basic, I would want to make it compatible with revision C - I would want to keep the bug in the cart and workaround it in code, rather than do a fix through a patch to basic.

Simply because few people will ever change the rom in their computer, in my view.

 

 I guess my thoughts are about all the cool projects that didn't catch on, even veronica didn't get uptake.

 

Altirra basic's position as a default in the altirra emulator has given it some uptake...well, to me personally I view Altirra basic as essentially the next Atari basic..  I know it isn't a patch, but a rewrite, I am just talking in terms of adoption, it has gotten some traction, which is no small feat.

My thought on this is admittedly conflicted, but is more of a matter of compatibility.  On my 600XL, which is my main Atari computer now, I have it upgraded to V. 4 of the OS and BASIC R. C.  At one time I was running Altirra BASIC in the computer and it worked great.  I would have kept Alitirra BASIC installed but the problem I encountered is that it's too fast.  I was playing the text version of the Star Trek like program "Enterprise" and the sound...although limited...was skewed.  This, admittedly, goes back to the poor practice of people timing their programs with the program execution speed on a given computer as opposed to having them compensate for the computer speed.  (Hence the "Turbo" button on early AT compatible systems.)  So I put Atari BASIC Rev. C. back in.  I could have found the right loop in the game and adjusted it for Altirra BASIC.  But it just didn't feel right as the game is, in some ways, historical.  Quite honestly, this concern is what has kept me from figuring out how to patch the OS with faster floating point math pack as well.  If breaking the speed compatibility of existing software wasn't a concern I would absolutely be running Altirra BASIC as I believe it to be the best version of BASIC, that can be squeezed into 8k, on an Atari.

 

So, if speed compatibility wasn't an issue, this system would be upgraded to OS V.4 w/Fast Chip for the math pack and Alitirra BASIC. 

 

So, that's my thought as to why a "Revision D" of Atari BASIC may be useful....if it's possible to do so.

 

 

 

 

Edited December 21, 2022 by reifsnyderb

[Mark2008]

32 minutes ago, reifsnyderb said:

 

 

So, that's my thought as to why a "Revision D" of Atari BASIC may be useful....if it's possible to do so.

 

 

 

 

Gotcha, that makes sense...so in this case the stack size of the Basic rev. A parser, essentially supports 21 entries, rather than 20, so the question is if one can return it to 21 without impacting execution speed - even an improvement would not be desirable...

 

just chatting....I don't usually program in basic, but I am doing a port of a TI-99 4/A basic game, and so as it happens I am working with a game that partially has timings that work off the clock and partially has basic loop timing... not that it had any for-next style delays, but dependent upon the execution speed of the code, nevertheless, as I found out.   TI documented the code for the motion subroutine as "very slow" for values near zero and "a value far from zero is very fast".  Not being happy with the vagueness of that, I modded the program to allow me to time the velocity in pixel distance/per second. To my surprise, the mod, which was to remove 3 lines of code, caused the rest of the program to work so dramatically faster, that the game was completely unplayable.  Not that I needed to play it in that condition, but omg, 3 lines of code that barely did anything.  any removal or additions - actually ruins the timing of the game.   whew.....I had forgotten just how slow basic is - it's a miracle people got work done.

 

 

 

 

 

[_The Doctor__]

A purist would simply have cartridges or an OS switcher, perhaps a 32 in 1, or flash slots. Remember official Atari BASIC is not just A B C, but also AMSB 1 and 2.

There is nothing wrong with a speed up so long as it's selectable to turn it off and be close to normal basic speeds a tad faster still wouldn't hurt anything in normal mode, but slower than the slowest variant would be a big issue.

 

 

Edited December 21, 2022 by _The Doctor__

[+kheller2]

2 hours ago, Mark2008 said:

just curious as to why?  in my view if writing code for Atari basic, I would want to make it compatible with revision C - I would want to keep the bug in the cart and workaround it in code, rather than do a fix through a patch to basic.

Simply because few people will ever change the rom in their computer, in my view.

 

 

I'm not talking about fixing a divide by zero, or increasing the speed.  I'm talking about the fact you really can't program in Rev B w/o locking up your computer or eventually corrupting your code.  The bugs relate to editing code and saving code -- as a young programmer, this infuriated me to no end how often I would hit the damn bug that locked up the computer.  There are some other coding bugs in A that are discussed in the source book.

 

Having said that, I'm sure there are some BASIC programs that do really bad illegal things right to spots in the binary code similar to the OS B vs XL issues.

[+kheller2]

I did mange to compile the BASIC's in this archive: 

 

The compiled C is binary identical to the C ROM.  I didn't not check A or B.  But, I did notice that that listing output between A and B seems to have a lot more changes than B to C (which is to be excepted) but I didn't analyze all the changes. 

 

[800_Rocks]

Also FYI... unless you just like typing-in programs... all the ANALOG Magazine disks have been imaged (to .ATR files).  There are found in many places but I find them in the Holmes->Holmes3->ANALOG directory at this link.

 

http://ftp.pigwa.net/stuff/collections/holmes cd/index.html

[phaeron]

Dug into the rev. B ROM and figured out the change that caused the problem -- it's due to a bug fix for nested unary operators.

 

The rev. A parser has this production for expressions:

exp := (exp) | unary exp | nv

 

What this says it that an expression can be either another expression grouped by parentheses, an expression prefixed by a unary operator, or a numeric value. Problem is that this allows repeated unary operators, e.g. --X. It parses fine, but the expression evaluator can't handle it and doesn't evaluate it properly at runtime. Thus, in rev. B, the production was split to prevent nesting unary ops:

 

exp := unary exp2 | exp2
exp2 := (exp) | nv

 

However, the extra production requires an extra stack level when parsing expressions. Since the PRINT statement above is just barely within the limits on rev. A, it goes one over on rev. B and fails to parse.

 

[_The Doctor__]

off by one errors for the win!

[Rybags]

Early revisions had the "bug" where a long line could overflow and hit page 6 - was this ever fixed in Rev C?

I think it only happens if doing ENTER from another device which allows exceeding the 120 characters normally limited by E:

[phaeron]

Nope, rev. C still issues a CIO read to $0580 with length $00FF any time it needs line input.