GoDot Programierkurs / Handbuch / Quellcode-PDFs

  • GoDot schrieb:

    Na ja, ["080" anstelle von "80"] hat mir allerhand Gerödel erspart
    Bei nur drei verschiedenen Headern kann man diese als feste Zeichenkette ablegen. So hast Du es im Prinzip ja auch gemacht. Mit einer Ausgaberoutine, die mit 3 verschiedenen Pointern aufgerufen wird, oder einer PRIMM Routine *) wäre der Teil auch gut einzukürzen.

    Sobald natürlich beliebige Dezimalzahlen nach links ausgerichtet ausgegeben werden sollen, hat man besser eine allgemeine Routine mit im Boot: in MINIPAINT werden die aktuellen Cursor-Koordinaten mit einer 8-Bit-Ausgabe erstellt, und für das Directory brauchte ich eine vergleichbare Routine für 16-Bit-Zahlen. Insofern kann ich gut abschätzen, welcher Programmieraufwand dahinter steckt. Vor allem, wenn es im Fall von MP nicht halbe Ewigkeiten bis zum Output brauchen soll (da hab' ich dann mit Tabellen gearbeitet).

    ...

    Noch eine Anmerkung zu deiner Anmerkung in der Beschreibung des MP-Loaders auf der Webseite:

    GoDot schrieb:

    Bilder, die von anderen Rechnern zum VC20 nach MiniPaint portiert wurden, gewinnen jedoch durch die GoDot-Konvertierung, da die Pixel dann oft wieder im richtigen Aspekt angezeigt werden (die Fotografie-Bilder hier sind Beispiele dafür).
    Die meisten Bilder *werden* auf einem PAL-VC-20 bereits im richtigen Pixel-Aspekt angezeigt. Es ist nicht besonders schwierig, das bei der Auswahl eines geeigneten Bildausschnitts gleich mit zu berücksichtigen, sofern man das Bild auf dem PC vorbereitet: Mit dem Pixel-Aspekt-Verhältnis von 5:3 und der Auflösung von 160x192 ergibt sich ein Breite-zu-Höhe-Verhältnis des Gesamtbildes von 1,389:1 - was z.B. in IrfanView bei der Auswahl des Bildausschnitts in der Titelleiste mit angezeigt wird. Diesen Ausschnitt bringt man nun durch Rescale (unter absichtlicher Deaktivierung der Beibehaltung des Pixelaspekts) auf 160x192 (oder 80x192) und speichert ihn als *.pgm für die Import-Tools ab.

    Einen Tod stirbt man hier trotzdem: der NTSC-VIC-20 hat ein anderes Pixel-Aspekt-Verhältnis - 1,5:1 (oder 3:2 in kleinen ganzen Zahlen) - damit sehen Bilder beim V(I)C-20 auf der jeweils anderen TV-Norm immer verzerrt aus.

    Die Abweichung bei Konvertierung in GoDot von PAL VC zu PAL C64 relativiert sich aber dann doch noch aus einem anderen Grund: der PAL C64 hat nämlich auch keine quadratischen Pixel, sondern hier liegen wir bei 0,9365:1 - mit verdoppelten Pixeln sind das dann 1,873:1

    Und zu 1,667:1 ist das eine Verbreiterung um lediglich 12%. :)

    Gruß,

    Michael


    *) so wie die hier mit vorigem CHKOUT auf die Ausgabedatei. Hinter JSR steht direkt die 0-terminierte Zeichenkette, wonach dann die Ausführung des aufrufenden Programms direkt hinter der 0 fortgesetzt wird:

    Quellcode

    1. .Primm
    2. PLA
    3. STA zp
    4. PLA
    5. STA zp+1
    6. .Primm_00
    7. INC zp
    8. BNE Primm_01
    9. INC zp+1
    10. .Primm_01
    11. LDY #0
    12. LDA (zp),Y
    13. BEQ Primm_02
    14. JSR $FFD2
    15. BCC Primm_00
    16. .Primm_02
    17. LDA zp+1
    18. PHA
    19. LDA zp
    20. PHA
    21. RTS
    Alles anzeigen

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Mike ()

  • GoDot schrieb:

    sd2iec: Kann mal einer ausprobieren, ob GoDot schon ganz ohne irgendwelche Klimmzüge darauf läuft? CMD-Geräte werden ja auch klaglos akzeptiert. Wahrscheinlich gibt's da gar keinen Handlungsbedarf!
    Woran macht GoDot denn fest, bei welchem Laufwerk ein ChangeDir zur Verfügung steht? Und hatten CMD-Geräte auch unterstützung für "mountbare" D64 Disk-Images so wie das SD2IEC? Ich würde gerne im "nativen" Modus arbeiten können.
    Was gehen könnte (bei Nachladern weiß man ja nie, was da getrieben wird) ist mit gemounteten Images wie mit einer 1541 zu arbeiten. Schön wäre aber, wenn ein SD2IEC erkannt würde und man unter GoDot z.B. Verzeichnisse wechseln und Disk-Image auswählen könnte.
  • Cyberdyne schrieb:

    Verzeichnisse wechseln und Disk-Image auswählen
    Mit diesen beiden Modulen ausprobieren: ChangeParts und ChangeDir.

    Ich hab mir die Easyflash-Texte angeschaut: Das EasyFS hat verdammte Ähnlichkeit mit meinem dev.REU! (Hier der Source-Code.) Ich könnte mir vorstellen, dass für GoDot ein dev.EasyFlash machbar wäre (um also Module und vor allem Bilddaten zwischenspeichern zu können). Aber GoDot als Easyflash-Cartridge: muss ich noch drüber nachdenken, ob das Sinn macht.

    Arndt
    GoDot C64 Image Processing
    www.godot64.de
    GoDot on Github
  • GoDot schrieb:

    Mit diesen beiden Modulen ausprobieren: ChangeParts und ChangeDir.
    Ich dachte, die stehen nur zur Verfügung, wenn ein entsprechendes LW erkannt wurde?!
    Wenn mein Arbeitszimmer wieder begehbar ist, werde ich es testen. ;)

    GoDot schrieb:

    muss ich noch drüber nachdenken, ob das Sinn macht.
    Sinn? GoDot und alle seine Module pfeilschnell "geladen", kein Diskettenwechsel mehr und 1MB Platz. Das nenne ich mal Sinnvoll! ;)
    Die eigentliche Frage ist, wie aufwendig die nötigen Anpassungen sind (Kosten/Nutzen halt) und ob du Bock drauf hast.
  • Cyberdyne schrieb:

    Die eigentliche Frage ist, wie aufwendig die nötigen Anpassungen sind (Kosten/Nutzen halt) und ob du Bock drauf hast.
    Müsste man sehen. Ich tendiere dazu, dass der Aufwand eher gering ist. Man müsste die Hardware nur zur Verfügung haben. Das wird bei mir ein Problem, denn ich hab nur noch einen C64 (meinen allerersten!) und der hängt an der Wand, Ehrenplatz. Kein Monitor, kein Laufwerk, Netzteil... müsste ich suchen. Ich arbeite ausschließlich auf VICE, reicht für GoDot völlig.

    Arndt
    GoDot C64 Image Processing
    www.godot64.de
    GoDot on Github