Koala-Format abbilden mit ACME und ca65

Es gibt 5 Antworten in diesem Thema, welches 1.736 mal aufgerufen wurde. Der letzte Beitrag (3. November 2016 um 15:21) ist von Bytebreaker.

  • Hallo,

    durch Herumprobieren fand ich heraus, dass nur mit dem Zusatz

    ,,2

    z.B. bei der Direktive

    *= $2000
    !bin "pic.kla",,2

    ich ein Koala-Bild ohne Farb-RAM-Schrott laden kann. Erst mit ,,2 steht nicht nur die Bitmap sauber ab $2000 drin, sondern auch der Rest. Was bedeutet ,,2 ?

    Wenn ich mit ca65/ld65 arbeite (ich versuche meine Projekte immer für beide Assembler auszurichten, falls ich irgendwann mal dauerhaft auf ca65/ld65 gehen sollte), muss ich von Hand die Koala-Grafik nach $2000 kopieren. Das mache ich mit derselben Kopierroutine, die wir hier schonmal gemeinsam für das Kopieren eines SID-Stückes perfektioniert haben.

    Auch hier kommt ähnlicher Grafik-Schrott heraus, wie wenn ich bei ACME das ,,2 weglasse. Was wäre das ,,2 Äquivalent bei ca65/ld65?

    Dann fällt mir außerdem noch auf, dass mein Koala-Abbildungscode Palettenänderungen nicht übernimmt. Die Darstellung von Bitmap, ScreenRAM und FarbRAM ist zwar korrekt, aber die Farben sind falsch im Vergleich zum Original. Wo im Koala-Format steht die Paletteninformation?

    Die Kopierroutine müsste eigentlich sauber sein, denn beim SID funktioniert sie ja auch.

    Wenn die Infos hier nicht reichen sollten, poste ich Sources.

  • Was bedeutet ,,2 ?


    Damit wird die Ladeadresse (2 Bytes am Anfang des Files) übersprungen, auch Offset genannnt.


    Was wäre das ,,2 Äquivalent bei ca65/ld65?


    Versuchmal mit Bitte melde dich an, um diesen Link zu sehen.. In diesem Fall:

    Code
    .incbin         "pic.kla", 2
  • Du kannst die Ladeadresse auch einfach mitladen.Kostet dich zwei Bytes, ist nicht schön, aber funktioniert. Include das Koalabild einfach statt bei $2000 bei $2000-2...

  • !bin "pic.kla",,2
    [...]
    Erst mit ,,2 steht nicht nur die Bitmap sauber ab $2000 drin, sondern auch der Rest. Was bedeutet ,,2 ?

    Das hat ogd ja schon beantwortet - ich nehme aber auch gerne Verbesserungsvorschläge für die Doku entgegen, in der das, meiner Meinung nach, doch eigentlich ziemlich eindeutig beschrieben ist. :P

    Dann fällt mir außerdem noch auf, dass mein Koala-Abbildungscode Palettenänderungen nicht übernimmt. Die Darstellung von Bitmap, ScreenRAM und FarbRAM ist zwar korrekt, aber die Farben sind falsch im Vergleich zum Original. Wo im Koala-Format steht die Paletteninformation?

    Palettenänderungen im eigentlichen Wortsinn sind beim C64 gar nicht möglich, bei dem Beispielbild wurde wohl nur die Hintergrundfarbe nicht gesetzt - meines Wissens liegt der Farbcode als einzelnes Byte ziemlich am Ende der Koala-Datei.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Es war tatsächlich die Hintergrundfarbe.
    Achtung:

    Es klappte in ACME erst, als ich die Hintergrundfarbe NACH dem Kopiervorgang in ScreenRAM und FarbRAM gemäß Koala-Offset setzte.

    lda $4710 ; set Koala screen background color
    sta $d021

    Das Offset ist $2710, die ersten 2 Bytes weggenommen.

    -------

    In ca65/ld65 haut es noch immer nicht hin das Bild überhaupt sauber abzubilden, ohne Berücksichtigung der Hintergrundfarbe.

    Die Syntax

    .incbin "file",2

    hatte keinen Effekt.

    Ich probiere gerade, die ersten beiden Bytes durch direkte Addressierung zu umgehen, also den Kopiervorgang erst ab $1ffe zu starten. Das tut aber auch noch nicht, evtl. weil ich schlampig bin und nochmal genau gucken muss.

    ACME tut perfekt jetzt.

    Edit:

    Schon blöd wenn Tutorial-Material verbuggt ist und man selber als Anfänger drauf kommen muss.
    Der Tutor hat die Hälfte vergessen (Bitte melde dich an, um diesen Link zu sehen.)