Hello, Guest the thread was called1.1k times and contains 15 replays

last post from 12345 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.

  • Hi Paulscottrobson !


    Very nice job ! I'll have a look at your Github page and read into your project a little !

    It does sound promising, especially having the MEGA65 in mind.

  • 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.)

  • Can somebody tell me, how many sprites does the Mega65 offer? What are the memory cells for the sprites?

    _________________________________________________________________________
    Kickstarter C64, TAPunio, SD2IEC, ZX Spectrum 48k, Harlequin 128 mit ZX-HD, DivMMC Pro,
    ZX Spectrum 128 Toast Rack, Amiga1200, Turbokarte ACA1233n, MiSTer FPGA, TI99/4A mit PEB
    Atari 800 XL, PI1541, Creality CR10, Anycubic I3 Mega, Nexys A7 100T

  • Hi,


    the MEGA65 is offering 8 Sprites, like the C64 as well.... BUT....


    ... the Sprites have a lot more potential.

    In the christmas demo i wrote, i gave a good example, how you can use, in BASIC 2, a 15 color sprite, with 16 x 21 pixels.

    It uses the same Spritepointers, that you use on the normal c64.

    (You can find the whole christmas demo in ZeHa s christmas magazine for 2019. Not sure, if he still offers the magazine,

    but you can ask him in his thread.


    If you want to use BASIC10, then have a look at Zaadii 's video here


    The VIC-IV offers to support even bigger Sprites. Best to have a look in the MEGA65 manual at GitHub.


    You need to remember, that you have 3 VICs at your service. VIC-II (C64) VIC-III (C65) and VIC-IV (MEGA65).


    Also, you can use multiplexed Sprites (like on the C64) and since you are able to speed the MEGA65 up to 40MHz you could be able to do this even in BASIC. you find the code in the Blogpost how to switch to different speeds. Multiplexing in BASIC is one of the things i haven't tried for now. but i would be highly interested in your results, if your going this path.


    I hope this answer helps you to get started.

  • I played around with the Basic 10 on the Mega65 Xemu. It looks like that most is working but f.e. I was unable to use GRAPHIC options. I tried the example of the users guide (which nicely describes all Basic commands with samples) but all graphical options were somehow not interpreted. I didn't get an error message but nothing was painted (tried circle, line, polygon, box, all based on the provided sample codes in the user guide). It also might be that I have an outdated Mega65 ROM (V0.9B.911001).

    All over: it would be nice if - in the end - there would be a fully functional Basic implemented, dunno if this is the plan. As you enhance the Assembler mode (completing illegal opcodes, etc.) it also would be nice to see a working Basic version in the Mega65. Especially for the beginners Basic is a nice option to start with and I don't think it would break the C65 feeling.