Who created TI-99 BASIC, TI or MS?

[+hloberg]

5 hours ago, OLD CS1 said:

We getting biblical around here?

as long as we don't start burning people at the stake for heretical MS teachings on TI BASIC genesis story, I think we're OK. ? ?

[Airshack]

http://www.allbasic.info/forum/index.php

[+acadiel]

You guys should read the TI source code for the console GROMs.. some fun stuff in here.

 

Console GROM Source Code 1-Monitor 1982-08-25

Console GROM Source Code 2-Cassette 1982-08-25

Console GROM Source Code 3-EDIT-HC 1982-08-25

Console GROM Source Code 4-PSCAN 1982-08-25

Console GROM Source Code 5-FLMGR 1982-08-25

Console GROM Source Code 6-EXEC 1982-08-25

Console GROM Source Code-Monitor Page 33

 

 

console source.zip

[RXB]

This GPL code looks exactly like my GPL XB source code I use in RXB, I got these from Jim Lesure who got it from a Texas Instruments Warehouse.

 

Thanks!

 

Rich

 

P.S. I also got the XB ROM source too.

Edited August 28, 2019 by RXB

[The Usotsuki]

It doesn't look or feel like MS BASIC at all, can't imagine why people would think it was.

[carlsson]

Someone suggested that TI would have ordered a Dartmouth based BASIC, perhaps similar to what e.g. DEC used on the PDP line, to be developed by someone on the payroll from Microsoft, instead of ordering a version of Microsoft's own BASIC which by then had at least 2-3 years on the market and was beginning to get popular among other systems. Perhaps inner routines like parser or floating point library could be traced to Microsoft's implementations even if syntax is quite a bit different. However I would think Microsoft may have argued for implementing their own version fully unless of course TI offered them gobsmacks many dollars for doing exactly what they were told to do. Then again TI could just as well have hired the designated programmers instead of outsourcing it, if they were willing to spend a lot of money to have it done.

[Tursi]

On 8/28/2019 at 4:58 PM, The Usotsuki said:

It doesn't look or feel like MS BASIC at all, can't imagine why people would think it was.

You have to do the required reading to get there.

 

Whether you believe them or not is another thing, but it shouldn't be that hard to see why there are two camps.

 

[JB]

On 8/27/2019 at 12:19 PM, hloberg said:

please supply me the page numbers for that mention in the book. I'm using it as one of the sources in the WIKI article. And before anyone says that it might be apocrypha I will have other sources from TI & interviews as well.

The page numbers you're asking for are actually in the picture of the book.

