Part of what made BASIC so great back then was that it could be used for system level work. Still can be, though now it requires compiling to do so (as there is no BASIC interpreter at the lowest level). Because of this I am surprised that there has not been more work toward targeting simple BASIC compilers at bare metal on any system, the BASIC's of the Micro revolution were well suited to the task.
When do you think "back then" is? BASIC was invented in 1964. It ran on a time-sharing system. It was not intended for "system level work". It was intended as an easy way to get people into programming where they would them progress on to FORTRAN and who knows what.
I have not yet looked at RTB, though please, PLEASE, PLEASE support recursive parameterized Procedures, and integer variables (the two important things that were missing from some of the BASIC interpreters and compilers of that time). And please take some time to make the compiler optimizing, nothing fancy though some simple optimization's (like register order of use and redundant load/store elimination). Also please make it possible to compile with out the BASIC library (for OS specific I/O of all kinds), so that it can be used on a bare metal level.
So hang on - you're asking me about and to support features in RTB and you haven't even had the curtsey to read the manual or run it? That's a bit unfair, don't you think?
RTB does support parametrised procedures and functions. It has done for since its first public outing which was about 5 years ago (Before the Pi, it ran under most x86 Linuxes) Recursion works, as does local variables. Remember "at the time", (1960's) recursion had barely been invented.
Here is an example. This reverses a string:
Code: Select all
// FN rev:
// A reversed string is the last character of the string
// followed by the rest of the string, reversed.
def fn rev(s$)
if len (s$) = 1 then
= right$ (s$, 1) + fn rev (left$ (s$, len (s$) - 1))
Here is another classic example:
Code: Select all
def proc hanoi (A, B, C, D)
if A = 0 then endproc
proc hanoi (A - 1, B, D, C)
print "Move disk "; A; " from "; B; " to "; C
proc hanoi (A - 1, D, C, B)
RTB is interpreted - you'd have known that if you read the manual or downloaded it, so I'll ignore all your bleats about compiling and optimising. It's fast enough for what it is. RTB will never run on "bare metal" either. It needs an OS, it is not an OS. The OS provides a rich environment for it to run in and provide things like keyboard, mouse and screen to sound, networking (currently it only talks to a Pi Minecraft game, but I have more planned) and file handling to name a few.
Integer variables - well, I'll answer that after you show me an interpreter you have written that successfully mixes integer and floating point variables and constants in a sensible and efficient manner. I don't think its worth it for RTB.
If we fast forward from the 60's (which I think you are ignoring), then using BASIC for system-work... Well, that was more because there wasn't any other way - the early microcomputers of the 70's ran BASIC for a reason - at a time when we had Fortran, Algol and Pascal compilers running on big & expensive mainframe and mini computers with 100's of KB of memory, BASIC was small, cheap/free and easy to implement - a bonus when you had 4K of ROM and 4K of RAM (or less). In those systems BASIC was the OS - or rather subroutines in the interpreter provided the IO system - it was one big lump of code - limited by the memory (and probably cost as much as anything else). Towards the mid and later 70's some systems had evolved to having a small "monitor" ROM (or a bootstrap ROM and monitor loaded off a disk - and I'm thinking CP/M here) and a larger language section - the monitor providing rudimentary IO.
We had peek & poke really only to make up for shortcomings in the language and lack of space. Why load the expensive ROM with more and more keywords and code when one generic keyword would do? With peek & poke on the Apple II you could change video modes (2 resolutions, 2 pages each), make simple clicks, store machine code into RAM, read the keyboard without pausing program execution and so on. That was what they were for - to make up for shortcomings. The BBC Micro in 1981/2 had the luxury of more ROM space (so a bigger monitor, now much more like what we'd consider an OS these days), more features, but that was 4 years after the Apple II/Pet/C64/TRS-80, etc. and things were moving fast then. (and prices slowly dropping). Peek & poke in BBC BASIC were replaced by "indirection operators" taken directly from BCPL (as far as I can tell) and primarily designed for fast access to byte & word arrays - you typically didn't use them to talk to the hardware as it had dedicated OS calls to do that. (Although direct access to the "user port" was an exception IIRC. It still had overloaded operators though - the vdu and plot commands for example.
Anyway, enough here. Apologies to the Pascal people. If anyone want to chat about RTB then I'm all ears, but please do me the favour of actually trying it or at least reading the manual first.