Hallo Besucher, der Thread wurde 54k mal aufgerufen und enthält 172 Antworten

letzter Beitrag von war64burnout am

Tutorial zum Erstellen von REU Nuvies (16MB Kurzfilme) für die 1541 Ultimate Cartridges bzw. für den WinVice Emulator

    Abspielroutine ändern geht generell schon (macht Wired ja). Egal ob Tastatur oder auch eine Joystick Steuerung.
    Nur leider ist das eben in dem Nuvie-Maker nicht mit drin. Das müsste man per Hand in das Reu File reinmachen.
    Der Player selber bietet die Möglichkeit, Code vor dem Start auszuführen und alles entsprechend anzupassen.

    So Fertig !


    Ich freue mich euch das Ergebnis der Bemühungen ( in Sachen Nuvie Slideshow ) presentieren zu dürfen..


    Wem es beim Nufli schauen nicht schwindlig wird, kann sich das mal reinziehen. ( Oh - Dateianhang zu gross )


    Oder hier laden: https://sites.google.com/site/nuflibase64/home/nuvies


    So wie es jetzt ist bleibts . Das Timing mit der Musik gerät beim loopen des Sids leider aus dem Takt.


    Es wäre noch massenhaft Platz für mehrere Sids auf der Reu, aber ich weiss leider "noch ?" nicht, wie ich mehrere hintereinander einbinden kann. ( irgendwann langweilt es immer den gleichen Tune zu hören... )


    500 Bilder war ca. die Obergrenze, da die Playlist zu kurz ist, um noch mehr Einträge aufzunehmen, sonst überschreibt man den code des Nuviemakers. Jedes Bild benötigt 4 bytes mit der 90 token Methode ( hold Image for a number of nuvie frames - hier mal wieder in hexadizimal ), dafür kann man relativ leicht die "Verweildauer" jedes Bildes bestimmen...


    Ich hoffe euch gefällts - dauert ca. 15 min :)


    Greez

    Und damit man sich die Ohren nicht wundscheuert an dem einen Sid hier noch mal die SlideShow mit mehreren Sids hintereinander...


    mehrere .rar dateien unter 500 kb hochladen geht scheints auch nicht ( Der Parameter „files“ fehlt oder ist ungültig. "


    oder hier zum runterladen https://sites.google.com/site/nuflibase64/home/nuvies




    Gibt es eigentlich ausserhalb des Nuviemakers noch einen anderen Player, der mit dem von der Reu gestreamten Sid format umgehen kann ?

    Das ist ja mal genial mit mehreren SIDs in einem Nuvie. Wie hast du das gemacht ? Der Nuviemaker kann das ja eigentlich nicht.


    Was mich auch mal interessieren würde: wo liegt in der REU der Intro-Bildschirm und die Playlist ? (wo der Introbildschirm liegt wäre interessant, um nachträglich Tippfehler o.Ä. korrigieren zu können, ohne das ganze Nuvie nochmal neu machen zu müssen, die Speicherstelle der Playlist wäre interessant, um ein Basic-Programm zu schreiben, das vor dem Abspielen die Playlist manipuliert, um z.B. die Bildanzeigedauer bei der Slideshow zu ändern oder z.B. die Bilder zu mischen, also in einer zufälligen Reihenfolge anzeigen zu lassen)

    Hi daddlertl,


    bin ich froh, daß jemand fragt. - Leider war das nicht so einfach.


    Ich hab mir dabei schon gedacht, ich sollte unbedingt eine Nuvie Cutter programmieren, damit das einfacher wird - aber es macht Spass.


    1. hab ich mir die Sids einzeln mit dem Nuviemaker in die REU eingelesen. Ich nenne das neue Format jetzt einfach mal REU-Sids.


    2. Die Reus mit den eingelesenen Sids gespeichert. Sie befinden sich im oberen Bereich der REU. Also REU in den Hexeditor geladen und den unteren Bereich der Reu, der mit Nullern gefüllt ist gelöscht. Und auch die allerletzten 11 Bytes gelöscht, da diese irgendwie nichts mit dem REU-Sid zu tun haben. zu beachten wäre hierbei noch, dass pro C64 Frame jeweils 25 bytes für die Sid Register abgespeichert werden. also sollte der REU-Sid, wenn man die allerletzten 11 bytes in der REU gelöscht hat unbedingt ein Vielfaches von 25 ( DEZIMAL ) haben.


    3. So jetzt hab ich also mehrere REU-Sids. Die setzte ich im Hex-editor wieder hintereinander zusammen. und füge die allerletzten 11 bytes wieder dazu ( einfach 11 nuller ).
    jetzt habe ich ein aus mehreren Sids bestehendes REU-Sid.


    4. Die Abspiellänge lässt sich ja einfach berechnen, indem man die grösse des entstandenen Files durch 25 teilt. dann erhält man die Abspiellänge in C64-Frames oder Sid-Frames.


    5. Den Trick, wie man die abspiellänge im Nuviemaker hochsetzt, hast Du mir ja erklärt. Ich hab das allerdings ohne Cheatengine gemacht. Einfach Nuviemaker starten - irgendein Sid laden (playlänge 9999) - Während des ladens einen Vice Snapshot machen - Vice Snapshot in Hex-editor laden - nach $270F suchen - ( also 0F 27 , da low byte first im Speicher liegt ). Beim suchen nach dieser byte combi werden 2 stellen gefunden. Die 2. ist die richtige. Also diese 2 bytes mit der richtigen errechneten Abspiellänge überschreiben. Veränderten Snapshot in Vice laden - ob alles geklappt hat kann man feststellen, wenn man den REU-Sid im Nuviemaker kontroll hört und er beim übergang von 9999 zu 1 nicht von vorne anfängt, sondern weiterspielt. Dann Nuvie fertig erstellen und sich diese erstellte REU als Vorlage abspeichern.



    6. dort wird nun der erstellte multi-REU-Sid im Hex-Editor ganz ans Ende hineinkopiert. Darauf achten, daß die REU grösse genau 16 MB also FF FF FF groß ist.



    7. Voila ! - Fertig



    es funktionieren keine endlos langen REU-Sids. Ich glaube bei ca. 20 Minuten ist wohl Schluss. Also nicht FF FF als Abspiellänge hineinkopieren,sonst hängt sich der Nuviemaker beim laden der Bilder in einer Endlosschleife auf !!



    Ich fand das sehr kompliziert. Hab mir immer eine Exel Tabelle gemacht, in der ich die Grösse der einzelnen REU-Sids aufaddiert habe und von FF FF FF abgezogen habe, damit ich wusste, wo ich das ganze Gebilde in die REU reinpasten soll.


    Irgendwann verzwirbelt sich das Gehirn bei den ganzen Hexadezimalwerten.



    Es müsste einfach eine Software geben, die mit diesem REU-Sid Format umgehen kann. Mann könnte sich dann die Sids in die REU "Sampeln" und aneinanderschneiden wie man will. So schwer kann das nicht sein auf Frame Basis die Sid Register in die REU zu schreiben. ( OK die Shadow Register ) ins RAM statt in den I/O Bereich und von dort in die REU. Man könnte eben Sids schneiden, wenn einem z.B. der Anfang nicht gefällt usw.



    Wo der REU intro-Bildschirm liegt, weiss ich auch nicht. Einmal natürlich im VideoRAM. Aber wo noch ? - Vielleicht einfach mal ne byte combi aus dem Videoram im Hex-editor im Vice Snapshot suchen...



    Wo die Jungs die ganzen Bytes in der Reu untergebracht haben ist mir ein absolutes Rätsel. Mein Rat ist, alles solange zu im C64 Speicher zu verändern, solange es noch nicht auf die REU geschaufelt wurde. Das wird auf ewig ein Coder-Geheimnis bleiben.



    Die Playlist liegt im C64 Speicher bei $A000 und im Vice Snapshot ab $A080, solange sie noch nicht auf die REU verstreut wurde.



    Die Bildanzeigedauer lässt sich ja z.B. durch den 90 Token verändern ... also in der Playlist z.B


    <

    00 00 90 1f
    00 01 90 1f
    00 02 90 1f...


    usw


    für eine Slideshow. Wobei $ 1f die Anzeigedauer in C64 Frames ist. Aber komischerweise tatsächlich 1 Frame länger gehalten wird - also $ 20 - also 32 frames dezimal.

    Zitat von buexe74

    Wobei $ 1f die Anzeigedauer in C64 Frames ist. Aber komischerweise tatsächlich 1 Frame länger gehalten wird - also $ 20 - also 32 frames dezimal.

    Das ist doch eigentlich logisch: Das Nuvie-Format ist ja flexibel. Ein Bild, das nicht angezeigt werden soll, muss also in der Liste überhaupt nicht vorkommen (selbst, wenn es trotzdem in der REU vorhanden ist). Falls also ein Bild gar nicht gezeigt werden soll, braucht es auch keine eigene Frameangabe, was in der Interpretation der gegebenen Framesanzahl berücksichtigt wird. Daraus folgt, dass die Frameanzahl in der Liste gleich der angegebenen Zahl + 1 ist. Eine Null in der Liste bedeutet dann also 1 Frame, $ff = 256 Frames.

    Zitat von buexe74


    Wo die Jungs die ganzen Bytes in der Reu untergebracht haben ist mir ein absolutes Rätsel. Mein Rat ist, alles solange zu im C64 Speicher zu verändern, solange es noch nicht auf die REU geschaufelt wurde. Das wird auf ewig ein Coder-Geheimnis bleiben.


    Ja, das ist auf den ersten Blick etwas kompliziert :)
    Ziel war es ja zunächst, so viele Bilder wie möglich in den Speicher zu bekommen, aber auch gleichmäßig, so dass der Player die Bilder leicht und schnell wieder in der C64 zurückschreiben kann.
    Letztendlich ist es so, dass 3 Bilder pro 64k Block abgelegt werden und jedes Bild $5550 Bytes verbraucht.
    Pro 64k Block sind das $FFF0 Bytes. Die restlichen $10 Bytes werden für den Infoscreen, Playlist und Metadaten verwendet.
    D.h. der Infoscreen, Playlist und Metadaten sind in $10 Byte Blöcken über die ganze REU verteilt.
    Und zwar immer an Position: $xx00F0 - $xx00FF.
    Das ganze 256 mal. Insgsamt also $1000 Bytes für Infoscreen, Playlist und Metadaten.
    ich glaube aber, je mehr Musik, desto weniger... kann aber auch sein, dass ich das fest beschränkt hatte.
    Also aufpassen, wenn man längere Musik verwendet, dass die nicht dadurch kaputt geht.


    Bilder sind folgendermasen abgelegt:
    Bild 1 liegt bei $000000 - $00004F und $000100 - $0055FF
    Bild 2 liegt bei $000050 - $00009F und $005600 - $00AAFF
    Bild 3 liegt bei $0000A0 - $0000EF und $00AB00 - $00FFFF
    usw...


    Die Musik liegt "rückwärts" von hinten nach vorne in der REU. Daher...je mehr Musik, desto weniger Platz für die Bilder (von vorne nach hinten...)


    ... wenn ich mich noch richtig erinnere :)

    Danke an buex74 und Roland für die Informationen.


    Dank der Infos von Roland konnte ich nun weitestgehend den Aufbau eines Nuvie-Files herausfinden (wo die Bilder liegen, hat Roland ja schon beschrieben, daher beziehe ich mich auf den Rest, insbesondere die Adressen.


    Ich poste mal hier meine Notizen, die ich bei meiner "Forschung" gemacht habe (Angaben ohne Gewähr, wer Fehler entdeckt: bitte korrigieren).



    $0000F0: 0E 15 16 09 05 30 30 31 16 31 2E 30 20 20 20 20 .....001.1.0 (evtl. Codec-Version)
    $0100F0: E8 DC FF FF 05 B6 FD 00 00 00 FF E6 02 00 A7 00 (Sonderzeichen, Byte 4-6 Musikadresse s.u., der Rest vermutlich Konfigurationsdaten, z.B. Musik ja/nein, Infoscreen ja/nein Farben usw.)


    $(02-0F)00F0: nur Nullen
    $1000F0: B4 00 00 00 90 09 01 00 90 09 02 00 90 09 00 01 Playlist
    $1100F0: 90 09 01 01 90 09 02 01 90 09 00 02 90 09 01 02 Playlist
    $1200F0: 90 09 02 02 90 09 00 03 90 1D B3 00 91 0D B9 00 Playlist
    $1300F0: 91 36 B4 00 02 19 90 1D 91 00 91 00 91 9F E8 00 Playlist
    $(14-8E)00F0: nur Nullen (nur stichprobenartig getestet, Reserve für längere Playlists ?)



    Bildnummern sind anders abgespeichert als im Playlisteditor:


    Bild 000: 00 00
    Bild 001: 01 00
    Bild 002: 02 00
    Bild 003: 00 01
    Bild 004: 01 01
    Bild 005: 02 01
    Bild 006: 00 02
    Bild 007: 01 02
    Bild 008: 02 02
    Bild 009: 00 03
    Bild 077: 02 19 $19 = 25


    Bildnummer = rechtes Byte (Dez) * 3 + linkes Byte
    rechtes Byte (Dez) = int(Bildnummer/3)
    linkes Byte (Dez) = Bildnummer - rechtes Byte * 3


    Die anderen Playlistcodes sind entsprechend dem Playlisteditor abgespeichert.


    $9000F0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 (Infoscreen)
    $9100F0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 (Infoscreen)
    $9200F0: 20 20 20 20 20 20 20 20 20 54 09 14 0C 05 20 20 T.... (Infoscreen)
    $9300F0: 20 3A 20 43 0C 01 13 13 09 03 2D 56 09 04 05 0F : C......-V.... (Infoscreen)
    $9400F0: 07 01 0D 05 13 20 4C 09 16 05 20 20 20 20 20 20 ..... L...
    $(95-CF)00F0: weiterer Inhalt des Infoscreens


    Infoscreen: der Text heißt im Original: "Title: Classic-Videogames Live" - der Hexeditor erkennt die


    Kleinbuchstaben des C64 nicht, abgespeichert sind die Werte in Hex, die man mit Peek(Speicheradresse des Zeichens) erhält


    Ab $D000F0: nur Nullen, bis man irgendwann die SID-Musik erreicht (s.u.).


    Theoretisch wären 3.133.429 Bytes (3.133.440 - 11) für SID-Musik möglich, ohne dass diese durch den Infoscreen
    überschrieben wird, was 125.337 Frames zu je 25 Byte wären, in der Praxis gehen jedoch deutlich weniger: bei mehr
    als 59.412 verrechnet sich der Nuviemaker bei der verbleibenden Bildanzahl und stürzt dann beim Laden der Bilder
    ab (bzw. wird nie damit fertig). Bei maximaler Musiklänge hat man genau 700 Bilder zur Verfügung. Die maximale
    Grenze von 59.412 Frames für die Musik entspricht einer Spieldauer von 19 Minuten und 48,24 Sekunden.


    In den Bytes $0100F4-$0100F6 in der REU scheint der Beginn der SID-Musik in der REU zu stehen im Format
    Low-Byte Mid-Byte High-Byte, im oberen Beispiel bedeudet dann 05 B6 FD ein Start bei $FDB605 in der REU.


    Den Start der Musik kann man so berechnen: im Dezimalsystem: 16.777.216 - Anzahl Musikframes*25 - 11 -> das
    Ergebnis dann in Hex umrechnen, um den Start der Musik zu erhalten (nützlich, wenn man die SID-Daten manuell
    einfügen will). Beispiel: 6000 Frames Musik eingefügt: ergibt 16.777.216 - 6000*25 - 11 = 16.627.205 = $FD B6 05
    als Beginn der Musik in der REU (bei $0100F4 ist dieser Wert als 05 B6 FD abgespeichert).



    Somit fehlen lediglich die paar wenigen "Konfigurationsbytes", die schaue ich mir vielleicht später mal an.


    Mit den Informationen kann man Fehler im Infoscreen nachträglich korrigieren, Sid-Musik leichter zusammenschneiden und "Playlistveränderer" für den C64 basteln (um z.B. vor dem Abspielen einer Slideshow die Reihenfolge der angezeigten Bilder zufällig zu verändern).


    Was mich auch noch interessieren würde: die Bilder haben in der REU eine Größe von $5550 Bytes = 21.840 Bytes. Die *.nuf-Dateien, die der Mufflon-Konverter erzeugt sind aber 23.042 Bytes groß, also 1.202 Bytes mehr. Werden da Daten weggelassen oder komprimiert und wirkt sich das irgendwie auf die Bildqualität der Einzelbilder aus ?

    Ah - das Geheimis lüftet sich !


    Das ist ja schon sehr interressant. Also wenn ich richtig verstehe gibt es 256 "Blöcke" zu je 3 Bildern samt 10 Bytes Metadaten.
    Ich vermute, 8 Bytes davon für die Playlist, was die grösse der Playlist dann auf 2048 Bytes begrenzen würde. Die Playlist wird dann vermutlich zusammenhängend irgendwo in den C64 Speicher geladen, bevor der Nuvie gestartet wird ?? Bloss wo sind hier 10 freie Bytes übrig ?


    ich kann nur 1 freies Byte finden. das wär dann $0000FF . aber wohin sind die 8 Playlist-Bytes verschwunden ??



    Du sagst, die Nufli Bilder werden in 2 Teile gesplittet. Aber die sind wahrscheinlich dann möglichst so zusammenhängend, dass sie "in einem Rutsch" in den C64 Speicher transferiert werden können, oder ?
    $4F + $54FF ergeben $554E also 21.838 bytes pro Bild.


    Also wenn man ein normales unkomprimiertes nufli lädt, lädt es ja nach $2000 bis $7A00 und belegt somit $5A00 bytes also 23.040 bytes



    Die restlichen $1202 bytes sind dann also für jedes Bild gleich ( vielleicht der anzeige Code ? )


    Also was müsste man machen, um z.B. das 1. Bild in der Reu durch ein normales nufli im C64 Speicher zu ersetzen ?


    Angenommem, man möchte die Playlist nachträglich nochmal verändern und hat eine saubere, zusammenhängende Playlist von 2048 Bytes im C64 Speicher stehen... An welche Reuadressen müsste man sie " zerhackt " schicken ?



    Ist das Nufli Format eigentlich irgendwo dokumentert ?


    Codebase64 weiss nur folgendes:


    " The latest invention (at the time of writing) in the UFLI-series is NUFLI. The spec of NUFLI
    is quite complicated, and it is more like a rendering format. An
    original picture is used as input to a converter tool, which does its
    best to represent the picture within the given limits. The timing code
    is then generated, including as many sprite-color or other HW-register
    manipulations as there is room for. When the code is generated, you can
    use an editor to hand-fix the areas that you are not satisfied with. NUFLI
    covers the whole screen, thus the resolution is 320×200 pixels, though
    the amount of availible colors is not the same on the whole screen."



    Weisst du zufällig noch, wie lang die Musik sein darf? Viel höher als $CC80 konnte ich den Musik Framecounter nicht hochsetzten. Ein Lied mehr, und der Nuviemaker konnte keine Bilder mehr importieren, obwohl theoretisch noch viel Platz auf der Reu für Musikdaten gewesen wäre.


    ... Komisch ...
    als ich angefangen hab zu schreiben, waren die Infos von daddlertl noch nicht da.


    Er scheint die REU ja wie eine Zeitung lesen zu können... :thumbup:


    Scheinbar auf der gleichen Mission wie ich:


    " Das Geheimnis des Nuvies " :winke:


    Mir schwebt irgendwie die ganze Zeit so eine Art Schnitt-Tool für Ton und Bild vor - wie Premiere oder so ähnlich... am C64 !
    besonders das REU-Sid-Format hat es mir angetan .
    HÄ - aber hier muss ein Rechenfehler sein : theoretisch über 3 1/2 Stunden Musik auf einer REU ?????? :whistling:


    EDIT: Aha die Frage nach der praktisch verfügbaren Musikllänge hat ja daddlertl beantwortet ! das bedeutet dann für den Musik Framecounter ein MAXimum von $E814 !



    Aha ! Und die Playlist Bytes verstecken sich scheinbar in den letzten 10 Bytes des jeweils 2.Teils jedes Bildes, richtig ?

    Ihr scheint ja Spass zu haben, das alles zu entschlüsseln Dann lasse ich euch mal machen und verrate nicht zu viel :)
    Allerdings: Der Aufbau eines einzelnen separaten NUFLIs und die Art wie sie für Nuvies in der REU gespeichert sind, ist nicht der selbe.
    Schon weil ein NUFLI ja auch einen Displayer mit integriert hat und dieser in der REU nicht mehr gebraucht wird.
    Für die Art wie sie dann in der REU liegen ist es eben wichtig, dass die Daten effizient in den C64 zurück übertragen werden. Und das ist eben nicht immer alles an einem Stück.
    Daher ist es nicht so ohne weiteres Möglich, nachträge per Hand ein Bild auszutauschen.


    Zu den Musikdaten: In den Metadaten steht die Startspeicherstelle (in 3 Bytes... meist fast ganz am Ende im Seichers) und nur 2 Bytes für die Endspeicherstelle (weiter vorne im Speicher, da die Musikdaten ja rückwärts ausgelesen werden). Achtung: NICHT die Länge ist in den Metadaten abgespeichert, sondern wirklich nur das Low und Middle Byte. Das Highbyte ist für den Ende-Check irrelevant, da sich die Low+Middlebyte Kombination nicht vor 65536 Durchläufen wiederholt und nicht mehr als 65536 Frames für die Musik geplant war.

    Erstmal muß mann das Format entschlüsseln - bis dahin ist alles - "HEXerei" !
    ( Es sei denn man hat es selbst gecodet ... )


    Die effizienteste Methode ( in sachen Geschwindigkeit ) ist es eben schon daten per DMA am Stück zu übertragen. Gut, da "nur" alle 4 C64 Frames ein Bild übertragen werden muß ist die Sache mit der Übertragung nicht mal besonders zeitkritisch. Aber es macht ja keinen Sinn zusammenhängende Daten nicht am Stück zu übertragen. Mir fallen nur 2 Gründe ein, das nicht zu tun. Wenn sich das "Übertragungszeitfenster schliesst" ( also während das nufli tatsächlich dargestellt wird, sollte die Reu mal pause machen - dadurch bleibt aber ungefähr ein Zeitfenster von 7000 cycles für eine von 4 Übertragungen.) Und der 2. Grund wäre, wenn die Daten eben nicht zusammenhängend sind, sondern irgendwo verstreut im C64 Speicher liegen müssen ( Und dazwischen eben Leerräume sind )


    Ohne den C64 Speicher jetzt genau unter die Lupe genommen zu haben tippe ich mal darauf, daß:


    Die Bitmap bei $4000 liegt und sich die 4 VideoRams "nahtlos" ( mit einer Lücke von 192 bytes ) daran anschliessen ab $6000.


    Bleibt also für die Spritedefinitionen und den darstellungsCode der Platz von $7000 bis $7a00 oder davor von $2000 bis $4000. Aber da sie der VIC in der gleichen VIC-Bank sehen möchte, wohl eher danach.
    Ich glaub 7 Sprites in einer Reihe zu je 3 Bytes macht 21 Bytes mal 200 Rasterlines = 4200 Bytes an Spritedefinitionen. ( Nur die Daten - nicht die Farben ) Ich nehme mal an, dass die Spritedaten nicht am Stück übertragen werden weil sie bestimmt wild im Speicher rumliegen.


    ( vielleicht korrigiert das jamand, wenn ich mit diesen Vermutungen falsch liege ... )


    Was ich nicht verstehe, ist, wie ihr es schafft, dass das gerade angezeigte Bild nicht vom darauffolgendem zerstört wird. etwa ein DoubleBuffer in der obersten VIC-Bank ?


    Na jedenfalls kann man ja folgende Rechnung aufstellen.
    Wir wissen jetzt, daß pro Bild 21.838 übertragen werden.
    Darin enthalten müssen folgende Daten sein:


    pro Bild übertragen 21.838 Bytes


    Die Bitmap mit 8000 Bytes
    Die 4 FarbRams mit 4000 Bytes
    Spritedaten 4200 Bytes


    sind schon 16200 Bytes


    bleiben also 5183 Bytes


    für den Bildspezifische Darstellungscode, Änderung der Farben etc.


    Aber so richtig viel schliessen kann man daraus auch nicht...


    ...es ist eben alles ein Geheimnis solange es nicht dokumentiert wird.


    Oder man schaut sich im Vice Monitor mal ( während des schreibens der Bilder auf die REU ) mal genau Schritt für Schritt an, welche Werte an die Register der REC übergeben werden.


    Ich glaub, wenn man nachträglich Bilder ändern will, wird einem nichts anderes übrig bleiben, als ein neues Nuvie (mit dem neuen Bild an der richtigen stelle) im Nuviemaker anzufertigen, und sich die Playlist und den Sound aus der alten REU in die neue Kopieren - per Hex-Editor.

    Du liegst da ziemlich falsch. :)


    1. Die Daten liegen leider nicht am Stück und sind über 2 VIC Bänke verteilt (ebenso der Darstellungscode). Mit einer VIC Bank klappt das mit den Sprites nicht (übriges 8 pro Zeile)
    2. Es wird ein Double-Buffer verwendet wobei immer die Bänke 0 +1 oder 2 + 3 angezeigt werden.
    3. Es sind nicht nur reine Bilderdaten, sondern auch ein großer Teil des Codes für die Darstellung die übertragen wird.
    Der Grund ist recht einfach. Die reinen Daten im Codeteil (Farben) sind recht unregelmäßig enthalten (so alle 5 Bytes ...+/-).
    Die kann man nicht so einfach ohne den Code drumherum aus der REU schaufeln. Dadurch wird der Datenanteil wesentlich größer. Eben die $5550 Bytes, die pro Wechsel übertragen werden. Aber eben nicht alles an ein Stück. Gerade die durch die 2 VIC Bänke verteilten Farbscreen lassen die Daten recht wild im Speicher liegen.
    4. Auch wenn nur alle 4 Frames das Bild gewechselt wird, ist die verfügbare Zeit arschknapp. Ansonsten wäre das mit dem Musik-Recording/Abspielen nicht notwendig gewesen.
    Ist ja auch leicht auszurechnen: Alleine für die Bilddarstellung ehen 200 Rasterzeilen drauf. Wenn man dann die 21838 Byte Daten geteilt durch 4 teilt kommen ca. 5460 Byte pro Frame raus. Die geteilt durch 63 Zyklen pro Zeile macht ca 87. Sprites fressen auch noch ein bissle unter dem Bild. Da bleiben dann nur noch ca. 20 für Musik, und einiges an Logik übrig. Die DMA Routine muss immer wieder mit neuen Start und Zielposition gesetzt und gestartet werden. Zuletzt waren wirklich nur noch ein paar Zyklen frei.


    ps: ich glaube aber, ich habe zumind. das NUFLI Format mal irgendwo genau beschrieben. Da kann man danan zumind. sehen, wie die Daten eines Bild im Speicher liegen.

    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)

    Urgh ! ... also doch etwas komlizierter als vermutet ... Wer hätte das gedacht ... 4 VIC-Bänke im Einsatz ... 8\|:Ssshock:



    Da blick ich nicht mehr durch ... Werd mich wohl erstmal auf die Playlist beschränken ! :blass:


    Aber vielen Dank erstmal für die ausfühlichen Infos. :respect:

    Was auch noch toll wäre: wenn es ein besseres "Aufnahmeprogramm" für Sid-Files gäbe: das im Nuviemaker kann ja nur Sid-files mit den Adressen $1000/$1003 nutzen und selbst da laufen dann nicht alle korrekt.


    Ich kann leider nicht gut programmieren, aber vielleicht könnte jemand, der sich damit auskennt einen C64-Emulator oder SID-Player so erweitern, dass er während des Abspielens eines SID-files die Register "abgreift" und im "Nuvie-Sid-Format" abspeichert (im Gegensatz zum echten SID kann man die Register in einer Emulation ja auslesen, da die Daten ja im RAM des PCs landen). Bei der Emulatorvariante könnte man dann sogar SID-Musik und Soundeffekte von Spielen, Demos etc. abgreifen.

    das mit dem "nicht alle SID Tunes laufen korrekt" liegt daran, in welcher Reihenfolge die unterschiedlichen Musikplayer ihre Daten in den SID schreiben.
    Wenn das im NUVIE Player nicht in der selben Reihenfolge geschieht, klingt die Musik "komisch"...oder eben gar nicht :)
    Beim NUVIE Player wurde eine Reihenfolge gewählt, die eben so die meisten Player verwenden (vor allem die JCH Player).
    Ich habe das bei dem einen oder anderen NUVIE auch mal über die Code-Injektion vor dem Start angepasst. Aber eine Analyse im NUVIE Maker ist halt nicht drin.

    Hier ein Zitat aus der Anleitung:


    " Depending on the player used, not all musics are compatible. As the musicdata is recorded from the musicroutine, this works only for players that set SID values only once per frame, e.g. the JCH Newplayer V15 does not work. "


    An so ein Aufnahmeprogramm würde ich mich noch ran trauen - mit eurer Hilfe natürlich - falls es sowas noch nicht gibt. Sollte eingentlich nicht so schwierig sein ( ich hoffe ich lehn mich hier nicht zu weit aus dem Fenster )


    Also soweit ich das verstehe, blendet man die I/O Register aus, damit die Register-Writes des Sids im RAM unter dem I/O Bereich landen. Von dort aus sollte man sie dann Frame für Frame je 25 Werte in die REU schreiben können. Wenn man weiss, welche Register wohin geschrieben werden sollen. Ich wage zu vermuten, es könnte sich hierbei um die ersten 25 Sid register handeln ? ( habs aber noch nicht getestet ) und hoffe innnnständig !!!!! , dass die alle am Stück der reihe nach (von 0 nach 25 aufteigend ) ( ich wags kaum noch auszusprechen ) "-IN EINEM RUTSCH-" in die REU übertragen werden. Das wäre zumindest am einfachsten, da die REC ja nicht gerne rückwärts zählt, oder ? der 1. Frame natürlich an die obersten 25 Bytes der REU ( minus die 11 Bytes ganz zum Schluss ).
    Das wär ein schönes Format und lässt sich gut bearbeiten und ne ganze Menge anderer lustiger Sachen mit anstellen, von denen man vorher nicht mal träumen durfte.


    Was die verschiedenen Sid Adressen betrifft könnte so ein Programm ja in mehreren Versionen vorhanden sein, dass es jeweils nicht mit dem sid kollidiert.


    Allerdings klappt das relocaten mit Sidreloc auch bis auf wenige Ausnahmen ganz wunderbar, wie es hier im thread sehr gut beschrieben wurde.


    Die Reihenfolge der Register-Writes macht der nuvieplayer ja automatisch.

    Hallo,


    Ich wollte mal darauf hinweisen, saß ich die Version mit mehreren Sids von meiner Nufli Slideshow mal auf Youtube gestellt habe,
    damit sie auch Leute ohne REU anschauen können :


    [Externes Medium: https://www.youtube.com/watch?v=KM_1anL5PsE]


    Mein REU-Sid-Recorder Projekt bewegt sich irendwie im Schneckentempo vorwärts. Das liegt aber bisher nicht an prinzipiellen Problemen, sondern eher am User Interface, da es ja leicht zu bedienen sein soll ... und das ist ganz schön aufwendig. Ich hoffe, ich kann hier bald eine funktionsfähige Version vorstellen, damit jeder problemlos seine Nuvies nachvertonen kann.