4 ms·

There was a bug in the TRS-80 basic (which was indeed Microsoft). It had an "on x goto" command that allowed the program to move to different lines depending on

by Starwatcher2001 6y ago

There was a bug in the TRS-80 basic (which was indeed Microsoft). It had an "on x goto" command that allowed the program to move to different lines depending on the value of a variable: ON X GOTO 200,300,400,500 depending if x=1, x=2,x=3... They'd obviously used the same parser for the standard "If a=1 then goto 200" construct, which allowed an undocumented shortcut of "If a=1, 200" which a few people noticed and started using. However, a later model fixed this, which broke a number of programs.

C1sc0cat 6y ago
ooh I never worked on TRS80's - so they had a version of the Arithmetic IF :-) I could have Told BillG that was bad idea back when I was 19
- ddingus 6y ago
  x = x + (x < 5) :D No If needed. Atari Basic would allow crazy things like: 10 Goto ((x < 5)*100) + 50 Goes to either line 50 or 150, depending on the comparison result being 1, or 0) Or... Goto (100*x) Faster On goto with no checking, lol. Bill Gates was not involved with the original Atari Basic. That could be purchased on a cartridge for running MS Basic programs.
  - int_19h 6y ago
    Did Atari BASIC use 1 for TRUE? Most BASICs used -1 (i.e. all bits 1), because this allowed the same operators to work for both bitwise and Boolean logic, in the absence of a dedicated Boolean data type.
    - ddingus 6y ago
      https://atariwiki.org/wiki/Wiki.jsp?page=Boolean%20Logic%20in%20BASIC https://atariwiki.org/wiki/Wiki.jsp?page=Boolean%20Logic%20i... Yes, it used 0 and 1. And it did not contain bitwise ops. Those were quite the surprise! My first efforts were in Applesoft. Computers at school. Got an Atari machine and programmed the crap out of it. Wrote my own assembler, a few games, etc... Then I got an Apple and finding them in Applesoft was a nice surprise! Prior to that, I thought they were an assembly only thing. The trade off in the Atari basic was doing things mathematically was pretty easy and it generally, but not always, was faster. A few of us wrote fairly complex programs with basically no if statements. Kind of a fun way to think about things back then. I much prefer -1 and 0 and the bit ops, frankly. Internally, I remembered this kind of thing as "really fucking true" as in every bit better signal, or it's false!
      - int_19h 6y ago
        The problem with using bit ops as logical is that they don't short circuit. Although it was unfortunately common even in languages that had proper Booleans at the time - e.g. standard Pascal didn't have it, and Turbo Pascal required a compiler directive/switch to enable it, which few even knew of. So it feels worse in retrospect than it actually was back then. On the other hand, one thing that BASIC still has to this day (in VBA) that no other language I can think of does, is bitwise equivalence (EQV) and implication (IMP) operators. Furthermore, since VBA has a Boolean data type, these operators are also available for Booleans; implication comes in handy sometimes.
        ddingus 6y ago
        Not sure what you mean by short circuit. I had no idea about those VBA features. Will read about them. Having the bit ops themselves is a very strong feature. My simple assembler would definitely been faster and simpler with them. Graphics, some math, all benefit. People would make little language extensions or callable machine language routines to make the bit ops available. In basics with bit ops, and the -1 as true: X = 100 & (y = 5) Atari X = 100 * (y = 5) Not doing the multiply seems like a net gain in a limited CPU too. That basic did not really have types, like MS basic did. Pretty much floating point only. Interestingly, basics that have the bit ops do not always allow the expressions in a goto. Or, could just be my own memory, or lack of trying. Not really needed. In fact, outside of trying to optimize, or just explore the language, the only case that made real sense was a sort of jump table making good use of line numbers like one would do with memory addresses in assembly. Say, branching directly on a checked or masked character value. And the spiffy thing was making pseudo labels. Put line numbers into variables and use them like labels. Foo = 1000 Goto Foo Overall though, it was a weird little basic. It nicely supported the machine, and the device independent I/O system in the OS ROM, but was slow otherwise. This guy has actually made an N: driver meaning Atari Basic programs written long ago can operate across the Internet today. Lol, cool old stuff. https://m.youtube.com/user/tschak909 https://m.youtube.com/user/tschak909
        int_19h 6y ago
    - mnaydin 6y ago
      There were no bitwise operators in the Atari BASIC, and numbers in the tokenized program were always stored as floating-point numbers in BCD (Binary Coded Decimal) format.
