While some of you were talking about the tiniest Tiny BASIC, I have been busy paraphrasing TSC Micro BASIC Plus to the 6502.

https://ia903409.us.archive.org/34/item ... asic_a.pdf

It is a relatively powerful integer BASIC running on the SWTPC 6800 computer. It was designed to be loaded from tape. User programs may be saved or loaded by escaping to the system monitor and using its "punch" and "load" capabilities, then warm starting back into the interpreter.

I am happy to be able to report that enough progress has been made that it is an ongoing project instead of a speculative experiment.

The following features have been implemented:

* Enter, list, delete and replace program lines
* Run program
* Print a number, variable or a constant text string (it does not support string variables)
* Assign a number or a variable to a variable including "implied" LET
* GOTO, GOSUB, RETURN, ON GOTO and ON GOSUB

I am currently working on FOR and NEXT.

Features still to be implemented:

* Most of expression handling including operators and the functions RND, ABS and SGN
* DIM for arrays
* IF
* DATA, READ and RESTORE
* INPUT

The original 6800 version utilizes self-modifying code in several places so it cannot reside in ROM. I do not do any of that.

Micro BASIC Plus allows use of a variable or expression as the target of a GOTO or GOSUB. You can write code like:

As far as I know, no other BASIC can do this. Not even Microsoft.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

BBC Micro BASIC had it and when I was lookin for it online, I found this manual

https://www.4corn.co.uk/archive/docs/BBC%20BASIC%20Reference%20Manual-opt.pdf see here, on page numbered 84 (95. page of the PDF, but it is counting preface and index too)

_________________
http://micro-corner.gilhad.cz/, http://8bit.gilhad.cz/6809/Expanduino/Expanduino_I.html, http://comp24.gilhad.cz/Comp24-specification.html, and many others

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It's pretty standard in TinyBasics - my own one works like this too. Here is a example from my xmas tree lights on the 6507:



It works in the main program as:



-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Got bogged down in NEXT as it makes use of the ADD and SUB parts of the complex and voluminous expressions and operators package.

Took a detour and implemented INPUT then DATA, READ and RESTORE.

The Micro BASIC Plus rendering of DATA statements is quite different from other BASICs.

In most of the others, all of the DATA statements within a program are treated as if they were one data pool.

Micro BASIC Plus remembers the most recently encountered DATA statement as the "current" data pool. An error results if READ is used before any DATA statement has been encountered. Reading more values than exists in the current statement restarts at the first item in the statement. RESTORE also sets the next READ to get that first item.

It is not clear why it was done this way. Existing code to search the program for a line number can be easily modified to search for DATA statements. Maybe they were tight on code space and could not afford that.

The only advantage I can see is that data can be localized to the code which uses it. Some other BASICs allow specifying a line number with the RESTORE statement to indicate where the next READ picks up. That would be an equivalent way to do the same thing.

Hi!



This is standard in Atari BASIC, where you even see code like GOTO STICK(0)*10+200 for processing the joystick. In Atari BASIC each number is encoded in 6 bytes, so doing "L1000=1000" and then multiple "GOTO L1000" used less memory, this technique was used in a lot of BASIC games.

Have Fun!

Apple integer BASIC (and, I assume Apple 1 basic which it was derived from) allows this as well.

Thank you for enlightening me as to which BASICs also allow specifying a target with a variable expression.

Now why do some prohibit that? Clearly it is slower than an absolute line number. Why not just document that fact and allow it anyway?

The compiler writer in me says that compiling a variable target is much more difficult. Essentially, a list of the addresses corresponding to the set of line numbers much be stored and searched when the jump is made.

By the way, FOR/NEXT now works for the simple case. More testing is needed. I can see the finish line from here...

I suspect it's explicitly tested for - ie. when you parse a GOTO/GOSUB then you either look for a number explicitly, or almost lazily just call your generic expression evaluator to get that number. Once you have then number the rest of the processing is the same.

And if you can GOTO an expression then it eliminates the need for ON x GOTO a,b,c ...

Or conversely if you really want ON x GOTO, then deliberately block GOTO expression...



But in BASICs you have a generic expression evaluator, so you save space by just calling it to get the number. There are very few BASICs that store a separate list of line numbers -> addresses. Most (at least in the 8-bit world) have just a line number and end of line token, or line number + length. The latter is in my TinyBasic - so GOTO/GOSUB involves a linear search, but at least it can skip lines as it knows their length.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

ON GOTO is arguably a bit more "structured" because the number of possible targets is limited. GOTO X can go anywhere...


I was talking about compiling the program into a binary image. There is no source code, even in tokenized form, to search.

Another of my many projects is a BASIC compiler to translate a program written in the TSC FLEX BASIC or XBASIC dialect into 6800 or 6502 assembly language.

The initial prototype generated code at the beginning of each line of source to store the line number into a variable for error reporting. Later versions quit doing that, but generated a list of line number/address couplets which is binary searched in case of error reporting. The run-time overhead is moved from normal execution to only in case there is an error.

Run-time error reporting in an 8-bit compiled binary? That's very fancy, at least in my limited experience. How common is that, really?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I added the length feature to VTL02, and included a condition that would allow "find" to start the linear search at the next line rather than the first line, making forward "GOTO"s less clunky. It worked so well that I decided to re-use it to find the next line during normal execution as well, at the expense of a handful of clocks.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

ON ERROR needs to know the number of the line executing when an error occurs so that it can RESUME back to the correct line. Since that information is already available, an unhandled error is reported with the error number along with the number of the line.

It might be interesting to know just how many forward references there are in a program - however this may vary during writing of that program. Would the overhead of saying "is the target greater than the current line number, or less than or equal?" and picking the appropriate algorithm worth the time to do the test and the extra RAM needed (in a minimal RAM system) ?

I think you might need a good selection of old BASIC programs to find out...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/