Talk:Microsoft BASIC

message: Seriously, are all of those REALLY versions of Microsoft BASIC?
I'm wondering at least about:
# Amiga BASIC (Commodore Amiga)
# Applesoft BASIC (Apple II family)
# Commodore BASIC (CBM 8-bit family, incl C64)
timl
:Yep, all the listed BASICs are descendants of MS BASIC; I've done some research on all of them to check this (not too much work really, just surfing to the relevant websites for the BASICs I wasn't familiar with from before). Curious you should mention CBM BASIC by the way -- it was the first home computer BASIC licenced from Microsoft (1977), with the PET beating the Apple II by a short amount of time (I'm excluding the MITS Altair here, since it could hardly be called a home computer; rather a microcomputer kit for seriously involved hobbyists).  --Wernher 16:58, 15 Apr 2004 (UTC)
replies: text: On the other hand, VB.NET and Small Basic are NOT descendants of Microsoft BASIC.  — Preceding unsigned comment added by 124.187.192.148 (talk) 04:00, 1 June 2022 (UTC)
replies: text: However, it is available in the Pusey library at Harvard: here is a annotated disassembly: http://www.interact-sw.co.uk/altair/index2.html 150.101.166.15 (talk) 09:44, 19 December 2007 (UTC)
thread_title: BASIC lineage doubts

message: For as long as we don't have a dedicated article on Standalone Disk BASIC-80 and Standalone Disk BASIC-86, this appears to be the best place to ask:
For the FAT article, I'm trying to find out better details in regard to the 8-bit FAT file system utilized by these BASIC variants on 8-inch (and possibly also 5.25"-inch) floppy disks between 1977 and 1980. If someone knows specs, has diskettes used under these systems or can provide disk images for further analysis, please contact me on my talk page or join the discussion at Talk:File Allocation Table#8-bit_original_FAT_specification?.
Thanks. --Matthiaspaul (talk) 23:27, 6 May 2014 (UTC)
thread_title:  Standalone Disk BASIC-80, Standalone Disk BASIC-86 and their 8-bit FAT filesystem on 8-inch floppies 

message: I think this was the 86 version although i did not see the compiler for a year or more.
If this is the m-80 processor. The page should still mention the macentosh.
These are very usefull tools andn historic language forms. Sometimes the right tool is relativly simple.
Qbasic is another one...  — Preceding unsigned comment added by 72.94.241.13 (talk) 14:28, 27 January 2015 (UTC)
thread_title:  Microsoft BASIC for Macintosh. W/compiler 

message: The article for a long time has said: The runtime symbol table uses a linear search so that a program which used many distinct variables would run much slower (in the time of early processors) than a program which used a single array for all its variables. This seems unlikely to me, so I have just removed it - but of course, if a reputable source can be found, feel free to add it back in. Snori (talk) 16:32, 28 November 2016 (UTC)
thread_title: Many variables = slow?

message: I'm afraid the section on 6502 BASIC is incorrect. I know this because I was around at the time and know it intimately, particularly version 1.0 rev 3.2.
The main problem is the standard features list:
GET wasn't always present (neither was INKEY). Version 1.0 used the BIOS to read a key, and often the only official way was to using the buffered INPUT statement. Various work-arounds existed on platforms using PEEK and POKE on the keyboard latches.
Version 1 (for sure) supported floating point and string variables and arrays; there was no integer support.
Long variable names - actually they could be as long as you like but the run-time variable table only held the first two characters.
Even more fun was the WAIT statement - did completely different things on different platforms!
There was indeed a 6.5 digit floating point version (in 8K ROM) and a 9.5 digit version on disk. Unfortunately I'll have to fire one up to work out the length; I think it was more than 9K long - but it did usually include OEM commands for the DOS so it's hard to make a direct comparison.
It's not true that there was no reseed for the random number generator in all cases. It was just part of the RND() function; although in these cases RND() would always produce a number between zero and one. In some versions the argument set the boundary (e.g. RND (8) would produce one <8). As a result, it was best to always call RND(1).
-- Microtan 65 BASIC --
This is listed as running BASIC-80. Hate to say it but the Microtan used a 6502. Hence the "65" in the name. BASIC-80 was, AFAIK, only applied to the 8080 (Z80) versions - later known as MBASIC on CP/M. Hence the "80" in its name.  — Preceding unsigned comment added by Fjleonhardt (talk • F J Leonhardt 18:50, 1 January 2018 (UTC)
thread_title:  6502 basic 

message: Section currently states:
:This is the version of BASIC used on Texas Instruments' TI-99/4A computer line. Notably, it is not written in assembly language, but in a high level interpreter developed by TI. The reason for this was because Microsoft did not have any programmers who knew how to code for the TI-99/4A's 9900 CPU and so Texas Instruments instead gave them an interpreter to code in instead.
I've tagged this as  because, while I don't have a reference to back it up, my understanding is that this isn't entirely true -- from all I've seen the decision was taken intentionally in order to reduce address space usage.  From the perspective of the developer implementing BASIC it may have been a way of simplifying development (although learning TMS9900 assembly language would have been unlikely to be much harder than learning the GPL interpreted byte code), but from the perspective of the system engineers having BASIC implemented like this was better than using native code. The BASIC interpreter sits in a GROM chip, from which the GPL interpreter is able to run it while only requiring 8 bytes of address space, which is pretty important for a 16-bit machine with a 16-bit address space.  If the TI-99 range hadn't been cancelled, the fact that it could have important features implemented without needing significant amounts of address space would have been critical to keeping up with other systems that allowed larger address spaces.
Also regarding the slowness, my understanding is that the GPL interpreter was expected during development to become much faster: they were expecting to have an 8-bit bus version of the processor available, but the project to develop that was cancelled very late, thus it was replaced with a bridge between a 16-bit local bus and an 8-bit peripheral bus.  This made all accesses to the 8-bit peripherals (including the GROM chips that contained BASIC) take two bus cycles rather than just one, effectively halving memory access performance.  If the expected 8-bit bus processor had been delivered, it would have been able to access the GROM chip in single cycles, so would have been noticeably faster.  Again, I don't have a reliable source that backs this up, so haven't added it to the article, but it is worth considering that the implication of the article that the slowness was caused by the decision to use GPL is potentially wrong. 212.159.69.4 (talk) 05:27, 4 November 2018 (UTC)
thread_title:  TI-99/4[A] BASIC 

message: The article mentions early versions of Microsoft's BASIC supporting "crunched" statements.  The way it is written, it is misleading in that it sounds like removing spaces from statements was an automatic feature of the language, but from what I have been able to gather, it was  not.  Appendix D, page 56, of the MITS Altair BASIC Reference Manual (1975) has a section titled "Space Hints". wherein it states:https://web.archive.org/web/20120512091923/http://altair32.com/pdf/Altair_8800_BASIC_Reference_Manual_1975.PDF
     2) Delete all unnecessary spaces from your program.  For instance:
                10 PRINT X, Y, Z
                uses three more bytes than
                10 PRINTX,Y,Z
          Note:  All spaces between the line number and the first non-
     blank character are ignored.
Since this was evidently a matter of coding style and not automatic, as far as I can determine there was no automated way to "un-crunch" such code.  To run such programs under BASICA, GW-BASIC and other later dialects, one is forced to tediously add spaces line-by-line until it passes the syntax checker in the BASIC interpreter or compiler.  It may have saved RAM space when RAM was expensive, but it gave rise to portability issues later. — Quicksilver (Hydrargyrum)T @ 22:49, 10 May 2019 (UTC)
thread_title:  "Crunched" code