But between the book's apparent lack of any bibliography and the existence of multiple large errors in just those two pages, I would be very hesitant to use any part of that book as a source for ANYTHING. Every claim the author makes is suspect, and there's no way to fact-check him without actually doing the research yourself(at which point you may as well just cite the sources used in researching the book's accuracy and skip the book entirely).

 

I'd wager the author's source for TI BASIC being written by MS was actually the very Wikipedia article we're discussing the (almost-certain) inaccuracy of, but since he didn't offer a source, there's no way to know.

https://m.xkcd.com/978/ is relevant here.

 

 

On 8/28/2019 at 6:58 PM, The Usotsuki said:

It doesn't look or feel like MS BASIC at all, can't imagine why people would think it was.

Because Wikipedia said so, never mind that the article was clearly written by someone with very little knowledge of the platform(seriously, last time I looked the 99/4a article was just AWFUL).

[+FarmerPotato]

On why TI BASIC follows Dartmouth BASIC: the obvious answer is, because TI implemented Dartmouth BASIC on their 990 minicomputers.

 

I'd like to work up an argument from internal evidence, by comparing  TI BASIC for the TI-99/4A and TI BASIC for DX-10, an operating system on the TI 990.

 

My hypothesis is that TI-99/4A BASIC was derived from DX-10 TI BASIC on the 990, possibly working from source code. This is just a hypothesis at this point. If there are internal similarities in the interpreter, token representation, floating point format, and other behavior, it argues that TI employees (or contractors with TI source) made the interpreter.

 

For now, I can see that the language syntax is very similar. At least, the spec for TI-99/4A BASIC and Extended BASIC was a subset of TI BASIC for DX10.

 

I think the key to answering this question is to disassemble the inner interpreter on DX-10, examining how it resembles or differs from the TI-99/4A interpreter. Actual commented source is probably unobtainable. I contacted Dave Pitts (www.cozx.net) who has the TI BASIC disk for DX10 on his ftp.  (Interestingly, he sent me his original fig-FORTH source for the 990. I don't think it is the same as the later fig-FORTH port that we got. But that's a separate inquiry!)

 

The following sources may be helpful in examining this hypothesis.

 

Page 4-13 of 990 Computer Family Systems Handbook 3rd edition May 1976
http://www.bitsavers.org/pdf/ti/990/945250-9701_990_Computer_Family_Systems_Handbook_3ed_May76.pdf

Quote

 

4.4.4 MULTIUSER BASIC. BASIC is an easily understood programming language
that is applicable to both business and scientific problem solving applications. It is an
interactive language for simultaneous use by several different users, each working from
his own terminal. The computer provides feedback to each command entered on the
terminal and points out any programming errors· by printing diagnostic messages
following the erroneous command.

 

The BASIC interpreter operates under the DX10 Disc Executive. The language 
implemented by this system is equivalent to Dartmouth BASIC with certain extensions to
enhance its use in the business world. The system package includes the following
components:

 

• An executive for processing commands and translating BASIC statements

 

• A re-entrant multi-terminal interface module to coordinate the interaction
of the executive, the interpreter and the operating system

 

• A re-entrant runtime interpreter that performs all arithmetic and logical
functions during the execution of a BASIC program. These functions
include: floating point arithmetic, string manipulation, I/O editing and
matrix arithmetic.

 

The memory size required to operate the BASIC system varies with the amount of
memory assigned to each user and to the number of users involved in the system. A
minimum of 32K words of memory supplies space for the system package, user
housekeeping areas, user programs and the operating system. 

 

 

Reference manuals from which you can see that TI-99/4A BASIC matches a subset of DX10 TI BASIC. Both are derived from Dartmouth BASIC.

TI BASIC for DX10 Reference Manual
http://www.bitsavers.org/pdf/ti/990/basic/2308769-9701A_BASIC_refMan_Dec83.pdf

 

The TI BASIC on the 4A is clearly a subset of TI BASIC for the 990, plus built-in CALL subroutine expansions. TI-99/4A Extended BASIC is a larger subset including "::", DISPLAY AT, CALL/SUB/SUBEND. PRINT USING is also from Dartmouth BASIC.

 

Dartmouth BASIC
http://www.bitsavers.org/pdf/dartmouth/BASIC_Oct64.pdf

http://www.bitsavers.org/pdf/oregonState/os3/CCM-71-08_BASIC_May72.pdf

 

More TI 990 references
https://www.cozx.com/dpitts/ti990.html

 

Floating Point

 

Another question I have is: what floating point format did DX-10 TI BASIC have? TI-99/4A's RADIX-100 was quite unusual. (This kind of broke my brain because it was what I knew first.) A related question is, what floating-point format did the 990  use? (answer: IBM 360 single precision  https://atariage.com/forums/topic/274613-99110-rom-disassembly/?do=findComment&comment=3947607)

 

Survey of floating point formats

https://mrob.com/pub/math/floatformats.html

 

Quote

 

Footnote 36 : Joe Zbiciak, email correspondence. The TI 99/4A uses radix 100 in an 8-byte storage format. 7 bytes are base-100 mantissa "digits" (equivalent to 14 decimal digits), and the exponent (a value from -64 to 63) is stored in the 8th byte along with a sign bit. The exponent is treated as a power of 100. The largest-magnitude values are ±99.999999999999×10063, and the smallest-magnitude values (apart from 0) are ±1×100-64. Precision varies from just over 12 decimal digits to just under 14: for example, π/3 is 01.047197551197×1000 and 3/π is 0.95492965855137 (represented as 95.492965855137×100-1).

 

 

 

 

Hypothesis: Perhaps the floating point format on the TI-99/4A was intended to be BCD coded, but this was abandonded in favor of Radix-100. The TI-99/4A was intended to have the TMS9940 cpu. This cpu had two new instructions for BCD arithmetic: DCA, DCS (LIIM is also new). But the TMS9940 didn't ship, forcing the TI-99/4A to use the TMS9990, coding around any use of DCA or DCS. And the rest is history. Anyhow, I don't see an advantage to using BCD over Radix-100.

See http://bitsavers.informatik.uni-stuttgart.de/pdf/ti/990/tx990/0943441-9701_990_Assembly_Language_Programming_Guide_Oct78.pdf appendix L-1, 9940 Programming Considerations.

 

Sources of more info

 

https://www.cozx.com/dpitts/ti990.html

http://www.bitsavers.org/pdf/ti/990/

 

 

[+Lee Stewart]

1 hour ago, FarmerPotato said:

Floating Point

 

Another question I have is: what floating point format did DX-10 TI BASIC have? TI-99/4A's RADIX-100 was quite unusual. (This kind of broke my brain because it was what I knew first.) A related question is, what floating-point format did the 990 hardware co-processor use? (I can't find anything about this.)

 

