15

I sort of "have a thing for BASIC" right now, which has led to a couple of great exchanges here in RSE about the variations "back in the day". I'm wondering if anyone is aware of other modern BASICs for the 6502?

I'm ultimately interested in seeing if there is a way to make a fairly universal BASIC for the platform that is a modern improvement on the MS standard. I know there are a number of examples like BBC and TURBO that have significant performance improvements, as well as complete re-implementations like FastBasic that everyone should look at. And then there's the various potential improvements seen here, especially supercat's remarks on strings.

So are there other examples I should look at?

Maury Markowitz
  • 19,803
  • 1
  • 47
  • 138
  • I'm sure there are. Are you asking for actually extant examples, or for hypothetical "this might be a good idea to do" type answers? – Omar and Lorraine May 30 '18 at 14:52
  • 2
    I'm looking for existing BASICs that have interesting ideas. FastBasic is an example, it's a p-code system instead of a "pure" interpreter and thus offers dramatic performance improvements.I think that's fascinating on it's own, but it still manages to run on an Atari. – Maury Markowitz May 30 '18 at 14:55
  • EH-Basic ofc. Then again, BBC Basic is already quite good. I still have some BASIC I did for the Apple II, trying new ways - like INC and DEC instructions and native Interger handling, but most important linked GOTO/GOSUB to speed up of the usual BASIC Spaghetti style. – Raffzahn May 30 '18 at 17:55
  • For anyone else who was wondering, True Basic seems to never have been available for 6502 and other 8-bit processors. It apparently started on the 16-bit machines. – RichF May 30 '18 at 20:40
  • @Raffzahn - by "linked", do you mean caching the return/goto addresses? Or something else? – Maury Markowitz May 31 '18 at 10:30
  • @MauryMarkowitz Not cashing, but kind of compiling. When the program gets started (RUN or CONT) the 'compiler' part parses thru the programm and adds the memory address of each GOTO/GOSUB target in to the statement - the editor keeps two bytes space for this. THey are by default filled with FF to detect un'compiled' ones (Originally this was used to 'compile' on the fly, which may be used as well to speed up startup). Whenever a line got edited (i.e. during break) it's address got noted down and CONT did 'recompile' all targets beyond that (starting form line 1). – Raffzahn May 31 '18 at 11:15
  • Oh yes, TURBO did this too. – Maury Markowitz May 31 '18 at 22:23

7 Answers7

16

In addition to FastBasic for the Atari, those interested in the Apple II line should take a look at PLASMA. PLASMA is not BASIC. It is its own language designed for the 6502 and focuses on being easier to read & maintain than assembly without sacrificing full access to the hardware. The syntax is familiar to Pascal, C, and 6502 assembly programmers. It also has a self-hosted compiler & editor, and generates compact and relocatable VM code.

There are early prototype ports of PLASMA aiming to support the Commodore 64 and BBC Micro.

Brian H
  • 60,767
  • 20
  • 200
  • 362
  • Ahh, Brian, have a look at Action!, I suspect they are very similar? https://atariwiki.org/wiki/Wiki.jsp?page=Action – Maury Markowitz May 30 '18 at 20:05
  • 3
    Action is completely different. Action is a traditional Algol style compiled language that happens to have been developed on the 6502. It, otherwise, does not expose any 6502 specific mechanics. If there was a Z80 version, the source would be identical. It's basically a "cheap C" that compiles in to machine language and is then executed. PLASMA has a different purpose, and completely different runtime philosophy. – Will Hartung May 30 '18 at 20:36
  • Ok I'll definitely have a look here too. – Maury Markowitz May 31 '18 at 20:31
10

Probably the most modern BASIC available for the 6502 - though it requires a 65C02 - is Acorn's BBC BASIC IV as released for the BBC Master. It can be ported to other 65C02-based hardware by implementing a few of the MOS API entry points it relies on, and dummying out the rest; several people have done so for home-built SBCs. The standard version occupies 16KB starting from $8000, but there is a relocated version for loading into high RAM of the Second Processor, starting from $B800.

BBC BASIC has much more support for "structured programming" than typical MS-derived BASICs, and is also noticeably faster. I thoroughly recommend digging out a BBC Master emulator and playing around with it.

