Hello, Guest the thread was called3.3k times and contains 32 replays

last post from umueller-wsw at the

Entwicklungsumgebung BASIC-Compiler fuer den Mega65

    Quote from Bit Shifter

    Der MEGA65 hat ein umfangreicheres BASIC als jeder 8Bit C= Computer zuvor und ist 40 mal schneller als ein C64.

    Das ist doch die Chance, endlich einmal POKE und PEEK freie BASIC Programme zu schreiben, die gut lesbar sind.

    Intensive PEEK/POKE Benutzung ist vor allem in BASIC Dialekten zu finden, welche die Hardware nur unzureichend nutzen können.

    Das schlechteste BASIC war sicher das des C64, weshalb dieser auch so PEEK/POKE lastig programmiert wurde.

    Das BASIC-10 hingegen bietet BASIC Befehle für Grafik, Sound uvm. an. Auch SID und Sprites können ohne POKES programmiert werden.

    Gut, wenn das ein gangbarer Weg ist, dann freut mich das. Komme halt, wie fast jeder hier vom VC 20/C64.

    The problem is, that the "Mega65 BASIC" is in fact a C65 BASIC. Yes, it has the ability to control the SID - but not 4 SIDs which Mega65 has. It can handle VIC-III - but not VIC-IV extended capabilities. And you can't just load a C64 program doing SYS into C65 BASIC, type RUN, and expect it to work - it won't.

    Mega65 really needs it's own BASIC dialect, not the C65 one.

    Quote from FeralChild

    Actually, I think Commodore-like machine should have Commodore-like BASIC. Just with some extensions, hardware support, etc.


    Not wanting to open pandoras box here... but I think a little bit more modern and structured BASIC would do the Mega65 a world of good. Commodore's software engineers also started thinking along these lines with BASIC 3.5 (and Terry Ryan got sh*t for it from his manager, cf. Brian Bagnall's book) and then later even more so with BASIC 7, but there are many things still missing. Still having to rely on cursed GOTOs and GOSUBs being one of the main nuisances here.


    There's nothing wrong with a little nostalgia (after all, that's why most of us are here), but denying oneself new and wonderful possibilities by purposefully crippling the programming language just for nostalgia's sake is (imho) not such a smart move. Named procedures and functions would elevate the usefulness of BASIC to new levels, and the whole thing could still 'feel' Commodore-like.


    Just my 2ct, of course ;)

    I think this is a misunderstanding. New compilers and interpreters for the MEGA65 are welcome.

    How wonderful would be for example a Turbo Basic, Turbo Pascal or Turbo C with integrated IDE look-alike.

    But we need developers, to do do the work of implementing, documenting and testing these compilers or interpreters.

    The MEGA65 needs at least a working OS, Shell, Interpreter when the "mass production" starts.

    So the pragmatic procedure is to start with a language, that is available.

    Waiting for the development of sophisticated programming languages, would delay the MEGA65 for years.

    But hey, you can add new operating systems or programming languages languages at any time.

    Load your favourite development system into RAM or put it in flash memory.

    The MEGA65 doesn't need new ROM's or EPROM's for update or reconfiguration.

    So the current plans with BASIC-10 serve as a starting point and as a reminiscence to the C= 65.

    ubik - That's why I wrote "with some extensions" :) Procedures and local/global variable concept is nothing really new in the Commodore world, both of my childhood-favourite BASIC extensions (Simon's Basic and Warsaw Basic 3.2) had them. IMHO it would be best to extend GOTO / GOSUB commands to call these, I'm not sure how to realize the LOCAL / GLOBAL concept.


    Bit Shifter

    Quote from Bit Shifter

    But hey, you can add new operating systems or programming languages languages at any time.


    And this is exactly what I'm doing :) I want to be highly compatible with C64 Kernal and BASIC V2, and partially compatible (at least on the source code level - not necessary on the token level) with BASIC V3.5-V10. Unfortunately, I'm doing the Kernal too, so I don't have that much time for BASIC. And I still have some low-level mechanisms to implement before adding the commands on a large scale. Although recently I've made the tokenizer to work as I want, before that I've written an expression parser (with brackets and operator priority support) and several floating point routines - there is still no memory manager for variables, no float<->PETSCII conversion, and the editor itself seems to have some bugs.

    Quote from Freddy
    Quote from FeralChild

    [...]
    Mega65 really needs it's own BASIC dialect, not the C65 one.

    Maybe a BASIC similar to BBC-BASIC from Acorn Arcimedes with inline assembler?

    I never considered myself as some sort of poweruser of BASIC on any system but I totally agree with FeralChild. Freddy's idea of a Basic with an inline assembler sounds promising, while I have to admit that I have practically no deeper knowledge that BBC-BASIC you came up with.

    Quote from ubik

    [...]I think a little bit more modern and structured BASIC would do the Mega65 a world of good.[...]

    There's nothing wrong with a little nostalgia (after all, that's why most of us are here), but denying oneself new and wonderful possibilities by purposefully crippling the programming language just for nostalgia's sake is (imho) not such a smart move. Named procedures and functions would elevate the usefulness of BASIC to new levels, and the whole thing could still 'feel' Commodore-like.

    I could not agree more and wave my support flag. :)

    Quote from Datasette

    I never considered myself as some sort of poweruser of BASIC on any system but I totally agree with FeralChild. Freddy's idea of a Basic with an inline assembler sounds promising, while I have to admit that I have practically no deeper knowledge that BBC-BASIC you came up with.

    Take a look @ -> https://de.wikipedia.org/wiki/…rammierung_des_Archimedes

    Quote from umueller-wsw

    Hat jemand eine Möglichkeit gefunden, 2 größere Basic Programme miteinander zu verbinden. (MERGE)?

    Das geht mit einem kleinen Workaround:


    Zuerst das erste Programm laden.

    Code
    1. DLOAD "1.Programm"

    Dann im Direktmodus eingeben:

    Code
    1. b=(256*peek(175)+peek(174))-2
    2. poke 46,b/256
    3. poke 45,b-peek(46)*256

    Danach das zweite Programm laden:

    Code
    1. DLOAD "2. Programm"

    Dann:

    Code
    1. poke 45,1:poke 46,32
    2. clr

    Somit werden die beiden BASIC10-Programme zusammengefügt.


    Kurze Erklärung:


    In den Speicherzellen 45,46 steht die Anfangsadresse des BASIC-Programms. In 174,175 die Endadresse.


    Mit dem Workaround wird nach dem ersten Programmladen, die Startadresse temporär auf das Ende des ersten Programms gesetzt (-2, da zwei Endemarkierungen "zuviel" sind).


    Das zweite Programm lädt dann an diese neue Startadresse (was ja das Ende des ersten ist).


    Nach dem Laden wird der Start wieder auf 8193 (default) gesetzt.


    Mit dem abschließenden CLR bereinigt man "sicherheitshalber" noch die Variablen usw.