Survey of floating point formats

https://mrob.com/pub/math/floatformats.html

 

Hypothesis: Perhaps the floating point format on the TI-99/4A was intended to be BCD coded, but this was abandonded in favor of Radix-100. The TI-99/4A was intended to have the TMS9940 cpu. This cpu had two new instructions for BCD arithmetic: DCA, DCS (LIIM is also new). But the TMS9940 didn't ship, forcing the TI-99/4A to use the TMS9990, coding around any use of DCA or DCS. And the rest is history. Anyhow, I don't see an advantage to using BCD over Radix-100.

See http://bitsavers.informatik.uni-stuttgart.de/pdf/ti/990/tx990/0943441-9701_990_Assembly_Language_Programming_Guide_Oct78.pdf appendix L-1, 9940 Programming Considerations.

 

Both BCD and radix-100 are wasteful, with BCD wasting 6 bits every nybble and radix-100 wasting 156 bits every byte.  Radix-256 would use every bit, provide 19 – 20 decimal digits and decimal powers of about -151 – +151 in the same 8 bytes, but the math routines would likely be slower and squander more code space—something at a definite premium in the TI-99/4A. I have often thought of developing a radix-256 library— h-m-m-m-m...

 

...lee

[Asmusr]

31 minutes ago, Lee Stewart said:

and radix-100 wasting 156 bits every byte

That *is* really wasteful.

[+mizapf]

Radix-100 has a *huge* advantage over other systems, despite the waste of bits. It can represent floating point numbers precisely which are interesting to us.

 

To illustrate this, compare it with IEEE-754. This is the standard format for floating point numbers today. IEEE-754 is not capable of representing 1/10 = 0.1 accurately, and most multiples of it (except for 0.5). The reason is that floating point numbers in different number systems (base 10 vs. base 2) may change from terminating to periodical, as is the case for 0.1.

 

To be precise, there is no terminating sum of 2-powers that yield 0.1 (decimal).  0.1(dec) = 0.000110011001100110011...(bin). As every computer con only process a limited number of digits, this number will be truncated, and therefore not be correct but an approximation.

 

