Talk:Microsoft BASIC

BASIC lineage doubts

Seriously, are all of those REALLY versions of Microsoft BASIC?

I'm wondering at least about:

1. Amiga BASIC (Commodore Amiga)
2. Applesoft BASIC (Apple II family)
3. 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)

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)

There are allegations that Microsoft BASIC was hacked from a stolen DEC BASIC. Bill Gates has been asked to release the source code for his original BASIC, partly out of general curiosity, partly to see if this allegation has any truth in it. He has never released this source code.

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)

I, too, second that suspicion of BASIC language heritage. The proverbial citation is needed. At least once in the whole article. Hosiah (talk) 23:36, 25 March 2008 (UTC)

I was there and know the Basic source code rather well (at least then). We had no source for DEC Basic except the DecSystem-10 version (Paul Allen made some modifications to it years earlier) which has nothing in common with Microsoft Basic. The architecture is totally different, the processors weren't nearly powerful enough and in no way would fit in 4k. We did have a manual for PDP-11 RSTS Basic and did use the syntax of some of their statements. Microsoft Basic used a tokenized representation of a program, words like "print" were replaced by a single byte. The machine code of Basic made heavy use of RST opcodes to call key subroutines in fewer bytes and "LXI tricks" which were using instruction overlap to provide multiple entry points to a subroutine in fewer bytes. MarcMcd (talk) 05:46, 15 August 2012 (UTC)

Skipping over a long time in history in just one paragraph

I just wanted to say that the whole text is about the good old times when computers were actually (4, 8 or 16 kbyte RAM) + (4,8 or 16 kbyte ROM) programmable calculators There are mentioned memory sizes measured in kbytes

At that time I was using time on a CDC 7600, a 1970s super computer, which had around 200 K of RAM. So even 'serious' computers had small amounts of RAM. UNIX was developed on a PDP 8 with c. 4 K of RAM, in the late 1960s. My programmable calculator then had 31 bytes of RAM. By the time of the HP-41, when programmable calculators had kB of RAM, the other differentiator was the display - one-line on a calculator, 23+ on a computer. No graphics on a calculator; graphics on a computer.

But in the last paragraph there is mentioned C#, .NET and other technologies from the Gigabyte era (when both Ram and Harddisk is in gigabytes)

To jump from kilobyte era (1970s~1980s) straight to gigabyte era (2000s) is too big skip

I think many things in between are missing - about GWBASIC, QBASIC and so on. How the features of BASIC grew up and so on

I didn't think Microsoft BASIC supported long variable names. You could use long names, but only the first two characters were significant. Thus, A10 and A11 were the same variable. Once you realised this you stopped confusing yourself by using 'long' names - they took up RAM and caused confusion, no more.

QBASIC is still included with some versions of Windows XP, so the statement in the article that it is no longer included is not entirely correct. For example, type "qbasic" at the Run window on any Korean language Windows XP system and you'll get QBASIC. I don't know why it's no longer included in the English version, but the English version of Windows XP is not the only version in existence.

Variables?

The phrase "BASIC used dynamically allocated strings which stored their size, a feature not common in C or C++ until the Standard Template Library of the 1990" implies this was an unusual feature of MS basic. PASCAL and its decendants has always stored strings in this manner. Indeed, I cant think of programming language other than C and C++ that dont record string size in some manner. —Preceding unsigned comment added by 81.86.246.117 (talk) 12:54, 24 November 2010 (UTC)

I don't see the relevance of comparing it to 'C', and the STL isn't part of the language anyway! You could always use dynamic "strings" in 'C' using malloc() of you want to. The fact is that 'C' doesn't actually have a string type. So I'm agreeing with anonymous about the relevance of the comment here.

HOWEVER, with Microcomputers in the late 1970s to mid 1980's in was unusual to find a language with garbage collected string types. But then again, it was unusual to find a language another that would run on a Microcomputer other than Assembler or FORTH. UCSD Pascal existed, but I'd dispute that it actually ran in any meaningful sense!

F J Leonhardt 18:50, 1 January 2018 (UTC)

Standalone Disk BASIC-80, Standalone Disk BASIC-86 and their 8-bit FAT filesystem on 8-inch floppies

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)

Microsoft BASIC for Macintosh. W/compiler

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)

Many variables = slow?

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)

It is true that: The runtime symbol table uses a linear search. At least that is what I am familiar with in BASIC for Sharp MZ-800 (Z80 based computer), confirmed by seeing the assembly source. However, that does not make a program run much slower always. The slowdown could be experienced in the worst case when you pick the variable initialized at the latest moment and use it in some time critical inner loop. So in my opinion, better wording would be: The runtime symbol table uses a linear search and so the time needed to calculate an expression involving variables depends not only on the complexity of the expression, but also on the initialization order of the variables used. -lukq — Preceding unsigned comment added by 185.112.167.100 (talk) 08:49, 9 February 2019 (UTC) To clarify: I do not have proof that it is the same in Microsoft BASIC, but I believe it is highly likely. The performance impact could probably be measured in an emulator. -lukq — Preceding unsigned comment added by 185.112.167.100 (talk) 09:00, 9 February 2019 (UTC)

6502 basic

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)contribs) 18:43, 1 January 2018 (UTC)

TI-99/4[A] BASIC

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 {{fact}} 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)

This is consistent with my memories of this very interesting machine. It had the honor of being the first 16-bit microcomputer, but that was stretching the definition. the 9900 had no stack or GP register, but instead used a block of workspace RAM pointed to by WP. So instead of pushing registers to a stack on a JSR, you just moved the WP. Great if your RAM was really fast. But it was really slow; accessed on a multiplexed 8-bit bus via the graphics chip IIRC. There was something that sounded very much like a L2 cache possible, but TI made it very small to save money.

I used the 99000 series on a project in the 1980's. It was brilliant. But by then everyone was using 80x86 if they wanted naff, or 68K if they didn't.

Incidentally, Jobs did a similar crippling job on the 68000 running on the Mac - effectively running a 7MHz 68K at 3.5Mhz — F J Leonhardt 21:42, 4 November 2018 (UTC)

"Crunched" code

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:

     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)

Sources