Atari BASIC, was it intended as an interim BASIC?

[JamesD]

Has anyone tried these benchmark programs on Digital Research CB80 on a 4 MHz Z80 CP/M computer? It would be interesting to see how that compiled BASIC performs in comparison to the 6502.

This was the result published in the magazine. I think there are only interpreters.

https://archive.org/stream/creativecomputing-1984-03/Creative_Computing_v10_n03_1984_Mar#page/n7/mode/1up

[thorfdbg]

 

I'm going by your own words in the following post, where I reported the issue and your suggestion was to "use a fixed math pack":

http://atariage.com/forums/topic/242489-asking-for-basic-beta-testing/?p=3317044

 

As far as I know, Atari is not planning on releasing new revisions of the OS-B/XLOS math pack with further fixes.

 

This issue still appears to occur in Basic++ 1.03 when running under the XL/XE OS version 2 and Atari++ 1.80 -- PRINT --0 and PRINT -(0) both produce -<8. You are correct that this issue was present in Atari BASIC revision A, but it was fixed in revision C. I assume that with your focus on quality and correctness that if you were intending to support OS-B and XL/XE that you would be intending to at least match rev. C's fixes despite the bugs in the Atari's math pack, even if there are other ways this can occur that are harder to fix. If this is planned in the future and was merely miscommunicated or omitted, then I apologize. If backporting or reimplementing the workarounds is not planned and Basic++ relies by design on the Os++ math pack to work correctly here, then I don't see how you can say that Basic++ supports running on the stock operating system.

 

 

I never suggested that the checks should go away. You stated my interpreter was faster because I omitted those checks, and that is false. If Atari BASIC is spending a lot of time doing those checks then perhaps those checks can be optimized.

Atari is surely not doing anything about it. Whatever Atari is these days....

 

PRINT --0 is simply printing 0, actually on any version of the Os and math pack. If it parses. Basic B and C refuse parsing, as part of a "poor men's approach" to fix up the broken priorities of the unary minus. The problem appears if you print a "-0", and the question should rather be "where is the bug?". You believe it is a Basic bug because it does not check for zero before negating. I rather say it is a bug in the math pack not printing some BCD representation correctly. Now what?

 

If you believe that Basic C "fixed this", I believe you believe wrong. (-: Basic C did nothing about the math pack - how could it? It's in a completely different ROM area. I don't know exactly how Atari worked around this problem, the sources of B and C remained unpublished - possibly by modifying the unary minus operator. However, that's not necessarily the only source that could create a "-0", so the problem remains, it's just hidden. I like to fix bugs at their origin and not work around them.

 

Anyhow, Basic++ 1.04 includes a workaround (but without giving up -0) against the math pack bug. It also includes a couple of other fixes I found during the last weeks, including one pretty embarrasing bug that broke KAISER (embarrising because I should have known better). I can only suggest to test any Basic implementation with this mes^H^H^H game. It doesn't work on TurboBasic either.

 

FOR-NEXT is a bit faster, though in real-life programs, little difference can be noticed, except for empty loops. In any other case, the loop body is dominating anyhow. The double-pop-and-push in NEXT is gone, and there is an evaluation short-cut in the numerical comparison, amongst some other minor improvements. And another embarrasing bug in the memory allocator. Outch for that, too.

[fujidude]

Priorities differ. I personally do not want to give up STOP/BREAK and CONT, because it impacts compatibility. There are a couple of programs that use a POKE 842,13 to modify the program on the fly, and that depend on working STOP and CONT. If you can get away with limited STOP/CONT support, there is TurboBasic: It does not allow to STOP a FOR-NEXT loop safely and continue the loop.

 

Development priorities in Basic++ are: a) be correct. Avoid bugs, use proper algorithms, proper math. b) be compatible. Atari Basic programs should run correctly on Basic++, unless they depend on a), c) be fast, unless it conflicts with a) or b). d) add useful new features unless they conflict with a) to c).

 

That might be not your list of priorities, but I prefer "rather bug free than fast".

 

...

 

I afraid that "FAST" is currently not a run-time option. There is not enough ROM-space to allow such a function.

 