The situation is drastically different for radix-100. The idea is to represent two digits of the decimal system per byte, that is, 0.123456 is 12/100 + 34/(100^2) + 56/(100)^3. We can assume that we are always working with a limited number of decimal digits when we enter numbers, and for these cases (if we don't use too many digits), the number will be correctly represented.

 

In the above case, 0.1(dec) = 0.10(radix100).

 

[+Lee Stewart]

26 minutes ago, Asmusr said:

That *is* really wasteful.

 

With my accounting, it appears that BCD wastes less in the 8 byte representation than radix-100, but they are practically identical, with a couple of exceptions. BCD is always 14 decimal digits of precision, whereas radix-100 is 13 for odd powers of 10. Radix-100 has the better range, with decimal powers of -127 – +128 over BCD’s -63 – +64, using the same excess-64, 7-bit exponent.

 

...lee

[ChildOfCv]

On 8/27/2019 at 11:45 AM, OLD CS1 said:

We getting biblical around here?

The Four Horsemen of the Apocrypha?

 

On 8/26/2019 at 8:05 AM, hloberg said:

I plan to quote from the books, the interviews, what documentation that is on line and just put it all out there for people to make up their own minds.

No.  Modern writing is about choosing your narrative; omitting, distorting, or impugning facts that disagree with it; and passionately pushing your side.

 

On a more serious note, encyclopedias are pretty much just compilations of existing research.  You can point out where cited sources disagree, but you aren't allowed to push your own conclusion. [citation needed]  So your plan makes sense in the grand scheme of things.

 

Of course the irony is that one could argue that the very search for existing research is, in itself, original research

[+FarmerPotato]

Well, not 156 bits per byte wasted, just 156 values. Log2(100) is 6.64, so there are 1.36 bits wasted by only counting up to 100 in each byte.

Putting 13 digits, radix-100, in 56 bits, you have stored Log2(1e14) = 46.5 bits, so actually only 9.5 bits of the 56 are wasted, in the sense that you could have squeezed more out of them. (this is the Shannon information-theory sense.)

 

Radix-100 seems like it came from a calculator designer.

 

In 1972, the TMS1802 was TI's first single-chip for calculators, and used 8-digit BCD numbers.

 

According to the table, other Radix-10 (BCD) are TI-85 and HP-71B calculators and Motorola Packed Decimal Real (68881).

 

The Motorola math coprocessor seems to get 17 digits in BCD in 10 bytes.
The 8 byte IEEE 754r-decimal64 gives 16 digits (I don't get this)

 

How much precision can you squeeze from 8 bytes?

 

Radix-100 in 8 bytes gave ~13 digits of precision and a max of 9.99*10^127.
TRS-80 8-byte double precision (aka VAX D) used radix 2 and yields 16.9 digits or Log10(2^56). There is 1 exponent byte and 7 mantissa bytes.

IEEE-754 8-byte double trades 3 bits of mantissa for 3 bits of exponent, yielding 15.9 digits of precision, Log10(2^53), and an upper limit of 1.8 x 10^308.

 

And IEEE-754 is where everybody has converged.

Some lecture notes on floating point:
http://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/flpt.apprec.html
 

[+mizapf]

As I stated above, the IEEE-754 is more efficient and yields more digits of precision, but this is in many cases just uninteresting for everyday calculations. While many digits of precision are certainly important during calculations, the IEEE format just does not allow you to enter everyday values like 0.1 precisely. The TI is therefore one of the rare examples (the only one?) that achieves to add 10 times 0.1 and get precisely 1 as a result (not rounded!). If you use IEEE-754 and do this calculation, you will never get a precise 1.

[+FarmerPotato]

11 minutes ago, mizapf said:

As I stated above, the IEEE-754 is more efficient and yields more digits of precision, but this is in many cases just uninteresting for everyday calculations. While many digits of precision are certainly important during calculations, the IEEE format just does not allow you to enter everyday values like 0.1 precisely. The TI is therefore one of the rare examples (the only one?) that achieves to add 10 times 0.1 and get precisely 1 as a result (not rounded!). If you use IEEE-754 and do this calculation, you will never get a precise 1.

 

I heartily agree!

 

The TI-89 and TI-92 calculators are still BCD with 16 digits. They are as precise as IEEE-754 double, but use 10 bytes per number.

 

https://www.manualslib.com/manual/325941/Texas-Instruments-Ti-89.html?page=73

 

I want to make a base-60 floating-point core (6 bits per digit) so you can exactly represent 1/3,  1/12 etc. It needs a cool name, like Calculon or something. 

 

 

[kl99]

On 8/29/2019 at 12:14 AM, acadiel said:

You guys should read the TI source code for the console GROMs.. some fun stuff in here.

 

Console GROM Source Code 1-Monitor 1982-08-25

Console GROM Source Code 2-Cassette 1982-08-25

Console GROM Source Code 3-EDIT-HC 1982-08-25

Console GROM Source Code 4-PSCAN 1982-08-25

Console GROM Source Code 5-FLMGR 1982-08-25

Console GROM Source Code 6-EXEC 1982-08-25

Console GROM Source Code-Monitor Page 33

 

 

console source.zip 9.18 MB · 11 downloads

This is spectacular! Endless thanks for sharing this.

 

I got in contact with Stan Hume, who is mentioned in those source code documents so many times and will ask him if he is ready for an interview. His Linked In profile claims his involvement in the BASIC interpreter.

"Software Engineer, Texas Instruments, June 1978 - June 1981, Lubbock Texas.

First job out of college. Wrote a large portion of the embedded BASIC and all of the Extended BASIC product for the TI 99/4 and TI99/4a. Anyone learn to program on a 99/4? Yes, I started as an Assembly Language programmer. This gives a unique perspective on how software actually runs on hardware that many today don't understand."

 

Also I know about Sumiko Glenn, who was working on Extended Basic.

"Software Design Engineer, Texas Instruments, Jan 1977 - June 1982.

Worked as a software engineer and implimeted Extended Basic Interpreter and other home computer software."

[+hloberg]

well, it looks like the sources and info  been added to the list. thx

 

[+FarmerPotato]

Here are some facts arguing that TI-99/4A BASIC is derived from DX10 TI BASIC.

 

I perused the file EDIT-HC which contains the TI BASIC token table (page 4).

 

Some tokens that appear in DX10 TI BASIC are commented out in the token table.  They were:

*
* B A S I C   T O K E N   T A B L E  
*                         REVISED 8/23/78
::
!
SUBEXIT
SUBEND
REAL
INTEGER
SCRATCH
ACCEPT
IMAGE
OR
AND
XOR
NOT
ALL
USING
BEEP
ERASE
AT
VARIABLE (?)
TEMPORARY
RELATIVE (?)
INTERNAL (?)

Some of these are familiar from TI Extended BASIC. I found those existed in DX10 TI BASIC first. Some of them are unfamiliar, and they are from DX10 TI BASIC too. For instance, the REAL and INTEGER (and later DECIMAL) declare variables of integer or float. The keyword ALL sets the default type.

 

REAL A,B,C,D
INTEGER ALL

Integers are 32 bit signed.

Reals are 14 digits with an exponent up to 128.  (this sounds like Radix-100!)

Later, by 1983, the DECIMAL(-2) type indicated a real with a format for printing with rounding.

 

Program Storage

 

I don't see SCRATCH in the 1983 DX10 TI BASIC. Obviously it's not in TI-99/4A BASIC, because it was commented out of the source!

 

SCRATCH, in Dartmouth BASIC, is like NEW but keeps the program name. (NEW prompted for a program name, UNSAVE deleted one, CATALOG listed all of them.)

 

Interesting tidbit: DX10 TI BASIC had a concept of work file and separate main and subprograms. OLD copied a disk file into the work file. From there you could RUN, or EDIT MAIN or EDIT ESUB <name> to bring the main program or subroutine library into memory for editing. DELETE ESUB <name>. UPDATE would save memory to the workfile. Finally, SAVE would overwrite the program on disk.

 

File access

 

Dartmouth BASIC opens a file like so:

 

OPEN %1,"HI",OUTPUT

DX10 TI BASIC uses the syntax:

OPEN #7:"LP01"
OPEN #1:"DS01.SCRATCH",OUTPUT,TEMPORARY

 

remember PERMANENT in TI BASIC?  In DX10 TI BASIC, "TEMPORARY files are deleted when CLOSE or BYE statement is executed."

 

DX10 has Logical Unit Numbers (LUNO). Is that for the Number sign?

 

Strings

 

Another bit of evidence: strings can be 255 characters long in DX10 TI BASIC. Though the limit is 255 in GWBASIC as well. I can't find the answer for Dartmouth BASIC. Nowadays we call these "Pascal Strings" because Pascal tended to use a one length byte, while C uses a terminating null.

 

Intrinsic Functions

The TI-99/4A BASIC token table from CB to D4 has ABS, ATN, COS, EXP, INT, LOG, SGN, SIN, SQR, TAN.

 

These are exactly the list of numeric functions provided by DX10 TI BASIC.

 

The TI-99/4A BASIC token table continues with LEN, CHR$, RND, SEG$, POS, VAL, STR$, followed by 16 empty slots.  

 

While DX10 TI BASIC has String functions ASC BREAK LEN NUMERIC POS RPT$ SPAN UPRC$ VAL CHR$ SEG$ STR$.  

 

Followed by DAT$, TIME$, and misc functions RND, RANDOMIZE, FREESPACE, INKEY, INKEY$, EOF, FTYPE, TAB, ERR, DUP.

There are 10 + 7 + 16(empty) = 33 slots for functions in the TI-99/4A BASIC token table. DX10 TI BASIC has 10 + 12 + 2 + 10 = 35.

 

Hmm, I thought they might line up better. Of course, function names can grow in number, and tokens just help compress the program size. Wait, BREAK is already a token. So is RANDOMIZE. 

 

The number of built-in functions in DX10 TI BASIC exactly matches the size of the hole in the TI-99/4A BASIC token table!

 

[RXB]

SCRATCH (RECORD) was never implemented it is noted in XB source that was in future version of XB, you can see this is still there in RXB Source using XB GPL Source and XB ROM source.

 

TEMPORARY was also mentioned but not used as like RELATIVE, VARIABLE, and INTERNAL were all assigned to FILES (RECORDS)  only. (Again lack of memory created this problem.)

 

Obviously OLD could not be used like the DX10 TI Basic as the TI99/4A only had 32K nowhere as much memory, so OLD was modified to behave like LOAD, and LOAD was ASSEMBLY only or Address.

 

The only reference in GPL source of XB on PERMANENT is for FILES ONLY, and MEMORY ACCESS of that program in memory. (A simple CALL LOAD and bypass it once in memory).

(Another way I did years ago is CALL PEEK and print out the values to paper then manually enter them getting around the PROTECTION option.)

 

TI BASIC on the the TI99/4A is a really cut down slow version of XB. No sprites, no multiple lines for programs and worst of all only runs from VDP memory and everything in just console sharing all in VDP RAM.

Edited August 31, 2019 by RXB

[+hloberg]

we had TI miniframes in college. I learned programming on a Ti-99 then TI miniframes. I don't remember the BASIC on the miniframes though.

while I was still in High-school (this should tipped me off I was going to be a programmer) I helped some college students writing code on TI print tele-type machines (this was before the TI-99). I helped them with their homework then we would play Star-Trek on the tele-type machines. type in a command, press enter. prints out on the paper scroll. wait a few minutes, output prints on page. I lived in middle Ga. and the severs were in Athens 200 miles away at 300bd. sometimes very long waits.

by the time I went to Tech they had IBM PCs & terminals attached to, again, TI miniframes on campus. I remember thinking how primitive the graphics & sound was on the IBM PCs compared to the TI-99. 

I now wish I had learned more about the TI miniframes but it took everything to make it through Ga. polytech and work at the same time.

[+Lee Stewart]

12 minutes ago, RXB said:

SCRATCH (RECORD) was never implemented it is noted in XB source that was in future version of XB, you can see this is still there in RXB Source using XB GPL Source and XB ROM source.

 

This use of the word, SCRATCH, has absolutely nothing to do with the SCRATCH of Dartmouth Basic.  As you point out, TI never implemented the SCRATCH opcode in DSRs for file records. However, the SCRATCH under discussion relates to the Basic program in memory, not a file record. The fact that they have the same name and are related to erasure is irrelevant.

 

...lee

[RXB]

19 minutes ago, Lee Stewart said:

 

This use of the word, SCRATCH, has absolutely nothing to do with the SCRATCH of Dartmouth Basic.  As you point out, TI never implemented the SCRATCH opcode in DSRs for file records. However, the SCRATCH under discussion relates to the Basic program in memory, not a file record. The fact that they have the same name and are related to erasure is irrelevant.

 

...lee

The main reason for my mention of this is Western Horizon wanted me to make a SCRATCH record for use with the Horizon RAMDISK that would implement it.

Problem was it was so freaking slow as it had to cycle entire file records and find it then reset every record to fill that empty space created by removal.

 

It worked but took up so much DSR space and was so slow we dumped the project. Huge DV80 files were the slowest.

 

And the discussion was on differences between BASIC's which I did not see a disclaimer on what I could mention or not point out. Sorry it is in the GPL/ROM source after all.

Edited August 31, 2019 by RXB

[Tursi]

21 hours ago, JB said:

Because Wikipedia said so, never mind that the article was clearly written by someone with very little knowledge of the platform(seriously, last time I looked the 99/4a article was just AWFUL).

No, the Wikipedia source for the comment is the book "Gates" by Stephen Manes and Paul Andrews. It does have a comprehensive index and 6 pages of people called out by name, but it's not clear where they got the bits about TI BASIC specifically. This is cited every time the argument arises and discounted every time because obviously Bill Gates must be lying.

 

The theory that they worked on a different BASIC for TI which never shipped is the only new information this time around, and it's an interesting one.