Chromatix
  • 16,791
  • 1
  • 49
  • 69
  • There's also Advanced Basic, which is a backport of Basic V from the Archimedes to the BBC second processor or Master. It's got things like multiline IF, CASE, WHILE, etc. It doesn't seem to be by Acorn. There's not a lot of information about it --- I'd love for the source to be released. http://mdfs.net/Software/BBCBasic/BBC/AdvBasic/ – David Given Dec 13 '20 at 20:29
7

There's EHBasic, which is (afaik) a re-invented BASIC (i.e. I do not believe it's a port from a vintage BASIC, but recreated out of whole cloth), but it seems pretty mundane and conventional.

There's a reverse engineered, commented assembly listing of the Atari TURBO BASIC XL. It was noted for having some interesting features.

I have not looked at it in detail, so can't comment on that.

Will Hartung
  • 12,276
  • 1
  • 27
  • 53
  • EHBasic is pretty conventional. What is neat about it is the work the late Lee Davison put into making it stable, extensible and relatively easy to understand – scruss May 30 '18 at 17:05
  • I am definitely going to have a look at this. Thanks Will! – Maury Markowitz May 30 '18 at 20:05
  • There is considerable evidence that ehBasic is a derivative of MS BASIC. – Chromatix Jun 28 '19 at 23:45
  • do tell, @Chromatix - it would be unfortunate for Lee Davison's memory if his record of writing it from scratch were not true – scruss Jun 29 '19 at 18:27
  • Look at the source code. Most of the labels are of the form L, which is what you would get out of a disassembler, not in an original work. The code is also in a remarkably similar structure to MS BASIC; a structure you'd only expect to find in a program squeezed down to fit a small ROM, whereas by the time Lee did his work, relatively large ROMs were readily available. Finally, the syntax, quirks and performance of ehBasic are too similar to MS BASIC to be coincidental. It is unfortunate indeed, but there is too much evidence. – Chromatix Jun 30 '19 at 02:52
  • The key indicator for me is overall organization of the parser: MS did a weird double parse, tokenizing only the line number and first statement at edit time, leaving the rest of the line to the tokenized at run time. No newer design would do this, tokenizing everything at run time requires a little extra RAM but results in much higher performance and cleaner code. So which design does eh follow? – Maury Markowitz Aug 24 '19 at 12:18
  • @MauryMarkowitz: What version of MS-Basic did that!? Tokeninizing a line reduces the length, and I don't recall seeing any mechanism to accommodate that during program execution in any version of MS-Basic I've seen. – supercat Nov 25 '19 at 16:50
  • 6502 does for sure, at least the version of the code I saw. It tokenizes keywords, but doesn't do literals or variables. Atari BASIC tokenized everything, so numbers were parsed into their BCD form, strings were put into the stack, and variables were set up and replaced by a pointer to the storage. – Maury Markowitz Nov 25 '19 at 19:07
  • @supercat - oh, and of course, Tiny BASIC and its derivatives did even less. TB only read the line number and converted it to an 8-bit int, everything else, including the CR at the end of the line, was just copied directly into memory and re-tokened and parsed every time over the line. – Maury Markowitz Nov 25 '19 at 20:04
  • @MauryMarkowitz: The only thing that was tokenized were keywords, but those would be tokenized except within REM or DATA statements or within string literals, regardless of whether they appeared in the first statement or elsewhere. – supercat Nov 25 '19 at 20:11
  • "The only thing that was tokenized were keywords" - exactly. In MS there's still a lot of tokenizing going on at runtime. Atari BASIC did all of this at line entry time, which, frankly, makes a whole lot more sense. – Maury Markowitz Nov 25 '19 at 20:25
  • @MauryMarkowitz: The advantage of the MS-BASIC approach is that it makes it easy to store code in a form which can be reconstituted to precisely match what was entered. There are many ways of representing any particular floating-point value; ensuring that listing a program will output values the same way as they were entered would require storing extra information within the program. – supercat Nov 26 '19 at 00:22
  • Sure, but at the cost of performance at runtime and overall program size. The flip side is that a LIST takes longer, where the "reconstitution" time is completely buried in the I/O performance so has no real effect. – Maury Markowitz Nov 26 '19 at 12:00
  • If anything, the interpreted BASICs were bastions of compromise to balance the different needs of users under the most crushing of system limitations in both performance and space. None of them were perfect. – Will Hartung Nov 26 '19 at 16:53