int_19h 6y ago
This was legal in BASIC from the very first versions of the language: IF a=1 THEN 200 and when they added ON..GOTO, they basically made these two mirrored syntactically. So you could do: IF a=1 GOTO 200 ON a THEN 100,200,300 (I suspect it was simply treated as identical token?)

C1sc0cat 6y ago

ooh I never worked on TRS80's - so they had a version of the Arithmetic IF :-) I could have Told BillG that was bad idea back when I was 19

ddingus 6y ago
x = x + (x < 5) :D No If needed. Atari Basic would allow crazy things like: 10 Goto ((x < 5)*100) + 50 Goes to either line 50 or 150, depending on the comparison result being 1, or 0) Or... Goto (100*x) Faster On goto with no checking, lol. Bill Gates was not involved with the original Atari Basic. That could be purchased on a cartridge for running MS Basic programs.
- int_19h 6y ago
  Did Atari BASIC use 1 for TRUE? Most BASICs used -1 (i.e. all bits 1), because this allowed the same operators to work for both bitwise and Boolean logic, in the absence of a dedicated Boolean data type.
  - ddingus 6y ago
    https://atariwiki.org/wiki/Wiki.jsp?page=Boolean%20Logic%20in%20BASIC https://atariwiki.org/wiki/Wiki.jsp?page=Boolean%20Logic%20i... Yes, it used 0 and 1. And it did not contain bitwise ops. Those were quite the surprise! My first efforts were in Applesoft. Computers at school. Got an Atari machine and programmed the crap out of it. Wrote my own assembler, a few games, etc... Then I got an Apple and finding them in Applesoft was a nice surprise! Prior to that, I thought they were an assembly only thing. The trade off in the Atari basic was doing things mathematically was pretty easy and it generally, but not always, was faster. A few of us wrote fairly complex programs with basically no if statements. Kind of a fun way to think about things back then. I much prefer -1 and 0 and the bit ops, frankly. Internally, I remembered this kind of thing as "really fucking true" as in every bit better signal, or it's false!
    - int_19h 6y ago
      The problem with using bit ops as logical is that they don't short circuit. Although it was unfortunately common even in languages that had proper Booleans at the time - e.g. standard Pascal didn't have it, and Turbo Pascal required a compiler directive/switch to enable it, which few even knew of. So it feels worse in retrospect than it actually was back then. On the other hand, one thing that BASIC still has to this day (in VBA) that no other language I can think of does, is bitwise equivalence (EQV) and implication (IMP) operators. Furthermore, since VBA has a Boolean data type, these operators are also available for Booleans; implication comes in handy sometimes.
      - ddingus 6y ago
        Not sure what you mean by short circuit. I had no idea about those VBA features. Will read about them. Having the bit ops themselves is a very strong feature. My simple assembler would definitely been faster and simpler with them. Graphics, some math, all benefit. People would make little language extensions or callable machine language routines to make the bit ops available. In basics with bit ops, and the -1 as true: X = 100 & (y = 5) Atari X = 100 * (y = 5) Not doing the multiply seems like a net gain in a limited CPU too. That basic did not really have types, like MS basic did. Pretty much floating point only. Interestingly, basics that have the bit ops do not always allow the expressions in a goto. Or, could just be my own memory, or lack of trying. Not really needed. In fact, outside of trying to optimize, or just explore the language, the only case that made real sense was a sort of jump table making good use of line numbers like one would do with memory addresses in assembly. Say, branching directly on a checked or masked character value. And the spiffy thing was making pseudo labels. Put line numbers into variables and use them like labels. Foo = 1000 Goto Foo Overall though, it was a weird little basic. It nicely supported the machine, and the device independent I/O system in the OS ROM, but was slow otherwise. This guy has actually made an N: driver meaning Atari Basic programs written long ago can operate across the Internet today. Lol, cool old stuff. https://m.youtube.com/user/tschak909 https://m.youtube.com/user/tschak909
        int_19h 6y ago
  - mnaydin 6y ago
    There were no bitwise operators in the Atari BASIC, and numbers in the tokenized program were always stored as floating-point numbers in BCD (Binary Coded Decimal) format.

int_19h 6y ago

This was legal in BASIC from the very first versions of the language: IF a=1 THEN 200 and when they added ON..GOTO, they basically made these two mirrored syntactically. So you could do: IF a=1 GOTO 200 ON a THEN 100,200,300 (I suspect it was simply treated as identical token?)