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?

  • 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? Commented May 30, 2018 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. Commented May 30, 2018 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
    Commented May 30, 2018 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
    Commented May 30, 2018 at 20:40
  • @Raffzahn - by "linked", do you mean caching the return/goto addresses? Or something else? Commented May 31, 2018 at 10:30

7 Answers 7


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.

  • Ahh, Brian, have a look at Action!, I suspect they are very similar? atariwiki.org/wiki/Wiki.jsp?page=Action Commented May 30, 2018 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. Commented May 30, 2018 at 20:36
  • Ok I'll definitely have a look here too. Commented May 31, 2018 at 20:31

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.

  • 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. mdfs.net/Software/BBCBasic/BBC/AdvBasic Commented Dec 13, 2020 at 20:29

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.

  • 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
    Commented May 30, 2018 at 17:05
  • I am definitely going to have a look at this. Thanks Will! Commented May 30, 2018 at 20:05
  • There is considerable evidence that ehBasic is a derivative of MS BASIC.
    – Chromatix
    Commented Jun 28, 2019 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
    Commented Jun 29, 2019 at 18:27
  • Look at the source code. Most of the labels are of the form L<addr>, 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
    Commented Jun 30, 2019 at 2:52

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

  • 2
    BASIC on the 2600?! Wow, hats off to them! Commented May 30, 2018 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
    Commented May 30, 2018 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
    Commented May 30, 2018 at 21:46

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.


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.

  • The Oric BASIC, though well specified, was fairly buggy and very slow.
    – scruss
    Commented May 31, 2018 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
    Commented Jun 1, 2018 at 16:04

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .