Beiträge von Diddl im Thema „Wrapper für Basicfunktionenverbindung“

    bei demos, die 100% genaues timing brauchen, gebe ich dir recht. aber mein anspruch ist es schon, ein "flottes spiel" in c zu programmieren. mal schauen, wie weit ich damit komme ...


    Von der Geschwindigkeit dürfte das kein Problem sein, davor bekommst du Platzprobleme.

    Wenn es wirklich eng wird mit der Geschwindigkeit hilft immer noch kleinere ASM Teile für kritische Sachen.

    Jetzt einverstanden? :smile:


    natürlich.

    Im Prinzip hast du ja auch mit der vorherigen Aussage Recht. Ich will nur vermeiden dass Anfänger Assembler lernen. Ich glaube von C haben die mehr und Assembler können die dann in Grenzfällen immer noch zusätzlich machen.

    Begründung

    • Assembler - man muss dafür geboren sein. Viele Menschen verzweifeln/scheitern daran
    • Ich halte einen C/Assembler Hybriden fpr die bessere Lösung als puren Assembler
    • Assembler ist selbst für den Entwickler selbst mit der Zeit unleserlich
    • Der Zeitaufwand ist 10 mal so hoch wie in C
    • Assembler ist praktisch unportierbar
    • Das Wissen das man in Assembler aufbaut ist nur sehr begrenzt einsetzbar (nur auf der selben CPU Type oder sehr ähnlich).

    Richtig, nur so kann man das Gerät richtig kennenlernen. Und wer Assembler kann wird C auch viel besser verstehen.


    Sorry aber dem kann ich nicht zustimmen.

    Ich MUSS auch in C ein Gerät wie den C64 sehr gut kennen, sonst wird das nix. Und ich kenne persönlich viele Leute die sehr gut C können aber mit Assembler nix am Hut haben.


    Ein Argument lasse ich gelten: Die Architektur des C64 ist nicht sehr gut geeignet für C. Aber sonst hat C nur Vorteile, ganz davon zu schweigen dass ich den Code mitnehmen kann auf andere Hardware und auch meine Programmiererfahrung. Wenn ich Assembler kann, dann nützt mir das heutzutage nirgendwo etwas (außer am C64 im Extrembereich) ...

    Oder RR/MMCR/1541u RAM/ROM dafür verwenden.


    DAS wäre natürlich END-GENIAL!!! :juhu:


    Eine CC65 / MMC-Replay edition!! Durch das MMC-Replay wäre man nicht auf 16KB beschränkt, sojndern man hätte bis zu 512KB. Alle runtime Libs als binary im EEprom!! Mit automatischen Banking je nachdem welche Routine man aufruft.

    Die CC65 Programme wären sehr klein, auch wenn man printf und float verwenden würde.

    Alle ROMs abschalten. Da ist eh kaum etwas brauchbares drin.


    Das sind harte Worte, aber aus Profisicht nicht ganz unrichtig ... :roll2:

    Zumindest die Reset Initialisierung braucht man immer. Die IO Routinen des Kernel für IEC Zugriff wird man normal auch nicht zu 100% ersetzen.


    Im Falle der Float Unterstützung für der CC65, - da macht die Verwendung der ROM Routinen schon Sinn, weil die halt keinen Platz im wertvollen RAM Speicher wegnehmen.


    Die bessere Alternative zu ROM komplett ausblenden wäre ein spezielles CC65 ROM! Dann hätte man 64KB + 16KB (für Stdlib + float).

    Verstehe ich das richtig? Sowas wie Inline-Basic im c-Quelltext?


    Inline Basic wird nicht gehen, dann müsste man einen Tokenizer implementieren und es würde zuviel Platz brauchen.


    Ich denke an ein cc65 Programm was für eine höhere Adresse kompiliert wird, zb. ab $6000 bis $e000. Man könnte so beliebige kleine Basic Programme nachladen (Variablen Obergrenze auf $6000 + NEW).

    Ein kleine Routine im Kasettenpuffer blendet das Basic ROM ein, ruft den Basic Interpreter auf und startet das Basic Unterprogramm. Nach der Rückkehr wird das ROM wieder ausgeblendet und zum CC65 Programm zurückgekehrt.

    -------

    Man müsste "nur" die ChrGet Pointer setzen auf die richtige Zeilennummer. Dau könnte müsste man sich nur von $0801 an Zeile für Zeile durchhangeln.

    Vielleicht geht es sogar noch einfacher, die GOSUB Routine im ROM sucht sich ja auch die Zeile schon selber.

    ch hab gesagt ich bastel grad an nem wrapper für die floating point routinen. alles andere im basic rom werde ich fein weiter ignorieren, da es meiner meinung wenig sinn macht irgendwelche der basic befehle direkt aufzurufen


    Befehle machen wirklich keinen Sinn. Wer will schon POKE, FOR oder PRINT aufrufen. Aber alle Funktionen machen auf jeden Fall Sinn: +,-,*,/,Sin(), Cos(),Tan(),Rnd(),Ti(),Ti$() ...


    Was aber schon einen gewissen Reiz haben könnte, das ist ein GOSUB Wrapper für CC65. Man könnte kleine, feine Basic Lösungen als eine Sammlung von Unterprogrammen halten und per CC65 aufrufen ...

    Code
    :    :
       ExecGOSUB(2000);                  // Basic Code ab Zeile 2000 ausführen bis RETURN
       :    :