farbinformationen besser speichern?

Es gibt 45 Antworten in diesem Thema, welches 6.765 mal aufgerufen wurde. Der letzte Beitrag (17. Dezember 2016 um 11:58) ist von Mike.

  • Mal ein ganz frischer Gedanke, der auch das Drumrum betrifft:

    Code
    ; Rechtecke ausgeben, Parameter X/Y/Weite/Höhe
    -Startadressen Bildschirm setzen
    -Startadresse(n) RAM setzen
    -Schleife über die Höhe
      -Schleife über die Breite
        -Einzelnes Zeichen kopieren
        -Bildschirmadressen+40?
        (-RAM-Adresse(n)+Weite)

    Ich denke, dieses grobe Schema dürfte generell ganz gut sein, egal, wie die Details von "Einzelnes Zeichen kopieren" sind.

    Wie wäre es hiermit:
    -Zeichen und Farben abwechselnd gemischt in einem Speicher ablegen.
    -Ein Unterprogramm, das 4 Bit holt und in den Akku ROLt und nur den Akku benutzt.
    -Für ein Zeichen ruft man das 2mal auf, für die Farbe dann 1mal.
    -X und Y-Register sind frei, die machen sich dann gut in den beiden Schleifen.

  • Was mal ein konkretes Beispiel angeht, so hab' ich das "Zusammenschieben" der zwei Farb-RAM-Nibbles in ein Byte mal für ein Grafik-Format auf dem VC-20 gemacht. Die Bilder sind mit RUN ausführbar (wenn man sie mit ",8" und mind. einer +8K RAM-Erweiterung lädt), dank einer integrierten Anzeige-Routine. Die Farb-RAM-Daten wurden von 240 Bytes auf 120 Bytes eingedampft, witzigerweise ist die Anzeige-Routine ebenfalls 120 Bytes groß. :)

    Der hier relevante Teil der Farb-RAM-Entpackschleife sieht dort so aus:

    Das untere Nibble wird also zuerst geschrieben, wobei das Farb-RAM das obere Nibble ignoriert, dann wird das Byte 4x nach rechts ("unten") geshiftet und dann in's nächste Farb-RAM-Byte geschrieben. Die Adressierung war hier relativ easy, da Ein- und Ausgangsdaten in eine Page passen. Wird aber auch nicht viel komplizierter, wenn man mehr Daten hat.

  • wow aufstehen und losk.. aeh loscoden und schon isses erledigt :)

    hab die tips von Hexworx mit umgesetzt, danke dafuer :)


    somit waere diese baustelle fuer mich erstmal erledigt.
    ich bedanke mich bei allen beteiligten.

    salute

  • hm irgenwie geht das nich ...

    naja ich hab das jetzt auf selfmod code umgestellt da ich ah in der ZP bin,
    und da ja (zp),y wrapt dachte ich mir das das besser waer.

    nun muss ich ja aber die zeiger immer updaten und da hab ich mal wider ein problem mit dem colorspeicher.

    wann muss ich den denn updaten, eigendlich aller 2 durchlaeufe aber das will irgenwie nich.

    koenntet ihr mir bitte nochmal auf die spruenge helfen.

    salute

  • Leider befürchte ich, daß es ein kleines Problem mit dem Code gibt. Der Befehl BIT testet das höchste Bit (7) ab und übertragt den Inhalt ins N-Flag sowie das zweithöchste Bit (6), dessen Inhalt ins V-Flag kopiert wird. Dadurch kann man mit

    Code
    BIT	variable
    	BPL	bit_7_nicht_gesetzt
    	BMI	bit_7_gesetzt
    	BVC	bit_6_nicht_gesetzt
    	BVS	bit_6_gesetzt

    direkt testen, ob diese beiden Bits gesetzt sind oder nicht. In Deinem Fall willst Du aber das unterste Bit (0) testen. Zum Tests anderer Bits muß zuerst eine Maske in den Akkumulator geladen werden, die angibt, welche Bits getestet werden sollen, z. B.

    Code
    LDA	#%00000001
    	BIT	variable

    Der Prozessor führt dann beim BIT-Befehl eine UND-Operation durch mit dem Operanden, dessen Ergebnis dann im Z-Flag landet.
    Siehe hierzu auch: Bitte melde dich an, um diesen Link zu sehen.
    In Deinem Fall läßt sich das vielleicht so regeln:

    Code
    ;	vorher
    	LDA	print_line_offs      ;laenge holen
    	LSR		;	ungerade?
    	ROR		;	rotiere Bit ins höchste Bit
    	STA	print_line_flag	;speichern
    ;	dann
    	BIT	print_line_flag
    	BMI	+


    EDIT: In Deinem konkreten Fall läßt sich das Programm aber auch viel kürzer gestalten:

    Code
    LDA	print_line_offs      ;laenge holen
    	LSR		;	schiebe Bit 0 (gerade/ungerade) ins Carry-Flag
    	LDY	print_line_coloroffs ;color offset holen
    	LDA	(zpfd),y	;	color holen
    	BCS	+	;	Im Carry-Flag ist noch das Ergebnis enthalten für gerade/ungerade. ja dann low nibble speichern

    Einmal editiert, zuletzt von M. J. (10. Dezember 2016 um 18:30)

  • Meine erste Überlegung war, das höhere Nibble für ein simple RLE Encoding zu nutzen. Also z.B.

    $a5 = 10 * Farbe 5 ausgeben.

    Aber dann kann man ja nicht mal eine Zeile in 2 Bytes packen. Meine jetziges Schema 1 Byte Zähler plus 1 Byte Farbe könnte das. Alternativ fiel mir dann ein, dass man die oberen 4 Bit der Farbe auch dem Zähler zuschlagen könnte. Also dann 12 Bit Zähler und 4 Bit Farbe. Aber derart viele Wiederholungen hab ich wohl nicht.

  • kommen denn alle Farben vor überhaupt?

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • es kommt ja auch auf den screen an, wenn im colorspeicher folgen wie
    $0f,0f,$0f,0f,$0f,0f,$0f,0f,$0f,0f,$0f,0f,... stehen
    dann cruncht man die zu $ff,ff,ff,ff,ff,ff,ff,...
    diese koennte man dann weiter crunchen mit bspw rle

    normal sollten da ja nich soviele moeglichkeiten zu stande kommen
    so das sich der rle nich aufblaeht.

  • RLE hat hier nen Testscreen von 1500 Byte (1000 Byte Text + 500 Byte Farbe) auf 670 Byte komprimiert. Bringt schon bisserl was.

  • ein kleiner pseudocode

    Okay...

    bei textlaenge 5

    a) für Textlänge 5 braucht der de-Cruncher mehr Speicher als man an Datenbytes einspart.
    b) definiere Dein Programm so, daß nur gerade Textlängen vorkommen und spare die Sonderbehandlung. Solche Tricks und Kniffe kommen öfter vor als man denkt!
    c) wenn es denn unbedingt sein muß:

    start: load a, (quelle)
    shift_right a, 4; viermal nach rechts schieben...
    and #§0F; ---denn wir brauchen erstmal das High-Nibble
    store (farbram)
    increment farbram
    decrement counter
    jump_zero fertig; wenn counter auf Null geht: raus hier!


    load a, (quelle); nochmal holen- push/pull geht auch, ist aber langsamer
    and #§0F; diesmal: low-Nibble isolieren
    store (farbram)
    increment quelle; beim nächsten Durchgang brauchen wir ein neues Byte!
    increment farbram
    decrement counter
    jump_not_zero start; wenn counter noch nicht auf Null: nächste Runde!
    fertig: jee-ha!

    Du wolltest Pseudo-Code, hier hast Du... was jee-ha! macht darfst Du selbst rausfinden.

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

    3 Mal editiert, zuletzt von mc71 (11. Dezember 2016 um 05:20)

  • hehe danke mc71, ja hab das schon mitbekomm das der auch etwas langsam ist, war aber auch mal ne nette uebung.

    werd deinen pseudocode mal umsetzen und schaun ob ich den verwenden kann ;)

    salute

  • Wenn Du den Text jetzt noch als 5 oder 6 bit abspeicherst und über RLE nachdenkst bist Du schon fast bei echten Kompressionsverfahren.

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Jetzt brauchen wir nur noch einen Prozessor, der den Speicher als kontinuierlichen Bit-Strom abbilden kann, und wir sind golden...

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • Wieso lese ich 30 Posts später immer noch was von AND #$0F beim FarbRAM..?
    ;)

    Ps: Abhängig von den dargestellten Screens und deren (fixer?) Reihenfolge könnte man auch Delta-Kompression nutzen. Oder gleich Exomizer, wenn es sich rechnet...

    "...please come again - when I´m not working!"

    Einmal editiert, zuletzt von Squidward (11. Dezember 2016 um 10:46)

  • Zitat von Squidward

    Wieso lese ich 30 Posts später immer noch was von AND #$0F beim FarbRAM..?
    Bitte melde dich an, um dieses Bild zu sehen.

    +1

    Und wenn man zuerst das Low-Nibble wegschreibt, steht der kombinierte Wert immer noch im Akku, man braucht ihn also kein zweites Mal laden und kann dann nach 4x LSR A das High-Nibble wegschreiben, s.o. :P

    Umgekehrt, beim Laden aus dem Farb-RAM, ist man natürlich gut beraten, das Low-Nibble mit AND #$0F herauszuholen, da das High-Nibble nur Busrauschen liefert. Das zeigt der Gegenpart zu meinem Post Bitte melde dich an, um diesen Link zu sehen.:

    Daß die komprimierten Farb-RAM-Daten jetzt bei $2000 und nicht bei $2110 landen, ist Absicht.

  • Farb-Pack-Compo!


    Nee, die iss nicht zu kurz, Woltlappenmüll!

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • oh hab ich ganz vergessen, mit mc71s pseudo code bin ich ans ziehl gekommen, laeuft einwand frei
    ind reicht meinen anspruechen. zZ verbraucht mein ganzez prg mir allen zusatz daten und routinen
    17kb da koennte man sicher noch mehr rausholen aber das waere dann doch zu viel des guten.

    ich denke die restlichen 43kb sollten fuer den rest dann auch noch reichen.

    also ich bedanke mich bei allen beteiligten, fuer mich is das thema damit erstmal erledigt.

    salute


  • zZ verbraucht mein ganzez prg mir allen zusatz daten und routinen 17kb da koennte man sicher noch mehr rausholen aber das waere dann doch zu viel des guten.

    Wenn etwas zu gross ist und es kleiner werden soll, gibt es Universallösungen: Bitte melde dich an, um diesen Link zu sehen.

  • ja ich weis Fröhn das kommt dann zum schluss das macht ja waerend der entwiklung noch keinen sinn ;)

    somal ich davon ausgehe das garnich mehr alzuviel dazukommt ich schaetze ich werd so bei 20kb+-2kb rauskomm.