Neues OS für C64 (mit Zeichensatz-UI)

  • Ich habe mich in einer ähnlichen Situation endlich mal dazu aufgerafft, mir ein einfaches Unittest-Framework für den Cevi zusammenzustellen. Das war rückblickend glaube ich die beste Idee gleich nach dem Einführen eines Versionskontrollsystems ;) . Ist zwar natürlich auch erst mal Arbeit, aber seit dem ist mein Leben unglaublich viel entspannter geworden. Einfach ein paar fiese Cornercases ausdenken, dann hat man das Problem schon fast in der Tasche.
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • GoDot schrieb:

    Kann man eigentlich mit ACME aus einem Quell-File heraus mehrere Objekt-Files erzeugen?
    Nein, derzeit nicht.
    Sowas steht aber auf der Todo-Liste: Jemand (Claus?) hatte mal gefragt, ob man ein Hauptprogramm und mehrere Nachlade-Levels so assemblieren könnte, dass sie sich all ihre Symbole teilen. Wenn ich Dich richtig verstehe, würde das auch diesen Fall lösen.
    Yes, I'm the guy responsible for the ACME cross assembler
  • Selbstbewerb: C64 Studio kann das. Eine Dependency ausgewählt und ein Häkchen bei "Include Symbols" gesetzt. Mehrfach vorkommende Symbole werden dann natürlich angenörgelt.
    Das ist für genau so etwas gedacht, wenn man einen Basis-Code für Objekte o.Ä. in diversen nachgeladenen Code-Teilen verwenden will, ohne dass man da eine Liste der Adressen vorher festlegt.

    Wie man so etwas aber übersichtlich und vernünftig über den Code selbst regelt, habe ich selbst aber auch noch nicht herausgefunden :)
  • Mac Bacon schrieb:

    Jemand (Claus?) hatte mal gefragt, ob man ein Hauptprogramm und mehrere Nachlade-Levels so assemblieren könnte, dass sie sich all ihre Symbole teilen.
    Jo, das war ich :) ! Allerdings würde ich mir inzwischen vermutlich noch lieber Support für .o64 Objectfiles wünschen. Dann könnte man den ld65 als Linker verwenden und hätte gleich einen ganzen Haufen an zusätzlicher Funktionalität (einschließlich der geteilten Symbole) for free sozusagen. Der einzige Assembler, der das m.W. kann, ist der CA65. Mit dem lassen sich solche Probleme leicht lösen, weshalb ich mich auch dafür für Zeit der Stille entschieden habe. Das hilft Dir aber wahrscheinlich jetzt nichts mehr, @GoDot, außer Du willst all Deinen Sourcecode anpassen :/ .
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • Mac Bacon schrieb:

    Wenn ich Dich richtig verstehe, würde das auch diesen Fall lösen.
    Exakt. Der Explorer ist am Limit (4K) und ich hab angefangen, Routinen auszulagern (heißt dann "uni.xhelpers"). Da beide Files sich weiterhin aufeinander beziehen, aber an sehr unterschiedlichen Orten liegen, wäre eine Segmentierung äußerst hilfreich... ;)

    Arndt
    GoDot C64 Image Processing
    www.godot64.de
    GoDot on Github
  • Naja, schon wieder was dazwischengekommen!

    Also OT:
    Ich hab einen fast 15 Jahre alten Bug im Lader GeoPaint gefixt, der dazu führte, dass er hin und wieder eindeutige GeoPaint-Bilder mit "No GeoPaint image" abwies. Ich hatte das Verhalten zwar ab und zu mitbekommen, aber nicht ernst genommen, zumal es bei den Testbildern, die ich zur Verfügung hatte, nicht auftrat. Jetzt weiß ich, was da los war: GeoPaint speichert seine Bilder platzsparend ab, wenn lange Bereiche im Bild leer sind, werden sie erst gar nicht gespeichert. Es wird nur festgehalten, dass es diesen Bereich gibt. Tja, ich hatte nicht klar genug auf diesen Umstand getestet: Wenn es *am Anfang* eines Bildes pixelfreie Bereiche gab, hat der Lader fälschlich angenommen, dass das Bild *komplett* leer ist und womöglich deshalb gar kein GeoPaint-Bild ist. Daher die Meldung. Ist jetzt gefixt.

    Ein zweiter Fehler hat mit dem Ende eines Bildes zu tun: Manche Bilder belegen den *ganzen* Canvas, haben aber schon ab der Canvas-Mitte keinen Inhalt mehr. Das wird von Geos so ähnlich festgehalten wie oben beschrieben, ich hatte auch hier unklar abgefragt (die Höhe eines Bildes wurde dadurch zu Null). Ergebnis: das Bild wurde nicht eingelesen. Ist jetzt ebenfalls gefixt. :)

    Das also zwischendurch...

    Arndt
    GoDot C64 Image Processing
    www.godot64.de
    GoDot on Github
  • Benutzer online 1

    1 Besucher