Announcing VC83 BASIC, a BASIC interpreter for the 6502

[WillisBlackburn]

I've completed my project to implement BASIC in 6502 assembly language, repeating a feat performed many times before!

I've been working on a retrocomputer project and wanted a BASIC to run on it, and I wanted to implement it myself in order to have full control over the user experience, vs. just running the same old Microsoft BASIC. I thought it would take a couple of months, and now, four years later, it's done. It's a full-featured 8K BASIC and includes support for floating point, arbitrary-length variable names, multidimensional arrays, and dynamically-allocated strings. There are a few things that I forgot, e.g., RESTORE accepts a line number but doesn't actually do anything with it, and LOG doesn't reject negative inputs, but it mostly works. Incremental improvements to follow.

My idea is that the core interpreter fits in 8K but platform-specific extensions can take it to 10K or 12K. I haven't built my retrocomputer yet, so the project targets the sim6502 simulator that comes with the cc65 compiler package, and the Apple II. I've implemented the GR and TEXT statements that are unique to the Apple II as examples of how the platform extension mechanism works. There's currently no support for platform-specific functions, but I'll be adding that soon. Also, uh, it doesn't quite fit in 8K... I'm about 100 bytes over... but I think I can trim it down.

VC83 BASIC is available under the MIT license, so you can use it for your project. No need to ask, just fork and go. But if you reach out, I can help you adapt it to your platform.

Enjoy!

Project on GitHub: https://github.com/willisblackburn/vc83basic

Announcement on Reddit: https://www.reddit.com/r/retrocomputing ... _the_6502/

[BigEd]

Splendid - 8k and with floating point, that's great!

[jgharston]

Your BASIC shouldn't target the hardware. Your operating interface should target the hardware.

[WillisBlackburn]

jgharston wrote:

Your BASIC shouldn't target the hardware. Your operating interface should target the hardware.

Not sure what you mean! Did you look at the code? What do you think I should change?

[barrym95838]

jgharston wrote:

Your BASIC shouldn't target the hardware. Your operating interface should target the hardware.

Unless they are the same block of code. Elegant interfaces and hardware abstraction layers are nifty, but not necessarily a best fit for everyone.

[BigDumbDinosaur]

barrym95838 wrote:

jgharston wrote:

Your BASIC shouldn't target the hardware.  Your operating interface should target the hardware.

Unless they are the same block of code.  Elegant interfaces and hardware abstraction layers are nifty, but not necessarily a best fit for everyone.

It all depends on your target “audience.”

In general, I agree with Jonathan that a language compiler/interpreter should be hardware-agnostic, especially if you are offering your compiler/interpreter to the world at-large.  However, if you are just designing for yourself or if you are tightly integrating language capabilities with machine resources a la the Commodore 128, you can throw the HAL out the window.

[WillisBlackburn]

I think that what jgharston might have meant is that BASIC should interact with the hardware through some kind of interface so that the interpreter itself can remain platform-neutral. But, had he looked at the project, he would have found that VC83 BASIC does in fact do that. Each platform implements several functions:

• initialize_target: Called once at startup
• readline, write, putch: I/O functions
• ex_statement_name_table and ex_statement_name_vectors: Platform-specific statements

The interpreter core doesn't try to do anything that can't be done in a platform-independent manner. It doesn't even support commands to load and save the program because those tend to vary a lot from platform to platform.

Obviously there's little need for a new BASIC interpreter for the Apple II. I included the Apple II version to keep myself honest about the interpreter being capable of running on multiple platforms.

[dmsc]

Hi!

This is great, another open source BASIC interpreter for the 6502

I made a minimal port to the Atari 8-bit, only including a "DOS" statement. IMHO, for this to be more useful, you should add (minimal) "SAVE" and "LOAD" statements.

I suppose the floating-point support is written by yourself - so it is a new 40bit floating point code for the 6502!. I will look to see if I can use it in FastBasic - currently FastBasic uses the Atari BCD floating point support, and this is slow and not portable, so a new implementation using faster binary fp should be a great addition.

Have Fun!

[WillisBlackburn]

dmsc wrote:

I made a minimal port to the Atari 8-bit, only including a "DOS" statement. IMHO, for this to be more useful, you should add (minimal) "SAVE" and "LOAD" statements.

That's great! Want to contribute it back? If it runs *at all* then it's an improvement over what was there before. Also the Atari has a hardware PRNG so that would enable me to platform-ize random number generation.

dmsc wrote:

I suppose the floating-point support is written by yourself - so it is a new 40bit floating point code for the 6502!. I will look to see if I can use it in FastBasic - currently FastBasic uses the Atari BCD floating point support, and this is slow and not portable, so a new implementation using faster binary fp should be a great addition.

Yes, I wrote it, and you're welcome to use it. I'm in the middle of making a few improvements so it might change a bit but not dramatically. I think that FP is a part of the code where there are a lot of opportunities for optimization, so I'm not certain it will outperform the Atari. Since you have it running, you could run a few benchmarks and find out for yourself. Let me know if you see any potential optimizations or if you implement any yourself.

[WillisBlackburn]

Never mind about contributing back, I just saw your PR!

[BigEd]

Umm, should I be able to nest FOR loops? Something goes wrong with this:

Code: Select all

10 H=4
20 ND=80
40 E=1:FOR I=1 TO H:E=E*10:NEXT I
50 L=0:I=1
51 L=L+1:I=I*2:IF I<=E THEN GOTO 51
60 ND=H*(INT(ND/H))
65 PRINT ND
70 N=L*ND/H:DIM R(N+1):C=0:Q=2*INT(E/10)
80 FOR I=1 TO N:R(I)=Q:NEXT I
90 FOR K=N TO 1 STEP -L
95 D=0
100 B=K+K-1
110 FOR I=K TO 1 STEP -1
120 Q=D*I+R(I)*E:D=INT(Q/B):R(I)=Q-B*D:B=B-2
130 NEXT I
140 PRINT RIGHT$(STR$(1E6+C+INT(D/E)),H);
150 C=D-E*INT(D/E)
160 NEXT K

[WillisBlackburn]

Replace 1E6 with 1000000. The parser recognizes 1E6 but the interpreter doesn't handle it yet. Working on it!

The reason you get weird behavior is that the interpreter assumes that the structure of the post-parser tokenized program is valid, so when it finds 'E' after a number, instead of the expected operator token or terminator, it does... something...

[BigEd]

Ah - excellent, thanks!

Probably expected, but PRINT "lowercase" goes a bit wild, in a listing. It RUNs OK though.

[WillisBlackburn]

Someone else brought that to my attention. It's a consequence of my using lowercase letter values to tokenize function names. I'll fix it.

The GitHub master branch understands "E" now, so your program works without any changes. I'm not proud of the implementation, but it works. Converting between base 10 and binary floating point is very difficult; the correct algorithm requires arbitrary-precision arithmetic and was first published in the 1990s, and that algorithm is too complicated to implement in 8K BASIC. So it's all about coming up with an algorithm that minimizes error while still being compact.

[BigEd]

Splendid, thanks!