6

There's Batari BASIC which is specific to the Atari 2600. It's actually quite powerful.

snips-n-snails
  • 17,548
  • 3
  • 63
  • 120
  • 2
    BASIC on the 2600?! Wow, hats off to them! – Maury Markowitz May 30 '18 at 20:08
  • 2
    Batari BASIC is a compiler that produces machine code for the use on the 2600, but the language itself isn't processed on that platform. There's also Warren Robinett's "Basic Programming" cartridge for the 2600 which could have been really neat if it had included a SARA chip (not yet invented) to add an extra 128 bytes of RAM (doubling the total storage). The cartridge manages to offer an amazing array of features while leaving 64 bytes of memory available to the user. Unfortunately, 64 bytes isn't enough to do much of anything useful, but getting the cartridge's own memory use... – supercat May 30 '18 at 21:40
  • ...down to 64 bytes is rather impressive, especially if one considers that even the act of displaying a line of twelve characters requires setting up twelve two-byte pointers so the character bitmaps can be fetched with (ind),y addressing mode. With an extra 128 bytes things would still have been very limited, but not quite as badly. – supercat May 30 '18 at 21:46
4

I've toyed with the idea of doing my own attempt at a BASIC interpreter. If you want to try your own, figure out how you can design things to deal with the following basic (pun intended) operations:

  1. Accept a line of input preceded by a number and edit the program in memory to accommodate it.

  2. Convert a program which is stored in memory into human-readable form.

  3. Run a program in memory.

The last operation is probably the most performance-sensitive, but you should try to make the first one be fast as well. The second probably isn't likely to matter from a performance perspective, but you should ensure that the amount of code required to accomplish it is reasonable. Having an input scanner convert something like

print a+b*(c+d)+e,f

into a sequence of tokens equivalent to:

var#1 var#2 var#3 var#4 add multiply add var#5 add printvalue printseparator
var#6 printvalue

would not be overly difficult, and it would allow for very efficient processing, but converting it back to the original form might be tricky.

As a general design, I would suggest that variables be converted to tokens that identify a relative location within a symbol/value table (either an index or a byte offset), and numbers should be converted to tokens that store their value in binary. While converting expressions to prefix or postfix form may slightly expedite processing, keeping them in infix will make listing much simpler. If you store strings (literal or otherwise) with a length prefix and ensure that each string in memory takes at least three bytes total (perhaps by saying that a string pointer whose MSB equals 1 should be interpreted as a single-byte string) that may facilitate garbage collection by allowing relocated strings to be replaced by a pointer to their new address.

supercat
  • 35,993
  • 3
  • 63
  • 159
1

If your looking for concepts to add to BASIC, One of the most advanced BASICS of the time was Microware's BASIC09 for the 6809. It had removed line numbers as well as added structured programming concepts. It had a number of features that took advantage of the processor that might be very difficult to do on a 6502.

Tim
  • 11
  • 1
1

The Oric 1 and Oric Atmos had a good full featured basic language for the day. Both machines used the 6502A in the old standard 40 pin package.

Back in the day (the early 80's), a friend of mine disassembled the machine code from the ROM and then extended many of the commands and added a few new ones. As I recall, the programming had to be very creative since the ROM was only 16K and the OS, as it was, only just fit within a few bytes. But anyway, that machine had a pretty good BASIC language and I'm certain if you looked around you could find a simulator for the Oric and grab the ROM code from there.

user2388107
  • 11
  • 1
  • The Oric BASIC, though well specified, was fairly buggy and very slow. – scruss May 31 '18 at 21:35
  • Oric BASIC is the hardware-appropriate adaptation of Microsoft BASIC so no matter what the range of things it does, I'm not sure it would be sufficiently much of an improvement for Maury. – Tommy Jun 01 '18 at 16:04