There are 210 replies in this Thread which has previously been viewed 41,778 times. The latest Post (
"Like granny said, if you want a box hurled into the sun, you've got to do it yourself"
(Hermes, "The Farnsworth Parabox", Futurama S04E15)
That being said, I have half a mind to take 6 months of vacation, brush up on my 6502 assembly and whip up a new BASIC myself... 
a generated label link list at the start will be much more faster for the correct jump to the subroutine than searching through the whole program for the right line number every time.
I just implemented such a “fast call” into TSB. It speeds up running TSB programs that use labels enormously.
By the way, it is possible to accelerate this further by prefixing the label name with an 8-bit hash value (generated from the label), so most non-matching entries are recognized when comparing the first byte.
...and if you're this far, you can then use a binary tree instead of a simple list and use the hash to decide which way to navigate through the tree: Then the search time complexity goes from O(n) down to O(log2(n)).
By the way, it is possible to accelerate this further by prefixing the label name with an 8-bit hash value (generated from the label), so most non-matching entries are recognized when comparing the first byte.
quite interestingly that's exactly the way BBC BASIC looks up functions, procedures and variables* (gone full circle here, ha! :))
*except single letter integer variables, they are at fixed locations in memory for extra speed
Nevertheless, if you would like to improve the Open ROMs BASIC - I do not plan any significant work on it in the near future, for now I am going to focus on other areas (M65 screen editor, CP/M mode, etc.)
If CP/M will run on the MEGA65 then there is still a version of Please login to see this link..
Nevertheless, if you would like to improve the Open ROMs BASIC - I do not plan any significant work on it in the near future, for now I am going to focus on other areas (M65 screen editor, CP/M mode, etc.)
If CP/M will run on the MEGA65 then there is still a version of Please login to see this link..
hmm... still not quite complicated enough. Let‘s write a BBC Micro Emulator for CP/M, so that we can run original bbc basic on an emulated bbc micro on an emulated cp/m machine on the MEGA65!
hmm... still not quite complicated enough. Let‘s write a BBC Micro Emulator for CP/M, so that we can run original bbc basic on an emulated bbc micro on an emulated cp/m machine on the MEGA65!
What about using the ZX-Uno core, there the Spectrum 3 rom then running CP/M there with 64 column display? And there the BBC Emulator? Everything with less than 10 levels to reach the goal whould be far too easy. 
@Please login to see this link., Snoopy - we will almost certainly have a line number cache for GOTOs / GOSUBs, I am also thinking about preprocessed integers/floats (if I remember correctly, at least ZX Spectrum BASIC does this), as this will speed up not only the jumps. Sure, if you preprocess the whole program first, labels will be just as fast (at least until you allow providing label as a string variable).
Sure, if you preprocess the whole program first, labels will be just as fast (at least until you allow providing label as a string variable).
Precisely. If I were you, I wouldn't bother about writing a Basic interpreter like Commodore Basic. I'd rather follow these steps:
1.) Write a (tiny) text editor and put that into rom. (You gonna need it anyway.)
2.) Write a programmme that converts a Basic source text file from the editor into a token stream. While doing so collect all user-defined identifiers and give them unique IDs.
3.) Feel free to optimize the token stream up to the level of bytecode.
4.) Finally execute the token stream. When the token stream interpreter hits a yet unspecified identifer, look it up in the list of identifiers, then replace the identifer token with a specific token e. g. variable, label, procedure so that next time execution will be a lot faster.
N. B.: Tokenization on a 40 Mhz computer is quite fast and barely noticeable, but gives you a tremendous boost in execution speed afterwards - especially with dereferenced identifiers.
BTW: If you aim for a Basic dialect, please define the language in such a way that every FOR-statement will be closed by one and only one NEXT-statement. On the one hand this will improve the readability, on the other hand it will open up the possibility of writing an additional full compiler for that language.
But I do not intend to drop line numbers - I would like to stay reasonably compatible with BASIC 2.0 even in M65 native mode.
Couldn't line numbers at least be made optional? I.e. there if you really want them but absolutely unnecessary if you don't?
This is the way BBC BASIC works in its 32-bit versions (i.e. on RISC OS). There, you can write your BASIC programs entirely without line numbers, and it's standard practice not to use them – though you can if you really must. But you'll be hard pressed to find any BBC BASIC program on RISC OS with a GOTO or GOSUB in it. In fact, a sizeable proportion of multitasking RISC OS desktop applications are actually written in BASIC. The language is so fast on RISC OS that in most cases it's on a par with compiled C code, for example, and the structuring is also so good that you can write neat and modular desktop applications, and you simply don't need ugly GOTO/GOSUBs.
Anyway, my point is that NOT using line number encourages better programming practices. Certainly, you should keep them for backwards compatibility etc., but I'd encourage being able to have them turned off by default. Any good modern version of BASIC really shouldn't need GOTO/GOSUB and line numbers at all.
Write a (tiny) text editor and put that into rom. (You gonna need it anyway.)
Absolutely – taking this approach would make it much easier to write BASIC without line numbers, and discourage the use of GOTO/GOSUB in favour of writing better structured code.
@M. J.
I’m not interested in BASIC not compatible with CBM BASIC 2.0. For me the priority is to be able to run the old software and to make it easy to adapt it to the new capabilities. There are better machines to learn modern programming. But, of course, everybody is welcome to come with his own BASIC
It would certainly be possible to hide line numbers (with dummy numbers) from the user this way or another, but you would need a specialized editor, it wouldn’t be possible to use the CBM-like command line. Quite some work, though, to make it a sane tool.
I’m not interested in BASIC not compatible with CBM BASIC 2.0.
Like Hermes' granny (God rest her zombie bones) said:
"if you want a box hurled into the sun, you've got to do it yourself"
Every MEGA65 owner should have his own very personal BASIC! Of course not compatible to the others!
It’s always good to have options like BBC Basic, although to attract younger people, some form of the Python language would be needed.
I'm afraid full blown Python is too heavyweight. But Please login to see this link. should be a pretty good match for the machine. Personally I'd love to have a Please login to see this link. m65 backend.
It would certainly be possible to hide line numbers (with dummy numbers) from the user this way or another, but you would need a specialized editor, it wouldn’t be possible to use the CBM-like command line. Quite some work, though, to make it a sane tool.
That's why I reacted positively to @M. J.'s suggestion of a built-in text editor. Such a tool could be relatively simple but still a very good BASIC editor; it'd obviously just need to do the specialised job of tokenising/detokenising BASIC programs. But when editing them, it could default to not showing line numbers at all (unless the user turned them on). And when retokenising the BASIC, it would effectively do a 'renumber' operation so that it's another thing not to have to worry about.
Thus, listing the program at the CBM command line you'd still get a normal listing with line numbers as you'd expect, but in the editor you'd edit the content without needing to see any line numbers at all.
For what it's worth, that's how it works on RISC OS. You can go to the command line and enter BASIC, list programs and see their line numbers as you'd expect. But edit those same programs in a desktop multitasking general-purpose text editor and you don't see any line numbers at all (unless you choose to). It's a good way to work. Even a quite simple text editor is usually much preferable to editing BASIC at a command line.
For me the priority is to be able to run the old software and to make it easy to adapt it to the new capabilities.
Of course, it's your decision and totally up to you, though personally I would consider this a missed opportunity. For ZeHa's last Christmas Basic Magazine I contributed a little Basic game, which was not developed on a C64, but on a PC using a standard text editor. AFAIK other people used the C64 Studio for developing. After 30 years of writing programmes wth at least a text editor I just cannot imagine myself in the year 2021 still using a line number based language with a line editor especially for large programmes, and I fear this will also be the case with other potential programmers. In the end, your CBM BASIC 2.0 compatible language might not be as widley used as expected despite all the time and effort you will have put into the project. 
Richard Hallas is right: The Mega65 needs an easy to use modern language like the Risc OS Basic so that every user can write his/her own tools, system add-ons, games and other things. For comfortably writing such programmes CBM Basic 2.0 and its successors lack too many language features like local variables or subroutines with parameter lists but also the ability to include further source files (e. g. libraries).
everybody is welcome to come with his own BASIC
Very true, of course.
Just as a suggestion on how to accomplish this one might do the following:
1.) Write a compiler on a PC in a language like C or Pascal that accepts a source file in the target language and fully compiles it to byte code.
2.) Write a byte code interpreter for the target machine (maybe also for the PC).
3.) Convert the compiler source code (C, Pascal...) into its own target language.
4.) Compile the new compiler code (written in the target language) with the old compiler (written in C, Pascal...)
5.) Run the byte code of the compiler on the Mega65 to compile further programmes directly on the Mega65.
IOW: typical bootstrapping approach.
In 1985 we used Apple//e computers at school which ran ApplePascal (aka USCD Pascal). This system was completely based on byte code (including compiler and editor). Still, even then we were able to write small games that ran fast enough although the 6502 of the Apple//e only ran at 1 Mhz, plus the Apple//e did not have sprites or a char mode to display graphics, and the byte code was interpreted. Just editing and compiling was hard due to lack of memory and having to access the floppy all the time. However, this does not apply to the Mega65, and here a byte code interpreter might even be a good way to get around the limitations of an 8 bit processor while the size of the code file remains rather short and the execution speed is noticeably faster than interpreted (CBM) Basic.
Of course, it's your decision and totally up to you, though personally I would consider this a missed opportunity.
I agree with everything you write, 100% (obviously, that's why I started this thread ;-))
That being said... of course I have the utmost respect for what @FeralChild is doing with Open ROMs, and if he wanted to include a IBM/360 emulator with a backport of MS BASIC 1.0 in his work, that would of course be totally ok, too.
But it's also my belief the M65 as a platform would gain tremendously if somebody came and implemented an at least somewhat modern version of BASIC; because that would people give the opportunity to do really great stuff easily and without having to resort to cross developing.
I have a BBC Micro standing beside my DevKit here, and I can't help feeling a little bit sad that the 37 year old machine's programming language is way more advanced than what is going to go into the M65.
So, we need someone (or a group of people) to tackle the BASIC problem in the long run... 
. After 30 years of writing programmes wth at least a text editor I just cannot imagine myself in the year 2021 still using a line number based language with a line editor especially for large programmes, and I fear this will also be the case with other potential programmers.
(shameless plug):
As I have the feeling that this situation won't likely be resolved anytime soon, maybe the path I went with "Eleven" would be at least a temporary solution. Official announcement is here:
Please login to see this link.
Provided something like named procedures and functions is going to be included in the Open ROMs, I could very well imagine porting Eleven – or something Elven-like – to the Open ROMs, this time around written in assembly or C, of course. That would give people kind of the best of both worlds.
Richard Hallas , @M. J. I will keep your remarks in mind. The tokenizer will need one more rework nevertheless, and for now the Open ROMs BASIC is too limited to write anything serious (big missing: floating point support - although some code already exists).
For using BBC BASIC you only need a browser!
Please login to see this link.
For using BBC BASIC you only need a browser!
Please login to see this link.
I know! Yet another good example of how widespread, accessible and popular it is – all good reasons for porting it to the MEGA65! 
