Posts by Roland

    Ich hatte es schon in vorherigen Posts erwähnt (aber vielleicht hab ich es nicht deutlich genug erklärt).
    Z.B. in der Tabelle 2880:


    2880 08 02 09 0a 64 ee 79 69 0a 68 0a 70 56 72 0a 79



    Du darfst im AFLI Bereich nur die Bytes mit dem Highnibble 0 verwenden, und die anderen Bytes "überlesen", bzw. die vorherige Farbe beibehalten, da alle anderen Bytes für die FLIBUG Sprites sind (oder das neu setzen der Y Position im unteren Bereich)
    Das würde in deinem Beispiel folgendes bedeuten:


    2880 08 02 09 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a


    Technisch gesehen ist das ja auch leicht erklährt. Man muss die Spritefarbe ja nicht jede Zeile neu setzen, wenn sie sich nicht verändert.
    Der VIC behält die Spritefarbe ja einfach bei, wenn man nicht ins entsprechende Register schreibt.


    Die Bytes 64, ee, 79, 69, 70, 56, 72 und 79 werden für andere Sprites ($d026, $d02e, $d027 und $d025 verwendet)
    Also an der Zeile wo 64 steht, wird $04 in das Speite $d026 geschrieben (und eben nicht in das Sprite des Farbtabelle 2880)

    Zu den Sprites. Ja, die Farbe wird dort immer in den geraden Zeilen verändert. (2,4,6,....) wärend die FLI Farben in den ungeraden Zeilen veränderten werden (1,3,5,...)
    Bei dem blauen Blumenbild scheint im unteren dritten ein paar Zeilen falsch zu sein. Sieht man besonders in den blauen Kugeln auf der rechten Seite.


    und es scheint, als ob auf der rechten Seite Teile der Sprites fehlen. Denn da sind alle Kugeln "leer". Nur dunkelblauer Rand, und innen hohl/schwarz.
    D.h. der erste Char des ganz rechten Sprites ist noch da, aber Char 2 und 3 fehlen.

    Puh...alles hab ich jetzt nicht im Kopf.
    Aber ein paar Beispiele.
    Der Nufli-Displayer, der den Darstellungs-Speedcode aus den Sprite-Farbtabellen erzeugt, ist im Nuvie nicht mehr enthalten (wäre ja auch unnötig, den für jedes Bild mit in das Nuvie zu speichern).
    Dafür ist der fertige Speedcode im Nuvie. So ist es schneller, diesen aus der REU in den Speicher zu kopieren, als den Speedcode für jedes Bild wieder neu zu erzeugen. Und somit fallen dann auch wiederrum die Farbtabellen weg. Und so geht es weiter....alles, was irgendwie das Kopieren aus der REU schneller macht (wobei das Bild dann aber nicht mehr als ein drittel von 64k brauchen sollte)

    versteh die frage nicht ganz.
    Ja, im Interrupt werden jedes mal oben zu Beginn des Bild wieder die Farben aus $3FFx in die FLI Bug Spritefarben geschrieben.

    wäre gut, wenn du man dein Beispiel Bild hier irgendwo anhängen könntest.
    Das würde die Fehlersuche erleichtern.
    Hast du die zwei übereinander liegenden Sprites im FLI Bug in der richtigen Prioritätsreihenfolge?

    Es gibt nur diese 6 Tabellen. Es gibt ja auch im Code nur Zeit um 6 Speicherstellen pro 2 Rasterlines zu verändern.
    Und so sind diese 6 Tabellen alias Speicherstellen zunächst einmal für die Sprites 1-6 vorgesehen.


    Wenn sich nun aber die Spritefarbe in aufeinander folgenden 2er Lines sich nicht ändert, braucht man die Farbe ja auch nicht erneut setzten.
    Und genau dann kann man diese Zeit nutzen um eine andere Speicherstelle zu verändern. Eben genau eine Farbe der FLI-Bug Sprites.


    Genau das wird über das Highnibble in der 6 Farbtabellen definiert.
    Ist das Highnibble = 7 (also z.B: $71), wird die Spritefarbe weiß in das Sprite 0 ($D027) gesetzt. Egal in welcher der 6 Tabellen das steht.


    Beispiel:


    Tabelle $2800:


    01, 02, 03, 78, 04, 79, 53, 6a, 05


    Dann würden die Spritefarben folgendemaßen aussehen (immer doppelt, da ja 2er Zeilen)
    (?? bedeutet: unbekann, kommt darauf an, wie es zu beginn des screens definiert ist - steht wo anders :) muss ich nachschauen)


    Sprite 3: 01, 01, 02, 02, 03, 03, 03, 03, 04, 04, 04, 04, 04, 04, 04, 04, 05 05
    Sprite 0: ??, ??, ??, ??, ??, ??, 08, 08, 08, 08, 09, 09, 09 .....
    Multicolor 1 (D025): ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, 03, 03, 03, 03....
    Multicolor 2 (D026): ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, 0a, 0a....


    wobei ich nun davon ausgegangen bin, dass in den anderen Farbtabellen nur 0er Highnibbles verwendet wurden.
    Dort kann man natürlich auch die FLI Bug Spritefarben in der selben Art ändern.


    edit:
    Die Initialfarben vom Screenanfang für die FLI Bug Sprite kommen hier her:
    .C:31ba AD F0 3F LDA $3FF0
    .C:31bd 8D 26 D0 STA $D026
    .C:31c0 AD F1 3F LDA $3FF1
    .C:31c3 8D 25 D0 STA $D025
    .C:31c6 AD F7 3F LDA $3FF7
    .C:31c9 8D 27 D0 STA $D027
    .C:31cc AD F6 3F LDA $3FF6
    .C:31cf 8D 2E D0 STA $D02E

    Die FLI Sprites sind im Prinzip genauso verteilt, wie die anderen Sprites (zumind. was die Low-6-Bits betrifft).
    Was den Tabellen für den Speicherposition für die Highbytes + Low-oberersten-2-Bits betrifft müsste ich auch nochmal nachschauen :)


    Edit: Hier nun die Tabelle + Berechnungscode


    Spritedaten im fli bug:


    Ist ähnlich wie im afli screen.
    Positionsberechnung wieder mit X (00 bis 02) und Y (00 bis $c7)
    Initiale Lowbyte Offset wieder Tabelle $7f00.


    TXA
    CLC
    ADC $7F00,Y
    AND #$3F
    ORA $A800,Y
    STA $lowbyte sprite7
    STA $lowbyte sprite0
    LDA $A900,Y
    STA $highbyte sprite7
    CLC
    ADC #$02
    ORA #$10
    STA $highbyte sprite0



    >C:a800 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:a810 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:a820 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:a830 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:a840 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:a850 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:a860 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:a870 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:a880 00 00 40 40 80 80 c0 c0 00 00 40 40 80 80 c0 c0
    >C:a890 00 00 40 40 80 80 c0 c0 00 00 40 40 80 80 c0 c0
    >C:a8a0 00 00 40 40 80 80 c0 c0 40 40 80 80 c0 c0 00 00
    >C:a8b0 40 40 80 80 c0 c0 00 00 40 40 80 80 c0 c0 00 00
    >C:a8c0 40 40 80 80 c0 c0 00 00 00 00 00 00 00 00 00 00



    >C:a900 77 77 77 77 77 77 77 77 76 76 76 76 76 76 76 76
    >C:a910 77 77 77 77 77 77 77 77 76 76 76 76 76 76 76 76
    >C:a920 77 77 77 77 77 77 77 77 76 76 76 76 76 76 76 76
    >C:a930 77 77 77 77 77 77 77 77 76 76 76 76 76 76 76 76
    >C:a940 77 77 77 77 77 77 77 77 76 76 76 76 76 76 76 76
    >C:a950 77 77 77 77 77 77 77 77 76 76 76 76 76 76 76 76
    >C:a960 77 77 77 77 77 77 77 77 76 76 76 76 76 76 76 76
    >C:a970 77 77 77 77 77 77 77 77 76 76 76 76 76 76 76 76
    >C:a980 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
    >C:a990 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
    >C:a9a0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
    >C:a9b0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
    >C:a9c0 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00

    oops.
    schon wieder ein kleiner fehler/dreher.
    muss heißen:


    die farben aus der ersten farbtabelle ($2400) ändern die flibugspritefarben in zeilen 2, 4, 6, 8, ...usw. (und hier darf man im editor auch die borderfarbe $d020 nicht umsetzen)
    die farben aus den anderen farbtabellen ändern die flibugspritefaben in den zeilen 1, 3, 5, usw.

    ah, und noch eine gemeinheit im flibug bereich.


    die farben können ja auch dort nur alle 2 zeilen verändert werden.
    mit einer gemeinheit.
    die farben aus der ersten farbtabelle ($2400) ändern die flibugspritefarben in zeilen 1, 3, 5, 7, ...usw. (und hier darf man im editor auch die borderfarbe $d020 nicht umsetzen)
    die farben aus den anderen farbtabellen ändern die flibugspritefaben in den zeilen 2, 4, 6, usw.



    das gilt aber nur im flibug bereich.


    im aflibereich wenn die farben bei allen 6 sprites in den zeilen 2, 4, 6, 8... geändert (also assynchron zum afli-farbwechsel)

    2 Zeilen AFLI im NUFLI-Kontext bedeuten doch aber im Prinzip 2 Zeilen "reines" Hires oder? :) Man hat 2 Farben für 8x2 Pixel. Echt AFLI wäre ja 2 Farben für 8x1 Pixel und 2 andere Farben für die darunter liegenden 8x1 Pixel.


    Ja, da hab ich mich falsch ausgedrückt. sind 2 farben für 8x2 Pixel. Wollte nur rüber bringen, dass dort eben nicht alles grau ist wie sonst im flibug, sondern so wie auch in anderen 8x2 blöcken des 2-zeilen aflis..

    für die spriteeinfährbung im afli bereich sind nur die bytes mit 0 im highnibble. also nur werte von 00 - 0f.
    Wenn du die anderen bytes auch verwendest bekommst du im afli bereich falsche farben.



    die werte 40 - 4f sind für dich irrellevant. mit umgesetzt meinte ich, dass hier die y-position verändert, bzw. auf $d4 gesetzt wird.
    ich kann ja leider auch mit spritecrunching die sprites nicht über die gesamten 200 pixel ausdehnen.
    die sprites starten irgendwo vor der ersten afli bildzeile, und dort wird auch gleich die nächste position $aa gesetzt (bevor die erste afli zeile beginnt)
    nun muss ich halt noch einmal zwischen rasterzeile $aa und $d4 die 8 sprites auf die position $d4 setzen.
    und genau das wird mit den bytes 41 - 4f in den farbtabellen bestimmt. aber wie gesagt. für dich zunächst nicht wichtig.
    sollte godot allerdings auch bilder anderer formate IN nufli umwandeln können, dann muss das auch berücksichtigt werden.
    die werte 41, 43, 45, .... 4f müssen EINMAL in einer der farbtabellen zwischen den zeilen $xx55 und $xx6a auftauchen.


    und nun OOOOOooooooops!
    Nun stelle ich fest, dass der muflon nufli konverter wohl eine andere (ältere) darstellungsroutine verwendet, als der nufli editor.
    das fällt nicht auf, da die (ungepackten) bilder den displayer enthalten und so der unterschied nicht auffällt.


    der muflon konverter verwendet 40-4f für das setzen der sprite y-positionen.


    im nufli editor hab ich das aber anders. dort wird 10-1f dafür verwendet.
    (und auch noch highnibble 2 für das setzen von $d020)


    so finde ich in den mit muflon erstellten bildern, die anschließend mit dem editor bearbeitet wurden sowohl 11-1f, als auch 41-4f :(
    und da sind die 41-4f bytes völlig blödsinning, da dann im speedcode $d024 gesetzt wird (was allerdings nichts ausmacht)


    Die müssen dann noch zusammengebastelt werden, wobei der Sprite-Layer unter dem AFLI-Layer liegt, stimmt das, Roland?


    Jetzt fehlen noch die Sprites für den FLI-Bug. Roland, gibt's da was Besonderes zu beachten? Liegen da nicht zwei Sprite-Layer übereinander? Einer in Hires und einer in Multi? Sprite 0 = Hires, Sprite 7 = Multi? Ist das so?


    Ja. Sprites unter dem AFLI (zumind. den gesetzten AFLI Pixeln)


    FLI Bug: Ja. Genau so wie du es geschrieben hast.
    Nun aber zu den Spritefarben.
    Während der Darstellung von 2 Zeilen ist nur Zeit für das setzen von 6 Farben. Das war zunächst auch OK, da auf dem AFLI Screen nur 6 Sprites sind.
    Der FLI Bug Bereich war ursprünglich ungenutzt.
    Wenn nun aber im AFLI Bereich keine neue Spritefarbe für die nächste Zeile gesetzt werden muss, kann diese Zeit für das verändern der Sprites im FLI Bug Bereich verwendet werden.
    Dies wird in den Farbtabellen mit bestimmten High-Nibbles festgelegt. Die 6 Tabellen für die Spritefarben der 6 Sprites im AFLI Bereich sind ja:
    $2400 (Sprite 1)
    $2480 (Sprite 2)
    $2800 (Sprite 3)
    $2880 (Sprite 4)
    $2c00 (Sprite 5)
    $2c80 (Sprite 6)


    Die Werte darin bedeuten folgendes.
    $00-$0f Farbe für das jeweilige Sprite (abhängig von der Tabelle)
    $40-$4f Position, an der der Y-Wert der Sprites umgesetzt wird. (sind also über die Tabellen die Werte 41, 43, 45, 47, 49, 4b, 4d und 4f verteilt)
    $50-$5f Farbe für $d025 (für das Multicolor Sprite 7 im FLI Bug)
    $60-$6f Farbe für $d026 (für das Mutlicolor Sprite 7 im FLI Bug)
    $70-$7f Farbe für $d027 (für das Hiressprite 0 im FLI Bug)
    $e0-$ef Farbe für $d02e (für das Mutlicolor Sprite 7 im FLI Bug)


    Und weiterhin im FLI Bug Bereich zu beachten:
    Der ersten 2 Zeilen jedes 8 Zeilen Block ist auch 100% AFLI.
    Die Zeilen 3-8 jedes 8 Zeilen Block haben dann nur noch Hellgrau als Farben der Pixel. Damit kann man aber eben auch mit Hellgrau Bereiche der Sprite (wie im AFLI) überdecken.

    zum Thema Tabellen verwenden. Überhaupt kein Problem. Nimm was immer du willst :)


    zu den Sprites.
    Verabschiede dich von der Vorstellung eines normalen Sprites, bei dem die Daten in der Form:
    1. Zeile 00, 01, 02
    2. Zeile 03, 04, 05
    usw.
    gespeichert sind.


    Durch das "Spritecrunching" wird die Spritedarstellung zu Beginn für den VIC völlig durcheinandergebracht.
    So beginnt eine Spritezeile plötzlich mit:


    05, 06, 07,
    und geht dann weiter...
    08, 09, 0a,
    0b, 0c, 0d,
    usw...


    Und normalerweise hört dann der VIC mit der Spritedarstellung auf, wenn die Zeile mit der Datenposition $3f beginnen würde (was ja normalerweise nach $3c, $3d, $3e) der Fall wären.
    Durch das anfängliche "Spritecrunching" passiert aber folgendes.


    die Zeilen sind:
    ...
    38, 39, 3a,
    3b, 3c, 3d,
    3e, 3f, ...oops? wo soll ich weitermachen? (Fragt sich der VIC)...ach, einfach am Anfang...also 00,
    01, 02, 03,
    04, 05, 06
    usw...


    ...und so hört das Sprite eben nicht wie normal nach 21 auf, sondern wird einfach weiter dargstellt.
    Daher muss ich im Code auch nicht so oft die Y-Spriteposition neu nach unten setzen.


    Und durch die y-Expandierung sind die Sprites:


    05, 06, 07,
    05, 06, 07,
    08, 09, 0a,
    08, 09, 0a,
    0b, 0c, 0d,
    0b, 0c, 0d,


    ....aber da eben immer zwischen den doppelten Zeilen $D018 (mit den Spritepointern) verändert wird,
    sind die Pixel auf dem Bildschirm eben nicht doppelt, sondern die Daten kommen immer wieder aus anderen Bereichen.


    ACHTUNG:
    Die erste Zeile (05,06,07) ist quasi nur einmal im sichtbaren Bereich, damit die Y-expandierten Spritepixel abwechselnd mit dem 2-Zeilen FLI (mit $D018) auftritt.


    Also:
    1. Zeile: $d018 = $78. Spritedaten: 05, 06, 07,
    2. Zeile: $d018 = $78. Spritedaten: 08, 09, 0a,
    3. Zeile: $d018 = $68. Spritedaten: 08, 09, 0a,
    4. Zeile: $d018 = $68. Spritedaten: 0b, 0c, 0d,
    5. Zeile: $d018 = $58. Spritedaten: 0b, 0c, 0d,
    ....

    und dann nicht die Farbumschaltungen für die Sprites vergessen :)
    Die kann man ja auch jede 2. Zeile für jedes* Sprite umschalten.


    * abgesehen von den 8 benötigten Sprite Y-Umschaltungen in 20 Zeilen im unteren Bereich.


    und wenn du das alles hast kommt noch der FLI Bug :D

    Also...
    zunächst abhängig von der Y Position das initiale Lowbyte Offset für die Spriteposition
    Y ist Zeilenbasiert. Also von 0-c7


    >C:7f00 05 08 08 0b 0b 0e 0e 11 11 14 14 17 17 1a 1a 1d
    >C:7f10 1d 20 20 23 23 26 26 29 29 2c 2c 2f 2f 32 32 35
    >C:7f20 35 38 38 3b 3b 3e 3e 01 01 04 04 07 07 0a 0a 0d
    >C:7f30 0d 10 10 13 13 16 16 19 19 1c 1c 1f 1f 22 22 25
    >C:7f40 25 28 28 2b 2b 2e 2e 31 31 34 34 37 37 3a 3a 3d
    >C:7f50 3d 00 00 03 03 06 06 09 09 0c 0c 0f 0f 12 12 15
    >C:7f60 15 18 18 1b 1b 1e 1e 21 21 24 24 27 27 2a 2a 2d
    >C:7f70 2d 30 30 33 33 36 36 39 39 3c 3c 00 00 03 03 06
    >C:7f80 06 09 09 0c 0c 0f 0f 12 12 15 15 18 18 1b 1b 1e
    >C:7f90 1e 21 21 24 24 27 27 2a 2a 2d 2d 30 30 33 33 36
    >C:7fa0 36 39 39 3c 3c 00 00 03 03 06 06 09 09 0c 0c 0f
    >C:7fb0 0f 12 12 15 15 18 18 1b 1b 1e 1e 21 21 24 24 27
    >C:7fc0 27 2a 2a 2d 2d 30 30 33 00 00 00 00 00 00 00 00


    Nun die Logik für Sprites 1-5 (Also Cursor-Screenposition 4-33 bzw. X Position 0-1d)
    Achtung, folgende X Position startet bei Nummer 0, obwohl es auf dem Screen der 4. Char ist.
    Das liegt daran, dass die ersten 3 Chars für den FLI Bug separat editiert werden.
    Außerdem wird die X Position nur in Chars verwaltet (nicht in Pixeln).
    D.h. X=0 ist die 4. Charposition. X=1 die 5. Charposition...usw.


    Also, abhängig vom X Wert wird folgendes zum lowbyte hinzugefügt und mit AND #$3F ausmaskiert (damit keine Werte über #$40 entstehen)


    >C:8ed0 00 00 01 01 02 02 00 00 01 01 02 02 00 00 01 01
    >C:8ee0 02 02 00 00 01 01 02 02 00 00 01 01 02 02 00 00
    >C:8ef0 01 01 02 02 00 00 00 00 00 00 00 00 00 00 00 00


    nun noch folgenden Wert abhängig von Y hinzu-ORA-en


    >C:8c00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c10 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c20 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c30 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c40 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c50 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c60 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c70 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >C:8c90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >C:8ca0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >C:8cb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >C:8cc0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


    und dann nochmal abhängig von X folgendes hinzuaddieren


    >C:8cd0 00 00 00 00 00 00 40 40 40 40 40 40 80 80 80 80
    >C:8ce0 80 80 c0 c0 c0 c0 c0 c0 00 00 00 00 00 00 40 40
    >C:8cf0 40 40 40 40 00 00 00 00 00 00 00 00 00 00 00 00


    Also für das Lowbyte:
    Lda 7f00,y
    clc
    adc 8ed0,x
    and #3f
    ora 8c00,y
    clc
    adc 8cd0,x
    sta $lowbyte


    und für das Highbyte (Achtung....Carry-Flag vom letzter Addition für das lowbyte wird beachtet)


    lda 8d00,y
    adc 8dd0,x
    sta $highbyte


    >C:8d00 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d10 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d20 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d30 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d40 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d50 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d60 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d70 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d80 21 21 25 25 29 29 2d 2d 21 21 25 25 29 29 2d 2d
    >C:8d90 21 21 25 25 29 29 2d 2d 21 21 25 25 29 29 2d 2d
    >C:8da0 21 21 25 25 29 29 2d 2d 25 25 29 29 2d 2d 21 21
    >C:8db0 25 25 29 29 2d 2d 21 21 25 25 29 29 2d 2d 21 21
    >C:8dc0 25 25 29 29 2d 2d 21 21 00 00 00 00 00 00 00 00


    >C:8dd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    >C:8de0 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 ................
    >C:8df0 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00


    Da das 6. Sprite (Cursor-Screenposition 34-39, bzw X: 1e-23) etwas anders abgelegt ist,
    ist die Berechnung ein klein bisschen anders:


    Lowbyte:
    Lda 7f00,y
    clc
    adc 8ed0,x
    and #3f
    ora 8e00,y
    sta $lowbyte


    und das Highbyte
    lda 8f00,y
    sta $highbyte


    >C:8e00 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e10 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e20 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e30 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e40 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e50 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e60 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e70 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e80 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
    >C:8e90 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
    >C:8ea0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
    >C:8eb0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
    >C:8ec0 40 40 40 40 40 40 40 40 00 00 00 00 00 00 00 00



    >C:8f00 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f10 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f20 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f30 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f40 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f50 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f60 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f70 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f80 22 22 26 26 2a 2a 2e 2e 22 22 26 26 2a 2a 2e 2e
    >C:8f90 22 22 26 26 2a 2a 2e 2e 22 22 26 26 2a 2a 2e 2e
    >C:8fa0 22 22 26 26 2a 2a 2e 2e 26 26 2a 2a 2e 2e 22 22
    >C:8fb0 26 26 2a 2a 2e 2e 22 22 26 26 2a 2a 2e 2e 22 22
    >C:8fc0 26 26 2a 2a 2e 2e 22 22 00 00 00 00 00 00 00 00


    Ps: Wo ich mir die Tabellen gerade ansehe. Da fällt mir auf, dass im unteren Teil des Screens (nach dem Umschalten der VIC Bank) die Screen-RAMs bis zum Ende nicht in der selben Reihenfolge ablaufen.
    Also nicht immer Screen: 2000, 2400, 2800, 2c00, 2000, 2400, 2800, 2c00, 2000 .... sondern ab Zeile 168 gehts dann mit: 2400 (anstelle von 2000) weiter.
    Sieht man auch in der letzten Tabelle der Spritedaten. Da gehts ab 8fa8 nicht wie zuvor mit 22 22 26 26 ... weiter, sondern mit 26 26 2a 2a .... weiter.

    wenn mir jetzt nochmal jemand sagen kann, wie ich aus dem Vice Monitor heraus Text kopieren kann?
    STRG-C ist es nicht. Und irgendwie ging das auch...weiß bloss nicht mehr wie?


    edit: OK, mit Vice2.4 scheint es zu funktionieren. Mit Vice2.0 nicht...

    mal kurz ein blick in den NUFLI Editor geschaut.
    Denke im Code ab $8000 ist die entsprechende Routine...
    Da wird sowohl die Bitmap, Colorram und Spritedaten Position berechnet.
    ...werde heute Nachmittag da nochmal genau reinschauen (muss jetzt weg)
    Aber das wird schon... :)

    Nicht zu vergessen.
    In den ersten 3 Chars gilt eine etwas andere Logik als in den Chars 4-39.
    In den ersten 3 Chars gibt es FLI ja nur in den ersten 2 Zeilen pro Cursorzeile. Zeile 3-8 hat keine FLI-Farben, sondern nur Hellgrau.
    Dafür gibt es 2 Sprite-Layer. Einen in Hires, uun den anderen in Multicolor.


    In Char 40 gibt es dagegen überhaupt keinen Sprite Layer. Dort ist nur das reine 2-Zeilen HiresFLI.


    Insgesamt ist der Screen 320x200 Pixel



    Die FLI Daten sind noch recht "einfach".
    Schlimm wird es bei den Spritedaten :)
    ABER...ich hab ja auch einen Editor gemacht.
    Und dort habe ich auch ein paar Tabellen abgelegt, die aus einer X und Y Position des Zeichencursors die entsprechende Stelle im Speicher erzeugen.
    DA müsste man (also wohl ich :) ) nochmal nachschauen.