Hallo Besucher, der Thread wurde 9,2k mal aufgerufen und enthält 33 Antworten

letzter Beitrag von MauriceMEGA65 am

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.

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

    Zitat von FeralChild

    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.

    Zitat von paulscottrobson

    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.

    Zitat von Zaadii

    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.

    Zitat von EgonOlsen71
    Zitat von paulscottrobson

    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)

    Zitat von paulscottrobson
    Zitat von Zaadii

    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?

    ___________________________________________________________________________
    Ultimate64, TAPunio, SD2IEC, ZX Spectrum 48k, 1581 Replik, C64 Laptop, C64 MK II, C116, SX64,
    MiSTer FPGA, TI99/4A mit PEB, Atari 800 XL, Anycubic I3 Mega, Mega65, C64 Modular, Uniprom64

    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.

    Quite astonishingly I have been lobbying for a new MEGA65 BASIC for six long months now, but I haven't been aware of this project previously (in fact I mistakingly thought it simply related to the BASIC of the Open ROMs)...


    So I have a few quick questions:


    Is this still actively developed? If yes, how‘s the MEGA65 port coming, and do you need any help with it? Because MEGA65 needs you :)


    Great advancements have been made fixing and enhancing CBM BASIC10, but it's at its heart still a convoluted, hazardous and archaic affair.


    I still think it would be absolutely wonderful to have MEGA65 ship with the choice of 1) the fixed version of original CBM BASIC, and 2) a beginner-friendly, powerful and modern implementation of BASIC.

    Zitat von ubik

    I still think it would be absolutely wonderful to have MEGA65 ship with the choice of 1) the fixed version of original CBM BASIC, and 2) a beginner-friendly, powerful and modern implementation of BASIC.

    As much as I understand this project, it's a BASIC for the various platforms. But not ON them. Some Phyton scripts take the textfiles with the BASIC program and tokenise them for the use on the platforms.

    Basic 10 is being worked on (and currently named Mega65 Basic on the newer ROM’s) by Big Shifter.

    The Basic examples in the manual are indeed not all working and some outdated. Since last week I’m in the process to validate each single Basic example in the manual and correct them when needed, or have them corrected by Big Shifter as he exactly knows the changes in the Rom.

    So yes, MEGA65 will have an improved Basic 10 with up-to-date examples in the manual.

    The latest manual will already have some examples fixed.

    Zitat von MauriceMEGA65

    Basic 10 is being worked on (and currently named Mega65 Basic on the newer ROM’s) by Big Shifter.

    The Basic examples in the manual are indeed not all working and some outdated. Since last week I’m in the process to validate each single Basic example in the manual and correct them when needed, or have them corrected by Big Shifter as he exactly knows the changes in the Rom.

    So yes, MEGA65 will have an improved Basic 10 with up-to-date examples in the manual.

    The latest manual will already have some examples fixed.

    Thanks, I'm quite aware of that. In fact, I played a little role in it.


    But my question was not relating to BASIC10 at all. It's true that BitShifter has made tremendous fixes and enhancements to BASIC10, and he deserves nothing but the highest praise for that... but the fact stands that BASIC10 is (and always will be) a woefully inferior implementation of the BASIC language (which btw is one of the reasons why I wrote the Eleven development system).


    Yes, I know, many folks want to keep it there to "keep the C65 feeling" and "be true to the original" and "be compatible to the 5 BASIC10 programs that already exist", etc., etc. pp., and that's completely fine and good and understandable I wholeheartedly support that notion, and I don't have anything against it, and as far as I am concerned it may stay there forever... but I also very much would like a modern implementation of BASIC on the MEGA65, and I think the platform would *greatly* benefit from something that doesn't rely on floating point math, two-letter-variable names and line numbers, all of which were anachronisms in 1992 already.


    (sorry if I sound a little bit irritated, but I have been writing this for over six months now... :alt:)