My 2 cents were really just a commentary on BASIC interpreter design in general, not specifically BASIC++. In other words, I think it might have been better if Atari had been more speed oriented on BASIC. Comparability with Atari BASIC I agree is an important goal. And since Atari BASIC does allow for stop, edit, continue (with it's inerrant checks and logic), it makes sense that BASIC++ would need to do so too.

 

As to FAST on BASIC XL/XE... I was actually kind of asking if that is in fact what they are doing, offering a selectable approach to a speed vs. capability. And yes, I understand that those are using much more than 8K to do what they do.

[thorfdbg]

 

My 2 cents were really just a commentary on BASIC interpreter design in general, not specifically BASIC++. In other words, I think it might have been better if Atari had been more speed oriented on BASIC. Comparability with Atari BASIC I agree is an important goal. And since Atari BASIC does allow for stop, edit, continue (with it's inerrant checks and logic), it makes sense that BASIC++ would need to do so too.

 

As to FAST on BASIC XL/XE... I was actually kind of asking if that is in fact what they are doing, offering a selectable approach to a speed vs. capability. And yes, I understand that those are using much more than 8K to do what they do.

The priorities for Atari might have been different: Get a basic done that works in the machine, and get it done fast. Everything else was, as far as I read it, secondary. The quality did not matter much - I believe Basic was more considered a "sales argument" than a real product. "Here, look, you can program our machine! But get our games, too.".

 

So in the end, it did not matter how fast or good Basic was. It was a rush job anyhow.

[thorfdbg]

The 1.04 version of Basic++ can be found here, btw:

 

http://atariage.com/forums/topic/242489-asking-for-basic-beta-testing/page-2

[JamesD]

The priorities for Atari might have been different: Get a basic done that works in the machine, and get it done fast. Everything else was, as far as I read it, secondary. The quality did not matter much - I believe Basic was more considered a "sales argument" than a real product. "Here, look, you can program our machine! But get our games, too.".

 

So in the end, it did not matter how fast or good Basic was. It was a rush job anyhow.

Well, if they did contract Microsoft to do it and Gates didn't deliver, it would have required a short development time to have it ready to show.

Once they had a working product and found it worked well they decided not to spend any more money on it.

 

Really, they should have asked for a speed improvement when they had the bug fixes made.

I think it would have resulted in one less talking point for buying something else (slow BASIC).

 

[Lynxpro]

The BASIC V2 in the C64 was originally licensed for the PET years earlier. The story goes- for a one time flat fee regardless of the number of machines sold. For this reason, the exact same version was released on the VIC and C64... No additional royalty payments, and no hardware customization.

 

When the 128 came along, they did re-license it and add some machine-specific features.

 

There's a famous story - which may be just a tall-tale - of Jack Tramiel out-negotiating Bill Gates to where Bill basically settled for 1 penny per Commodore computer sold.

 

So in essence, Jack Tramiel is perhaps the only business person who screwed over Bill Gates while Atari was the only company to "fire" Bill Gates, per se.

[Lynxpro]

FWIW, Microsoft BASIC searches from the start or current line when it looks for line numbers so it has the same type of bottleneck.

Ok, I have ABC confused with something else then.

 

The typed variables would only be for a compiler and the interpreter does not need them.

Type definitions could be in REMs in the first few lines so the interpreter doesn't see any difference.

 

FWIW, BASIC-09 on the CoCo 3 completed AHL's benchmark in 6 seconds. It is an "I-Code" interpreter (similar to P-Code) and the fastest CoCo benchmark for Microsoft BASIC was close to a minute. Both were on a 6309 CPU. Now, that BASIC was designed to be compiled so that is sort of a best case, but there's no reason an Atari compiler couldn't do better than what is out there.

 

 

But a Motorola 6809 outperforms the 6502 or 6510...

[tschak909]

This is partially right. (re: Commodore BASIC)

 

Commodore DID license Microsoft's basic.

 

Ric Weiland had been porting Microsoft BASIC from the 8080 to the 6502, for his KIM-1, as a side project. Bill Gates had found out about it, and told him to quietly sell it, as he did not like the 6502 at all (he was particularly vocal about the paltry 8-bit stack). So when Commodore came to license the BASIC, Weiland was told to get a licensing deal, and just forget about it.

 

At the final negotiations for licensing, where Bill Gates and Jack Tramiel were present, Gates tried one last time to negotiate a license, to which Tramiel simply replied, "no thank you, I'm already married." At which point, a fixed cost was negotiated for the code-base, and any further modifications would be decided on a separate basis.

 

Microsoft's Ric Weiland worked with Commodore engineers (mainly John Feagans, and Leonard Tramiel) to adapt the 6502 BASIC, which had been running already on the KIM-1, and patched it thusly:

 

(this is all from memory, so please, don't shoot me)

 

* Convert to a ROMable code-base.

* Get rid of the ROR workaround needed on MOS 6502 processors made before 1976, a la the early KIM-1's and the KIM-1 BASIC.

* Utilize I/O routines which would become eventually the KERNAL

* Convert from 32-bit floating point (6 digits), to 40-bit floating point (9 digits)

* remove MEMORY SIZE? message, all memory is found and reserved for BASIC

* remove Microsoft BASIC (and Gates/Weiland authorship text) banner

* replace banner with Commodore banner.

* remove superfluous TERMINAL WIDTH? prompt, as terminal is assumed to always be size of screen.

* remove WANT ATN-COS-SIN? transcendental functions, as these were there to conserve RAM space when Microsoft BASIC was loaded into RAM, as it was made ROMable, this became superfluous.

* Added SYS statement, alongside USR function for user system calls.

* Added Commodore specific I/O functions that called IEEE-488 calls in the nascent KERNAL, LOAD, RUN, OPEN#, INPUT#, etc.

* change OK prompt to READY.

 

Leonard Tramiel had also found a bug during this time (after searching for the cause of a very peculiar crash for most of the summer), that had been left behind by the initial 8080 to 6502 code translation, namely that code that used the BCD features of the 6502 (SED/CLD instructions), did not correctly CLD (clear the decimal flag) after finishing, which would cause the BASIC to go way off into the weeds.

 

Microsoft was later contacted in 1978, by Commodore, to revise the BASIC, in which:

 

* fixes that had been made for Apple's variant (Applesoft Basic 1.0) were also applied here, namely: input buffer pointer bugfixes, changing memory test pattern to a more defacto $55/$AA pattern, number storage optimizations, DEF FN (user functions) error handling improvements, etc.

* the WAIT 6502 easter egg was added, which placed an XOR obfuscated MICROSOFT! string in memory, along with some re-used code in the math routines to decrypt it and display it.

 

After this point, Microsoft's involvement with Commodore's BASIC ended, until the license was re-negotiated in 1985.

 

In between this time, Commodore released versions 3.0 and 4.0 of the BASIC, which expanded the KERNAL rom, and added lots of I/O convenience functions, such as:

HEADER "MYDISK",I2A,D0

instead of

OPEN #15,8,15,"N:MYDISK,2A":CLOSE 15

to format a disk.

 

BASIC 3.0 was used in the PET/CBM 3000 units that were made mostly in Europe, and BASIC 4.0 was used in the PET/CBM 4000 and 8000 and CBM-II (B/P128, 5xx, 7xx, blahblah) units.

 

According to VIC-20 and Commodore-64 systems designer Bob Russell, the BASIC/KERNAL 2.0 ROMs were used in the VIC-20 to keep the system cost down (as the BASIC 4.0 requires considerably more ROM space than the 2.0 ROM does.). Using Basic 4.0 would have probably resulted in an even more awkward memory map than what ultimately made it to production.

 

The Commodore 64 used the BASIC 2.0 ROM...because of minimizing the ROM space again. They were constantly trying to fight for ROM space to balance out system features and cost (and in the end, they only had a few remaining bytes left (in which, they put their initials, BBRY)

 

The other two versions of Commodore BASIC are the 3.5 ROM, which was used in the TED machines, 3.6, which was used in the Commodore LCD machines, and 7.0, which was used in the Commodore 128, and 11.0, which was used in the C65), All of which were done under the stewardship of Terry Ryan, who added all sorts of structured constructs and goodies.

 

So...yeah, this is the canonical truth, all laid out, on the Commodore BASIC, all of it verifiable.

 

-Thom

[JamesD]

 

But a Motorola 6809 outperforms the 6502 or 6510...

Yes, but it shouldn't be by 4 or 5 times.

[ZylonBane]

That reminds me, Atari BASIC's machine language interface was pretty sweet compared to its contemporaries. The USR function allowed you to pass an arbitrary number of arguments to a machine language function (which got pushed on the stack as 16-bit integers, making them very easy to deal with), and could return a value to the BASIC environment. This allowed developing some really powerful helper routines.

 

Commodore and Apple BASICs were limited to passing a single argument, and AFAIK it was passed as a float, requiring the receiving routine to convert it to an int.

[JamesD]

That reminds me, Atari BASIC's machine language interface was pretty sweet compared to its contemporaries. The USR function allowed you to pass an arbitrary number of arguments to a machine language function (which got pushed on the stack as 16-bit integers, making them very easy to deal with), and could return a value to the BASIC environment. This allowed developing some really powerful helper routines.

 

Commodore and Apple BASICs were limited to passing a single argument, and AFAIK it was passed as a float, requiring the receiving routine to convert it to an int.

I think that depends on where you made the call in ROM. You may have to write to some specific addresses (usually page zero) that a subroutine expects parameters to be at but that's about it.

[MikeFulton]

So in the end, it did not matter how fast or good Basic was. It was a rush job anyhow.

 

No, it really wasn't. It was a job done quickly, which isn't at all the same thing. The developer turned in the finished product almost 4 months before the deadline. There was plenty of time to do more, if more had been required.

 

You have to keep in mind that all of these flaws and shortcomings that are mentioned in this thread are coming 35 years later with enormous amounts of actual operation in the field. If you think all these things were so well known and obvious at the end of 1978, you're kidding yourself.

[thorfdbg]

 

No, it really wasn't. It was a job done quickly, which isn't at all the same thing. The developer turned in the finished product almost 4 months before the deadline. There was plenty of time to do more, if more had been required.

 

You have to keep in mind that all of these flaws and shortcomings that are mentioned in this thread are coming 35 years later with enormous amounts of actual operation in the field. If you think all these things were so well known and obvious at the end of 1978, you're kidding yourself.

Oh, sure, the bugs we detect today were probably not known in 1978, for sure. You should also not underestimate the work Phaeron and/or I put into this, namely finding deficiencies of the Atari Basic and trying to fix things. It's spare time, unpaid, and if anyone would ever account the amount of time that went into these projects, Atari Basic would have been much too expensive.

 

But anyhow, even in 1978 they had something called "quality assurance" and "testing". If SMI would have spend more months on the project, a couple of the problems would have been found (and actually, had been found, Atari used a preliminary ROM and went with that for production!). But, you see, if you're in the position of either taking the money for a "well enough project", or spend more time on a project for getting *less* money, plus blocking time of your valuable engineers, what would you do, as management?

 

It's called business. Atari Basic was "well enough" for what Atari was asking for, and they did not request a specific execution speed, so well, that's what you get. "Bad code runs the industry". (-:

[JamesD]

 

No, it really wasn't. It was a job done quickly, which isn't at all the same thing. The developer turned in the finished product almost 4 months before the deadline. There was plenty of time to do more, if more had been required.

 

You have to keep in mind that all of these flaws and shortcomings that are mentioned in this thread are coming 35 years later with enormous amounts of actual operation in the field. If you think all these things were so well known and obvious at the end of 1978, you're kidding yourself.

Are you talking about before the release date or do you know the actual contract deadline?

Keep in mind that there would be some lead time required to put this in cheaper ROMs rather than EPROMs and in 1978-1979 that would be a little longer than now

[MikeFulton]

Are you talking about before the release date or do you know the actual contract deadline?

Keep in mind that there would be some lead time required to put this in cheaper ROMs rather than EPROMs and in 1978-1979 that would be a little longer than now

The project deadline specified in the contract was mid April '79 but it was turned in to Atari in Dec '78, just after they finalized the contract.

[MikeFulton]

Oh, sure, the bugs we detect today were probably not known in 1978, for sure. You should also not underestimate the work Phaeron and/or I put into this, namely finding deficiencies of the Atari Basic and trying to fix things. It's spare time, unpaid, and if anyone would ever account the amount of time that went into these projects, Atari Basic would have been much too expensive.

 

But anyhow, even in 1978 they had something called "quality assurance" and "testing". If SMI would have spend more months on the project, a couple of the problems would have been found (and actually, had been found, Atari used a preliminary ROM and went with that for production!). But, you see, if you're in the position of either taking the money for a "well enough project", or spend more time on a project for getting *less* money, plus blocking time of your valuable engineers, what would you do, as management?

 

It's called business. Atari Basic was "well enough" for what Atari was asking for, and they did not request a specific execution speed, so well, that's what you get. "Bad code runs the industry". (-:

I'm not claiming they couldn't have done better, just that it wasn't a "rush job"

[kool kitty89]

 

There's a famous story - which may be just a tall-tale - of Jack Tramiel out-negotiating Bill Gates to where Bill basically settled for 1 penny per Commodore computer sold.

 

So in essence, Jack Tramiel is perhaps the only business person who screwed over Bill Gates while Atari was the only company to "fire" Bill Gates, per se.

 

I'd believe that, or at least something close to it (probably a bit more in the details and also not just a flat $0.01 across the board from day one, but I'm sure it'd be an interesting story to see).

 

It appears Tramiel did later get a license for UNIX (from AT&T -so not the same BSD variant Atari Inc had been playing with for the Amiga chipset and their in-house 68000 machines) for $10 a unit while developing the RBP (ST) but it didn't end up being a practical OS for the 520ST as the tweaks to the MMU to allow for page fault recovery (and thus memory protection) couldn't be added in time for production. The features were added to the MEGA ST but the UNIX contract had lapsed by that point. (those features might have been used for MiNT though, given anything short of a TT030 lacked an onboard Motorola MMU)

 

http://www.dadhacker.com/blog/?p=1383

 

Would've been neat if they'd implemented a Multi-TOS variant earlier on for the MEGA series and had a leg-up on the Amiga's unprotected multitasking environment. (the STe should have had that feature too, not sure if later model STf/fms did too)