Hallo Besucher, der Thread wurde 20k mal aufgerufen und enthält 86 Antworten

letzter Beitrag von DMHas am

Nufli File Specs?

    Ich beschäftige mich gerade mit NUFLI, Mufflon und so. Kann leider nirgends eine Spezifikation finden, wie ein NUFLI-File aufgebaut ist, was folgt wie aufeinander und muss dann wo hin? Wäre für einen Link dankbar. Mein Google reicht irgendwie nicht... ;-)


    Arndt

    schau mal af csdb , da gabs mal nen thread dazu. http://csdb.dk/forums/?roomid=…icid=68273&showallposts=1



    Orginalzitat von Roland :



    Folgende NUFLI Spec. habe ich in den Untiefen meiner Festplatten gefunden.
    Aber vorsicht! Nicht alles ist dann beim NUVIE genauso.
    Z.B. Abschnitt b gibt es im NUVIE nicht. Da ist der Speedcode aus
    Abschnitt d für die Farben + Umschaltungen schon fertig erzeugt.
    Das Speicherdesign war von Anfang an so ausgelegt, dass auch Interlace
    oder DoubleBuffer möglich wäre (für 2 NUFLI Bilder auf einmal im
    Speicher)



    a: Grafik+Sprite Daten und Farben



    2000-2100 sprite 7 flibug
    2100-2280 sprite 1-6 im bild (1)
    2280-23e8 fli screenram (1)
    2500-2680 sprite 1-6 im bild (2)
    2680-27e8 fli screenram (2)
    2900-2a80 sprite 1-6 im bild (3)
    2a80-2be8 fli screenram (3)
    2d00-2e80 sprite 1-6 im bild (4)
    2e80-2fe8 fli screenram (4)
    3200-3300 sprite 0 flibug
    3400-3f40 bitmap



    nun kommen 8 screenrams, wobei jeweils nur jede 2. bildschirmzeile verwendet wird.
    zunächste 4 mal die geraden zeilen und dann 4 mal die ungeraden.



    4028-4050 fli screenram (1)
    4078-40a0
    40c8-40f0
    4118-4140
    4168-4190
    41b8-41e0
    4208-4230
    4258-4280
    4280-43c0 sprite 1-5 (1)



    4428-4450 fli screenram (2)
    4478-44a0
    44c8-44f0
    4518-4540
    4568-4590
    45b8-45e0
    4608-4630
    4658-4680
    4680-47c0 sprite 1-5 (2)



    4828-4850 fli screenram (3)
    4878-48a0
    48c8-48f0
    4918-4940
    4968-4990
    49b8-49e0
    4a08-4a30
    4a58-4a80
    4a80-4bc0 sprite 1-5 (3)



    4c28-4c50 fli screenram (4)
    4c78-4ca0
    4cc8-4cf0
    4d18-4d40
    4d68-4d90
    4db8-4de0
    4e08-4e30
    4e58-4e80
    4e80-4fc0 sprite 1-5 (4)



    5000-5028 fli screenram (5)
    5050-5078
    50a0-50c8
    50f0-5118
    5140-5168
    5190-51b8
    51e0-5208
    5230-5258
    5280-53c0 sprite 1-5 (5)



    5400-5428 fli screenram (6)
    5450-5478
    54a0-54c8
    54f0-5518
    5540-5568
    5590-55b8
    55e0-5608
    5630-5658
    5680-57c0 sprite 1-5 (6)



    5800-5828 fli screenram (7)
    5850-5878
    58a0-58c8
    58f0-5918
    5940-5968
    5990-59b8
    59e0-5a08
    5a30-5a58
    5a80-5bc0 sprite 1-5 (7)



    5c00-5c28 fli screenram (8)
    5c50-5c78
    5ca0-5cc8
    5cf0-5d18
    5d40-5d68
    5d90-5db8
    5de0-5e08
    5e30-5e58
    5e80-5fc0 sprite 1-5 (8)



    6000-7400 bitmap



    7400-7600 sprite 6
    7600-7800 sprite 7
    7800-7a00 sprite 0



    b: Farben und Umschaltungen für Speedcodegenerierung



    2400-2465 farben sprite 1 + freie umschaltungen für flibug sprites+border
    2480-24e5 farben sprite 2 + freie umschaltungen für flibug sprites+border
    2800-2865 farben sprite 1 + freie umschaltungen für flibug sprites+border
    2880-28e5 farben sprite 2 + freie umschaltungen für flibug sprites+border
    2c00-2c65 farben sprite 1 + freie umschaltungen für flibug sprites+border
    2c80-2ce5 farben sprite 2 + freie umschaltungen für flibug sprites+border
    3ff0, 3ff1, 3ff6, 3ff7 : initalfarben für $d025,d026,d027 und d02e




    c: Spritepointer



    23f8-2400
    27f8-2800
    2bf8-2c00
    2ff8-3000
    3f80-3fc0 : #$00er für clearsprite unten (brauchst du evtl. nicht wenn du da dein scroller code hast)
    3fff : #$00
    4000-400c : #$00er für clearsprite oben
    43f8-4400
    47f8-4800
    4bf8-4c00
    4ff8-5000
    53f8-5400
    57f8-5800
    5bf8-5c00
    5ff8-6000



    und dann sind da noch spritepointer und graphic, die vom displayer umkopiert werden.



    #$fe -> 07f8-0800
    2280-22a8 -> 0280 (da die erste fliscreenram zeile nach dem $dd00 umschalten da liegt)
    23f8-2400 -> 03f8 (da die erste fliscreenram zeile nach dem $dd00 umschalten da liegt)
    73d8-7400 -> 33d8 (da die erste fliscreenram zeile nach dem $dd00 umschalten da liegt -
    bräuchte aber eigentlich nur: 73d8, 73e0, 73e8, 73f0 und 73f8 da es die Bitmapzeile ist)
    #$00 -> 7ff8-8000




    d: Speicher wo Speedcode erzeugt wird



    1000-1f42



    e+f: komplette displayerroutine
    3000-31f5
    3300-33d6
    3fc0-3ff0 (vic init daten)





    Orginalzitat von DeeKay :


    Okay, I'll sum this up as condensed as I can:



    NUFLI-Picture: 1 hires bitmap, FLI every second line (=all even lines)
    plus 1 spritelayer of 6 expanded hires-sprites over the first 39 chars
    (last one is plain AFLI) under the bitmap with possible colorchanges for
    the sprites every 2 lines (=every odd line)
    NUFLI-bug: 1 hires bitmap, 6 lines of grey alternating with 2 lines of
    normal AFLI, plus one Mcol-spritelayer as the bottom layer (well,
    technically the unset bitmap color is at the very bottom, but in those 6
    lines with grey that's grey, which you also have as set pixels in hires
    *over* the whole thing, so it doesn't make any sense!), one
    hires-spritelayer over it and set bitmap pixels (that's those 6 lines
    grey alternating with 2 lines AFLI again!) over that (that's 4 layers
    instead of 3 like inside the picture). colorchanges are possible for all
    four sprite colors (five possible switches in total every even line,
    one every odd line), depending on how many register switches are free
    (unused) inside the picture!



    Yes, nobody said it's simple - that's why we made the converter! ;-D




    Wenn du C verstehst könntest du aus dem source des mufflon converters vielleicht schlauer werden: https://svn.sngs.de/metalvotze/svn/repo/mufflon/



    Grüsse

    Hab am Wochenende endlich mit einem NuFLI-Lader angefangen und mir dazu die Specs, die buexe74 hier gepostet hat, näher angeschaut.


    Zwei Fragen sind offen: 1. Die acht Screenrams sind ja jeweils gesplittet in zwei Teile, einer ist 360 Bytes lang (z.B. der Teil von 2280 bis 23e7), der zweite hat 640 Bytes (z.B. der Teil von 4000 bis 427f). Wie man unten im Zitat sehen kann, fehlen mir da vier von den kürzeren Abschnitten, und zwar die von Screenram 5 bis 8. Wo liegen die?


    Und damit komme ich zur zweiten Frage: 2. Die Bereiche für Sprite 6, 7 und 0 sind ja nun etwas lang für so ein bisschen Sprites. Außerdem ist nur der Bereich von 7400 bis 75ff überhaupt gefüllt (in meinem Testbild), die beiden restlichen Bereiche sind mit $00 aufgepumpt. Kann es sein, dass hier etwas an der Beschreibung nicht stimmt?


    Ist vielleicht dieser Bereich ab 7400 der fehlende Screenram-Kram (oder zumindest einTeil davon)? Platz wär da ja.


    Wenn ich den Lader fertig kriege, dann kann ich mich an einen Saver machen (das ist überhaupt das eigentliche Ziel hierbei). GoDot-4Bit nach NuFLI gewandelt, das stell ich mir ganz geschmeidig vor... :-)


    Arndt

    Hallo Arndt,


    Toll , dass du dich an so eine Aufgabe traust.


    Ich hab mich selber noch nicht eingehend mit den Nufli Specs auseinandergesetzt, was mir allerdings aufgefallen ist, ist folgendes.
    Wenn man die Nufli View Routine startet mit sys 12288, dann ändert sich einiges im Speicher im vergleich zum "ungestarteten" ( nur in den Speicher geladenen Bild ) .


    Alles was ich darüber weiss, hab ich von Roland hier aus dem Forum aus diesem Thread :
    Tutorial zum Erstellen von REU Nuvies (16MB Kurzfilme) für die 1541 Ultimate Cartridges bzw. für den WinVice Emulator


    Er wäre der richtige Ansprechpartner für die Details ... falls er sie noch weiss und erzählen möchte.


    GoDot-4Bit nach NuFLI ist ne tolle Idee , doch könnte ich mir vorstellen, dass die Rechenpower am C64 etwas zu gering sein dürfte. Zumindest um die optimierten Sprite Color changes zu berechnen. Ist nur ne Vermutung - aber eine Aufgabe des Mufflon Konverters ist sicher, im vorraus auszuprobieren, wie die SpriteLayer so eingefärbt werden kann, dass möglichst wenig Farbfehler im Bild entstehen.


    Das scheint mir überhaupt das grösste Problem bei dem Nufli Format ( Was super ist !) zu sein. Die Umwandlung der "Farbtiefe" eines 4 Bit Bildes ist sicher nicht trivial.



    Die besten konvertierungen entstehen nämlich dann, wenn das Ausgangsbild viele "ruhige" Bereiche hat, in denen eben nicht viele unterschiedliche Farben auf engem Raum sich abwechseln. Dann bleiben viele cycles für die "wilden" ( abwchslungsreichen ) Bereiche übrig, um die Spritefarben zu wechseln ( wieder nur Vermutung )



    Weiterhin nehme ich an, dass bei der Konvertierung viele Farben durch andere Farben ähnlicher helligkeit intelligent "ersetzt" werden, falls sonst zu viele Farben auf einem Haufen wären.



    Aber ich will dich nicht entmutigen...



    Ach so mit den ScreenRAM´s . ich hab nur gehört, daß das Bild wohl auf mehrer Vic Bänke verteilt ist - mehr weiss ich leider auch nicht.


    Viel erfolg !

    Zitat von buexe74

    Toll , dass du dich an so eine Aufgabe traust.

    Ah, das ist nur eine schöne Herausforderung, ich hab mit GoDot ja schon so einige schwierige Hürden genommen, da passt das NuFLI-Format so richtig ins Bild! :)


    Zitat

    GoDot-4Bit nach NuFLI ist ne tolle Idee , doch könnte ich mir vorstellen, dass die Rechenpower am C64 etwas zu gering sein dürfte.

    Hm, das glaub ich nicht. Das würde zwar gemächlicher ablaufen, aber für unmöglich halte ich das per se schon mal nicht. Ich müsste mir noch Gedanken machen, velleicht einen separaten NuFLI-Optimizer oder so.


    Zitat

    Die Umwandlung der "Farbtiefe" eines 4 Bit Bildes ist sicher nicht trivial.

    Das ist ja für Bilder, die im Speicher sind, bereits geschehen, also Umwandlung ist nicht das Problem, nur die Optimierung.


    Zitat

    Aber ich will dich nicht entmutigen...

    Kannst du nicht! :-)


    Zitat

    Ach so mit den ScreenRAM´s . ich hab nur gehört, daß das Bild wohl auf mehrer Vic Bänke verteilt ist - mehr weiss ich leider auch nicht.

    Das ist ja klar, AFLI braucht acht Screen-Rams, das geht aber auch aus den Specs, die du beim letzten Mal gepostet hast, gut hervor. Beim genauen Nachschauen jetzt fiel mir nur eben ins Auge, dass die acht Rams nicht vollständig im NUF-File enthalten sind, jedenfalls fehlen mir 4x360 Bytes zum ganzen Glück... Ich befürchte, dass ich den Player durchanalysieren muss... :-(


    Zitat

    Viel erfolg !

    Wird schon!


    Arndt

    Zitat von buexe74

    Ich dachte every 2nd line FLI braucht nur 4 ScreenRams ??? oder bring ich da was durcheinander..

    Hehe, zu der Erkenntnis bin ich jetzt auch schon gelangt. Also, ich berichte mal, wie ich vorankomme, vielleicht liest ja mal Roland oder Deekay hier rein, dann kann er mir gleich auf die Finger klopfen. :-)


    Mein erstes Ziel beim Lader für NuFLI ist, dass ich den AFLI-Anteil zusammenbaue und rendere. Dann kann ich beurteilen, ob ich (noch) auf dem richtigen Weg bin. Dazu hab ich mir die Filespecs von dir zuerst in der richtigen Reihenfolge aufgelistet und im Speicher nachgeschaut, ob das auch so stimmt.


    Dabei habe ich festgestellt, dass die Bitmap in zwei Abteilungen gesplittet ist: Die ersten 128 Rasterzeilen liegen in VIC-Bank 1, die unteren 72 Rasterzeilen in VIC-Bank 0. Für die erste Abteilung sind alle acht Screenrams (die man normalerweise für AFLI braucht) auch vorhanden, je eine Rasterzeile leer, je eine mit Farbdaten. Das ist der Punkt, der mich irritiert hat, denn - du hast genau recht - es heißt ja in den Specs, dass FLI nur alle zwei Rasterzeilen umgeschaltet wird, da bräuchte man eben nur vier Screenrams. Bei den 72 unteren Rasterzeilen des Bildes ist das auch so, hier gibt es nur vier Speicherbereiche für Screenrams. Da ich ja anfangen will mit dem Rendern des AFLI-Anteils des Bildes, brauche ich diese Screenrams aber doppelt (meine AFLI-Render-Routine aus dem ldr.AFLI ist so angelegt).


    Das hab ich jetzt auch so gemacht: Je zwei Rasterzeilen des unteren Bildteils haben einen gemeinsamen (also verdoppelten) Screenram-Teil. Das funktioniert auch.


    Nächster Schritt: Rendern als AFLI. Da ich im C64 dafür keinen Platz mehr habe (GoDot ist ziemlich großflächig im Speicher verteilt), muss ich das Ganze erstmal in die REU transferieren (per programmiertem GoDot-Undo). Von da aus hole ich dann die AFLI-Daten ab und rendere sie nach GoDot-4Bit.


    Wenn ich soweit bin, melde ich mich wieder.


    Arndt

    Ja...ich lese... :) Ich denke, ich hab die Specs auch schon einige Male (auch hier im Forum) gepostet.
    Ansonsten schaue ich am Wochenende mal, was ich noch finde. Das Hirn springt zur Not nach einiger Zeit auch wieder an.


    FLI ist wie vermutet alle 2 Zeilen. Dennoch werden 8 Screenrams verwendet, da das für die Spriteumschaltung gebraucht wird.
    In den Screenrams sieht man dann auch, dass immer eine Zeile (40 Zeichen) für die Farben verwendet wird, dann eine Zeile leer ist, und dann wieder Farben...usw.
    Bin mir aber gerade nicht sicher, ob das in der zweiten VIC Bank (nach 128 Zeilen) auch noch so ist, oder ob da auf 4 Screenram umgestellt wird.

    Damit ihr seht, wie ich vorankomme: Hier eins meiner Testbilder (ein NuFLI von buexes Seite) und das jetzige Stadium. Das Ergebnis (abgespeichert als AFLI) ist noch weit entfernt von gut und richtig, aber der AFLI-Anteil des NuFLI-Bildes ist schon mal drin, die Farben ebenfalls. (Die schwarzen Querbereiche sind im NuFLI-Bild leer, da kommen die Sprites hin - wenn ich richtig liege - lieg ich richtig?) Die Anordnung stimmt halt noch nicht...



    Muss jetzt schauen, woher der Versatz im Bild kommt, und wo ich falsch umgeschichtet habe. Wenn dann alles stimmt, melde ich mich wieder. Dann kommt der Sprite-Anteil im NuFLI an die Reihe

    Hier steht was zu Sprite Layer :


    http://csdb.dk/forums/?roomid=…icid=83785&showallposts=1


    und


    http://csdb.dk/forums/?roomid=…icid=68273&showallposts=1


    Die sollte nach meinem Verständnis nahezu über das gesamte Bild verteilt sein ( in X Richtung gestretcht ) aber von der "Transparenz" her unter der Bitmap Layer. Die genaue Anordnung weiss ich leider nicht. Ich würd mir im Monitor von WinVice vielleicht mal nen Breakpoint in der View Routine setzen und dann Rasterzeile für Rasterzeile die Vic - Register für die Sprites anschauen, um zu sehen , wie die Sprites plaziert sind. Die Spritepointer werden sich ja wahrscheinlich alle 2 Rastezeilen zusammen mit den Screenrams verändern...

    Das mit den schwarzen Balken könnte wohl von einer falschen Farbinfo kommen...
    Wenn er 00 liest wäre das ja schwarz auf schwarz. Roland hat ja geschrieben, daß immer im Wechsel eine Zeile des ScreenRams leer ist. Vielleicht greifst du an den schwarzen Stellen auf das falsche Screenram zu ?


    Es tritt ja auch nur im oberen Teil des Bildes auf - also vielleicht die ersten 128 Rasterzeilen ?

    Zitat von buexe74

    Roland hat ja geschrieben, daß immer im Wechsel eine Zeile des ScreenRams leer ist. Vielleicht greifst du an den schwarzen Stellen auf das falsche Screenram zu ?
    Es tritt ja auch nur im oberen Teil des Bildes auf - also vielleicht die ersten 128 Rasterzeilen ?

    Ja, genauso ist es! Ich dachte fälschlich, dass an diesen Stellen noch etwas fehlt, aber es ist natürlich so, dass (wegen der FLI-Umschaltung alle zwei Rasterzeilen) hier überhaupt nichts nötig ist, es ist ja schon da! Nur nicht bei meinem Render-Algorithmus für AFLI, ich muss also nur diese Bereiche mit den bereits vorhandenen Farbdaten füllen. Das kommt als nächstes.


    Trotzdem ist da noch irgendwas falsch angeordnet. Mal sehen, wo ich da wieder falsch denke. Hehe, so kommt man weiter: Zuerst Mist machen und dann alles ausbügeln... :-) Und dann die Sprites. Eins nach dem anderen.


    Arndt

    Zwischenstand:
    Ich hab beim Coden festgestellt, dass ich meinen REU-Treiber damals nicht bis zum Ende durchdacht hatte, daher klappte das Zwischenspeichern der NuFLI-Daten zuerst nicht richtig (es kam doch tatsächlich zu Abstürzen...) ;-)
    Jetzt brüte ich über den Farbdaten. Ich krieg den AFLI-Anteil des Bildes einfach nicht sauber gerendert (sieht immer noch so aus wie auf dem Beispielbild, nur jetzt ohne schwarze Streifen). Aber ich hab ja Zeit, hehe... :alt::rasen:puhh:


    Arndt

    Machs dir einfacher !


    Auf dem Bild kann ich kaum was erkennen. ausser vielleicht, daß der Mund-bereich doppelt erscheint
    Ich würd mit dem Mufflon konverter mal selber ein Nufli Bild erstellen, was ohne viel Spritedaten auskommen könnte und an dem man aber später Fehler in der Anordnung erkennen kann. also z.B. nur 2 Farben und eine dicke Linie Diagonal übers Bild. Damit sollte man doch schonmal erkennen können, ob die Bilddaten Richtig angeordnet sind.


    Oder man zeichnet sich dünne ( 1 Pixel breite Ziffern für die Zeilen auf ein Bild - ( für die feinen Sachen werden ja wahrscheinlich keine Sprites verwendet, da die ja gestrecht sind ). ( Am besten nicht in die FLI Bug Area )


    Als nächstes für die Farben z.B. ein Bild verwenden, welches Char-zeilenweise immer eine neue Farbe hat. Also alle 8 Rasterzeilen einen Farbwechsel usw.. immer weiter rantasten .. kennst es ja :)


    Werden denn nun 4 oder 8 Screenrams für die Farben benutzt ?