Hello, Guest the thread was called512 times and contains 12 replays

last post from paulscottrobson at the

Mega BASIC - In development

  • Hi. (Or Guten Morgen. I've just okayed pages of legal stuff in German. I can speak "Holiday German" when I visit .... but not legal German)


    I'm the bloke working on the open source replacement BASIC which is at https://github.com/paulscottrobson/6502-Basic . There is a reason for the name. It's a cross 65xx platform version. So it will run on a 65C02 (anyone who wants it), a 65816 (with Lenore Byron's project in mind) and the extended 4510 and take advantage of each. Currently I'm working towards loose Microsoft compatibility. Then adding nice stuff like named procedures. Then adding specifics for the Mega65.


    That's version 2. I really don't like BEGIN/BEND and the DO LOOP. So we will have WHILE/WEND and REPEAT/UNTIL and IF/ELSE/ENDIF multiple lines and so on.


    Most of the core is done. There are a few improvements to that. Firstly it does maths in integer unless you absolutely insist on introducing floats. Integers are 32 bits. Variables can be up to 31 characters long. There are three types, using % $ and # for real as the last character, and the default can be anything you want (realistically most work is done in Integers - if you use float variables it has to convert it to/from float for storage). It is a little, but not significantly quicker than MS Basic, unsurprisingly, because it's largely doing the same thing. A = A + 1 involves much the same binary manipulation. I've started on command words (other than LET, RUN etc.). Including GOTO. You just won't need GOTO.


    M65 is much quicker, of course, and I haven't made any 4510 specific optimisations yet, though the framework is all there. In FP math for example there's a lot of mantissa shifting going on, which on a 6502 takes four seperate instructions, and a 65816 two. The M65 does it in one instruction


    No specific losses. One limitation is data. Program Data is limited to a 64k block (the actual program can fill the whole memory space anywhere). However, the plan is that this is only actual variables ; things like tiles, graphics and sound are kept elsewhere.

  • Nice project - what are your plans for the future?


    Please note, that we have another open ROM project already - https://github.com/MEGA65/open-roms (and my work-in-progress fork, https://github.com/feralchild64/open-roms, I mostly focus on Kernal development), it would be nice if we didn't duplicate the effort.

  • It's now at the stage where I can benchmark it a bit. I coded REPEAT/UNTIL last night so it gives me very rough comparisons with the old BASIC benchmarks. It's a bit quicker than CBM Basic 2.0 (at equivalent 1Mhz clock, obviously) with Floats, and about 30-40% quicker with integers. Very roughly.


    Of course on an M65 it goes like a train, even without the optimisations (it's still just running 65C02 code, except when it's reading program data).

  • Nice project - what are your plans for the future?


    Please note, that we have another open ROM project already - https://github.com/MEGA65/open-roms (and my work-in-progress fork, https://github.com/feralchild64/open-roms, I mostly focus on Kernal development), it would be nice if we didn't duplicate the effort.

    PGS is okay with it, so I don't think it's an issue. I'm not doing any Kernel work at all, save a very simple interface to the hardware. Nor is it an extension, nor is it remotely binary compatible, though it is pretty much text compatible. It can't be completely so. This is in some ways a good thing ; Paul was very keen that it shouldn't be based on the available Microsoft BASIC source and things like the Floating Point Arithmetic are completely different. The whole implementation is different ; it has nothing from it at all.


    Immediate next stuff is adding in more CBM stuff, and some other stuff IF THEN / IF ELSE ENDIF / WHILE WEND / ON GOTO GOSUB / FOR NEXT / READ DATA RESTORE/ POKE DOKE LOKE / WAIT / DEF FN / GET / SYS / TAB / POS and Garbage Collection.

    Then get the line/program editing working.

    Then probably Procedures and Locals, an inline assembler like the Acorn one, and File I/O stuff.

    Then Mega65 specific stuff.

  • There are a few improvements to that. Firstly it does maths in integer unless you absolutely insist on introducing floats.

    Just a side note: The idea of BASIC was to be simple for beginners, which included the unification of number types. The orginal Dartmouth BASIC had one number type only, which was float. That way, a novice programmer didn't have to care about whether or not his choice of a variable type was fitting. That's why the inventors didn't like Microsoft's versions of it, for example, which added integer variables (albeit poorly implemented) to the mix. Switching back to integer as a default somehow is against this basic (no pun intended) idea. I just wanted to mention this, it's not meant as a criticism in any way. I have a feeling that people forgot about why BASIC is using floats in the first place and view it as a stupid oversight rather than a design principle of the language itself.

  • Great!

    As soon as the IF THEN, POKE and FOR NEXT is done, we allready can use and test it.

    The other commands can be left out for some first program (if you know that you have to avoid it).

    :thumbup:

    The main thing missing from being useable directly is you cannot do anything from the keyboard - enter/edit code, run commands etc etc. It does run on the M65 hardware (well, the FPGA board !) but code is currently tokenised by a Python script and sent over as part of the binary.

  • There are a few improvements to that. Firstly it does maths in integer unless you absolutely insist on introducing floats.

    Just a side note: The idea of BASIC was to be simple for beginners, which included the unification of number types. The orginal Dartmouth BASIC had one number type only, which was float. That way, a novice programmer didn't have to care about whether or not his choice of a variable type was fitting. That's why the inventors didn't like Microsoft's versions of it, for example, which added integer variables (albeit poorly implemented) to the mix. Switching back to integer as a default somehow is against this basic (no pun intended) idea. I just wanted to mention this, it's not meant as a criticism in any way. I have a feeling that people forgot about why BASIC is using floats in the first place and view it as a stupid oversight rather than a design principle of the language itself.

    Indeed. Most early computers didn't have integers at all. The plan is to leave the default as float but have DEFINT A-Z, or similar. I think (personally) it's bonkers to change the default depending on the first letter (probably a hangover from FORTRAN)

  • Great!

    As soon as the IF THEN, POKE and FOR NEXT is done, we allready can use and test it.

    The other commands can be left out for some first program (if you know that you have to avoid it).

    :thumbup:

    The main thing missing from being useable directly is you cannot do anything from the keyboard - enter/edit code, run commands etc etc. It does run on the M65 hardware (well, the FPGA board !) but code is currently tokenised by a Python script and sent over as part of the binary.

    But is this really a problem?

    I think not.

    If I have understood you right, for example the Input command is allready implemented.

    So while the programm is running the input will be supported by the OS, not the BASIC.

    This means that the only thing you have to do is to write the code oustide and then load it inot the system, right?

    So, this is anyways, how I did, all my MEGA-Programm so far.


    Well, ok. At least LOAD and RUN should work...

  • No, haven't done INPUT yet :) It is very much like that, but it's very primitive ; this is mainly because it's being built ground up. So the arrays, variables, arithmetic and so on all works (except for the Taylor series stuff), but the commands are coming along.


    Chapter & Verse is this file header.src which is the current state of play. Not everything marked "Not implemented" will be implemented as some of the tokens are syntactic. (It is Python generated which is why it looks odd.)