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

last post from wweicht at the

Alle Floatbefehle von Basic kann man nutzen für GEOS2.5

  • Jetzt klappt es mit dem Floatbefehl von Basic für GEOS2.5
    Kann jetzt alle Basic-Floatbefehle in GEOS2.5 nutzen. Sinus..Cosinus..Mult..DIV usw.


    Kann die Werte(String) von $100 nach $7f40 verlagern.
    Test ist 2xPI.
    Wie kann ich jetzt bitte die Werte in GEOS darstellen?


    Danke.
    Gruss


    Die Funktion in ASM für GEOS für den cc65 :


    Der cc65 Code:

  • Könnte man das nicht so umsetzen?


    flpout() geht nicht in GEOS , weil du auf dem Screen nicht einfach Printen kannst.


    Gruss




    <EDIT MOD>Bitte in Zukunft die Zitat Funktion nutzen, das macht das Lesen viel einfacher zum Nachvollzieher, wer was geschrieben hat. Einfach das " GänsefüsschenIcon in der Bearbeitungsleiste klicken im Text des benutzers, den man zitieren will. Danke.

    Edited once, last by syshack: Bitte in Zukunft die Zitat Funktion nutzen, das macht das Lesen viel einfacher zum Nachvollzieher, wer was geschrieben hat. Einfach das " GänsefüsschenIcon in der Bearbeitungsleiste klicken im Text des benutzers, den man zitieren will. Danke. ().

  • Na bitte, kaum macht man es richtig, schon funktionierts .

    Nur bedingt... ich hab jetzt mal "Just4Fun" das Programm in den MegaAss übersetzt, siehe unten.


    Kurzum: Ja es "geht"... :thumbup: *ABER* ist aus meiner Sicht doch noch sehr experimentell:


    Die obige Routine führt z.B. keine Berechnungen durch. Es wandelt nur die Konstante pi*2 in einen String ab $0100 um. Daher scheint es zu funktionieren.


    Aber schon die Routine MOVMF=$BBA2=ramfac=48034 zerstört gleich zu Beginn curPattern von GEOS. Kann man ja verschmerzen. SetPattern wieder aufrufen und gut ist.


    Dann hab ich wirklich mal etwas berechnet und SQR=$BF71 ergänzt. Auch das funktioniert, aber nur bis PutString. SQR ist eine Float-Routine und zerstört u.a. einige GEOS-Systemadressen mit Angaben zum aktuellen Zeichensatz. Lässt sich mit UseSystemFont wieder korrigieren.


    Ich hab jetzt nicht mehr weiter getestet. Prinzipiell funktioniert es (war ja klar, ROM-Routinen aufzurufen hat schon immer funktioniert) aber man müsste erstmal prüfen welche GEOS-Register die BASIC-Routinen zerstören und die hinterher wieder zurücksetzen. Entweder über eine generelle Schleife die einfach mal alle GEOS-Register innerhalb der ZeroPage sichert (Holzhammer-Methode) oder man erstellt eine Dokumentation in der zu jeder FLPT-Routine angegeben wird welche GEOS-Register zerstört werden. Z.B.


    ;----------------------------------------------------
    ; MOVMF = $BBA2
    ; Funktion: MFLPT-Konstante in FAC1 laden.
    ; Zerstört: AKKU, XREG, YREG, curPattern, a2L
    ;----------------------------------------------------


    Das MegaAss-Handbuch gibt einem ja die gleichen Informationen für die GEOS-Routinen. Ohne solche Informationen wird das programmieren zum Russischen Roulette.


    Abgesehen davon werden direkte Einsprungadressen im BASIC-ROM verwendet die nicht in einer Srungtabelle (wie bei den I/O-Routinen im Kernal) aufgeführt sind. Die Kernal-I/O-Routinen sind im "Commodore 64 Programmer's Reference Guide" als "User Callable KERNAL Routines" aufgeführt... für BASIC-Routinen gibt es so etwas nicht. Wenn es da angepasste ROMs gibt wird das schon schwierig.


    Für die BASIC-Funktionen gibt es aber immerhin die ROM-Tabelle mit den Adressen zu den BASIC-Kommandos. An Stelle von

    Code
    1. jsr SQR ;$BF71


    könnte man das hier verwenden:

    Code
    1. :vecSQR=$a05e
    2. lda vecSQR +0
    3. ldx vecSQR +1
    4. jsr CallRoutine


    Bei $A05E steht die Adresse für SQR=$BF71. Das wäre zumindest etwas sicherer für die Funktionen.


    Ich hab zum Spaß auch mal geoBasic ausprobiert. Damit lassen sich auch FLPT-Berechnungen durchführen. Ist zwar wohl nie wirklich fertig geworden und kommt wohl auch nicht mit GEOS-MP3 zurecht (fummelt auch wieder im GEOS-Kernal rum...) aber das geoBasic-Programm konnte ich dann auch als Anwendung abspeichern. Da reicht ein

    Code
    1. 10 print sin(1)


    um einen FLPT-Wert auszugeben. Danach kehrt die Anwendung wieder zum DeskTop zurück.



    Ich finde das zwar 'ne gute Idee, auch die Umsetzung für den cc65, aber das war bisher nur ein "Proof-of-concept". Damit man *ALLE* FLPT-Routinen nutzen kann fehlt eine ordentliche Doku, die Adressen der einzelnen Funktionen sollten auch alle mal aufgelistet und getestet werden. Zusätzliche Einsprünge direkt in die BASIC-ROM-Routinen sollten entsprechend deklariert werden, ggf. mit Testroutine ob dort auch die richtige Routine liegt.

  • Leider gibt es die float.h und die math.h nicht mehr für dieses Programm:
    Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung


    Ich habe auch die Daten gesichert und wieder zurückgeschrieben für GEOS bei den Berechungen.
    Ich habe auch geschaut wo GEOS was stehen hat und die Floatroutine dort etwas benutzt.
    Das sind viele...und ist mühselig.
    Für den seltenen Anwender ist die Spielerei nichts.
    Darum haben damals die GEOS-Erfinder die Finger davon gelassen.


    Gibt es für das geoBasic irgendwo den Sourcecode?
    Vielleicht waren die Float bei geoBasic selbst gestrickt ohne in das Basic zu gehen.


    Danke.
    Gruss

  • Gibt es für das geoBasic-Programm irgendwo den Sourcecode?

    Keine Ahnung, glaube es aber nicht. Aber ich hab das D64 von hier verwendet (etwas nach unten scrollen). Da gibts auch ein paar zusätzliche Infos.


    Darum haben damals die GEOS-Erfinder die Finger davon gelassen.

    Nein, für GEOS reicht doch in den meisten Fällen ganze Zahlen. geoCalc nutzt aber auch FLPT-Zahlen, es gibt da also Möglichkeiten. Evtl. haben die aber die Routinen auch nachgebildet.


    Ich habe auch geschaut wo GEOS was stehen hat und die Floatroutine dort etwas benutzt.
    Das sind viele...und ist mühselig.

    Das könnte man ja optimieren

    Code
    1. _ramfac:
    2. jsr 48034
    3. rts

    Z.B. so

    Code
    1. _ramfac:
    2. PushW curPattern
    3. jsr 48034
    4. PopW curPattern
    5. rts

    Also wenn man die Routinen schon per JSR aufruft gleich noch die GEOS-Register sichern. Wäre ein Weg... setzt aber voraus das man wirklich alle Register findet. Ansonsten:

    Code
    1. _ramfac:
    2. jsr SaveGeosData
    3. jsr 48034
    4. jsr LoadGeosData
    5. rts

    SaveGeosData sichert die gesamte zeroPage in einen internen Buffer. Aber auch das könnte man, bei Verwendung einer zentralen Sprungtabelle, noch optimieren.


    Die GEOS MemoryMap findet sich u.a. hier.

  • Wo hast du die denn ausgegraben : jsr SaveGeosData
    Die finde ich nicht.

    Das war nur ein Beispiel, die Routine musst Du schon selbst schreiben. Ist ja nun aber kein Hexenwerk.


    LoadGeosData darfst Du selbst schreiben ;)


    Je nach Routine die man hinterher aufruft muss man ggf. noch den AKKU/YREG vorher sichern (z.B. für MOVMF). Aber dazu bräuchte man erstmal eine Übersicht welche Routinen es gibt, welche Parameter die benötigen usw... Danach kann man entscheiden was die beste Lösung ist. Evtl. gibt es mehrere Varianten:


    Routinen die nur eine Adresse von GEOS ändern, da würde ein lda curPattern/pha reichen.
    Routinen die mehrere Adressen verändern würden dann SaveGeosData verwenden.


    Das erste ist schneller, aber nicht für alle Routinen. Variante#2 ist langsamer, aber für mehrere Routinen zu verwenden.


    Du siehst: Im voraus zu entscheiden was das beste ist geht nicht. Erst muss die Dokumentation der Routinen her damit man sieht welche Register verändert werden.

  • Blöder Link .


    Besser : zimmers.net/geos/geodev.html

    Da sucht man sich ja den Wolf bis man die Liste findet ;)
    MegaAss ist da klar besser, aber das hat in der Vergangenheit nicht viel geholfen. :whistling:


    Der Vorteil bei zimmers (wenn auch nicht immer korrekt, z.B. r15=unused, ok, vielleicht im Kernal) ist das bei einigen Registern, die beim MegaAss nicht aufgeführt sind, etwas dazu erklärt wird. z.B. $45-$6F. Im Teil B von MegaAss fehlt das komplett.


    Vielleicht sollte man die zimmers-Liste mal auf Deutsch übersetzen und aktualisieren... Mal sehen wie ich Lust dazu hab. :D