Posts by daddlertl

Quote from Bender

Quote from Stumpi

Quote from Bender

Es war mit eine Freude, der DoReCo Party Bericht 2022

Ähh..... wat?

Wo kommt das denn her?

Das mit "nackt" steht in den Dokumenteneigenschaften von dem pdf...

Ich habe meine Fotos und die C64-DoReCo-Hits-Breadamp-Compilation auf den FTP hochgeladen.

Mit diesem Programm soll man Images in eine REU laden können (habs nicht ausprobiert, obs geht) : https://csdb.dk/release/?id=122290

Nach 4 lustigen Retro-Tagen ist die DoReCo-Party 2022 nun zu Ende. Danke an das Orga-Team und die Teilnehmer für diese tolle und lange Veranstaltung. Es hat mir wieder viel Spaß gemacht

Da ich nach der Heimreise noch recht fit war, habe ich mich gleich an den Zusammenschnitt des dritten Nuvie-Teils gemacht (die ersten 2 hatte ich vor Ort auf der DoReCo gemacht und vorgeführt), eine Aufnahme erstellt und das ganze auf Youtube hochgeladen. Somit kann ich euch sogar taggleich das Nuvie präsentieren mit Bildern und Videoclips von Heute (sie sind im dritten Teil zu sehen).

Aus einem mir unbekannten Grund erzeugt Youtube momentan kein Vorschaubild... einfach auf den Play-Knopf klicken:

Herunterladen kann man das Nuvie hier: https://www.dropbox.com/s/f2ib…oReCo-Party_2022.rar?dl=1

Breadamp ist hauptsächlich für die 16 MB REU der 1541ultimate gemacht.

Theoretisch kann man auch eine echte 512 KB-REU nutzen, bekommt dann aber nur zwischen 32 Sekunden und knapp 3 Minuten in die REU, je nach Qualitätsstufe, wobei die niedrigste mit der längsten Spielzeit echt mies klingt.

Um eine echte 512 KB REU nutzen zu können, muss man mir dem Breadamp-REU-Maker ein Image generieren das max. 512 KB an Daten enthält (es wird immer ein 16 MB Image erstellt, man kan den überschüssigen Teil aber einfach abschneiden, wenn da keine Daten drin sind) und sich einen Loader bauen, der die Daten dann in die echte REU lädt. Dazu bräuchte man aber 3 Diskettenseiten oder eine 1581, was recht aufwändig ist nur um ein recht kurzes Soundsample zu hören.

Das ist auch der Grund, warum ich sowas nicht gebaut habe, weil das bei der Benutzung einfach keinen Spaß macht, das geht mit der 1541ultimate viel einfacher: Image auf dem USB-Stick wählen und in die REU laden, Breadamp starten.

Dieses Auto ist sehr auffällig und mit dem korrekten Firmenlogo bedruckt

Wie war das nochmal mit "Huckys Schnaps verzerrt ein klein wenig den Wettbewerb" ?

Nur noch 16 Tage !

Wenn man einen C64 mit 1541ultimate-Modul oder einen Ultimate 64 hat, kann man sich zur Einstimmung schonmal die DoReCo-Hits reinziehen, die man hier herunterladen kann.

Um die Musik zu hören, muss man in der 1541ultimate bzw. im Ultimate 64 die REU mit 16 MB aktivieren und andere Cartridges deaktivieren, die zum SID (6581/8580/FPGASID) passende reu-Datei in die REU laden und die Datei BREADAMPv06.prg starten, dann sollte die Musik zu hören sein.

Hat man einen Ultimate 64 ohne eingebauten SID kann man auch Ultimate Audio aktivieren und die Datei DoReCo-Hits_FPGA_UA.reu nutzen, dann wird die Musik über das Ultimate Audio-System abgespielt. Dieses kann man auch mit der 1541ultimate-II-(plus) nutzen, muss dann allerdings den Audioausgang des Moduls nutzen, um die Musik hören zu können.

Die Tracklist:

1 CZ-Tunes - DoReCo-Theme

2 Retroluzzer & Die DoReCo Goldkehlchen feat. M.A. Peel - Die DoReCo ist wieder da!

3 CZ-Tunes - DoReCo-Theme Instrumental

(Titelnamen auf dem C64 aufgrund Titelnamenlängenbegrenzung eingekürzt)

Bei Ebay gibts Netzteile, da steht "Brandneu". Bei der Beschreibung kann man nur hoffen, dass es bei der Benutzung keinen Brand gibt.

Grob zusammengefasst:

- Sample Rate ist 11,7 kHz, es werden 6 Samples pro 8 Rasterzeilen gespielt und zwar vom Timing so, dass keine Störungen durch die Badlines entstehen - hier habe ich die "Technologie" von meinem Breadamp Musikplayer übernommen

- In diesem Video beträgt die maximale Framerate 8,33 fps (50/6), an Stellen wo weniger "Action" statt findet und beim Abspann ist die Framerate reduziert, um Speicherplatz zu sparen. Der Player schafft aber bis zu 16,66 fps (50/3), was man bei kürzeren Videos nutzen könnte.

- Die Sampleabspielroutine nutzt einen 256 Byte großen Buffer, der gelegentlich vom Hauptprogramm überprüft wird durch Checken des höchstwertigen Bits der Abspielposition: befindet sich der Sampleplayer auf der zuletzt aufgefüllten Bufferhälfte, wird die andere Bufferhälfte mit neuen Daten gefüllt, durch den nur 256 Byte großen Buffer ist das eigentliche Abspielen ganz einfach: Wert aus Samplebuffer y-referenziert laden, Wert in $D418 schreiben, y inkrementieren (y darf im Hauptprogramm nicht angefasst werden, dafür wird aber die Samplewiedergabe beschleunigt, weil y nicht jedes mal gesichert und wiederhergestellt werden muss, dies ist nur für den Akku nötig)

- Aus der REU werden immer nur maximal 8 Byte pro Transfer geholt, dafür aber mittels Speedcode in schneller Folge. Dies erlaubt dem Sampleplayer-NMI sich zeitnah "dazwischenzuschieben", um ein Sample zu spielen. Zu große Transfers erzeugen einen zu großen und damit hörbaren Jitter beim Sampletiming, zu kleine Transfers erzeugen zuviel Overhead. Die 8 Byte haben sich als guter Kompromiss herausgestellt: der Sound klingt (für C64-Verhältnisse) gut und bei einem 16:9-Video sind 16,66 fps erreichbar (bei 16:10 = Vollbild gehen vermutlich nur 12,5 fps wegen der größeren Datenmenge pro Frame, bei 4:3 vermutlich auch nur 12,5 fps weil man wegen den Rändern links und rechts die Adressen häufiger "nachjustieren" muss, beide Fälle habe ich aber noch nicht getestet, deswegen sinds nur Vermutungen)

- Das Hauptprogramm buffert die Bitmap- und Screendaten wechselseitig in einer zweiten VIC-Bank, ist das erledigt, wird zu einem günstigen Zeitpunkt die VIC-Bank umgeschaltet und das Farb-RAM mit neuen Daten gefüllt (da dies nur einmal vorhanden ist, muss man das in "Echtzeit" machen, nämlich während der Rasterstrahl im Rahmen ist, damit man keine Farbglitche sieht.

- Ist ein Videoframe angezeigt, wartet der Player darauf bis der korrekte Frameskip (in diesem Fall 6) erreicht ist, um die korrekte Abspielgeschwindigkeit zu erhalten. Während der Wartezeit wird nur in Dauerschleife überprüft, ob noch genügend Sampledaten im Samplebuffer vorliegen und wenn nötig wird nachgefüllt.

- Die Koaladaten sind leicht komprimiert: 1. habe ich bei diesem 16:9-Video die Daten der oberen und unteren Zeilen ("schwarze Ränder") nicht gespeichert, was 800 Byte pro Frame einspart und die Daten fürs Farb-RAM sind komprimiert: jeweils 2 x 4 Bit in einem Byte, das spart nochmal 460 Byte pro Frame, Gesamtersparnis in Summe also 1260 Byte pro Frame, Größe der Bilddaten 8.740 statt 10.000 Byte pro Frame (+die Hintergrundfarbe, die im "Adressverzeichnis" gespeichert ist, wo für jedes Bild die 3 Byte große REU-Adresse und die Hintergrundfarbe abgelegt ist, also insgesamt 4 Byte, wodurch man wieder eine schönere und leichter zu handhabende Anordnung der Adressverzeichnisdaten hat (Datenfelder mit einer Länge von 2^x lassen sich programmiertechnisch immer leichter handhaben als "krumme" Längen). Die Farb-RAM-Dekomprimierung benötigt trotz Optimierungen und Speedcode einiges an Rechenzeit, weshalb es sein kann, dass bei 16:10- und 4:3-Videos nicht genug Rasterzeit vorhanden ist, weil zum einen mehr Daten entpackt werden müssen und zum anderen weniger Rasterzeilen zur Verfügung stehen, weil diese Formate ja mehr Zeilen beanspruchen als 16:9

- Das 16:9-Format ist mit der Auflösung 320x184 (eigentlich 160x184 mit doppelt breiten Pixeln) angenähert, um oben und unten genau 8 Zeilen übrig zu haben, die jeweils der Höhe eines Zeichens im Textmodus entsprechen. Dies verhindert Geflacker am Videorand durch wechselnde Hintergrundfarben der Koalabilder

Wie man sieht war einiges an Bastelei nötig, um das vernünftig zum Laufen zu bekommen. Dieser Test sollte die Machbarkeit eines Videoplayers zeigen und ist Grundlage für die Entwicklung eines universellen Videoplayers, der die 3 Videoformate 16:9, 16:10 und 4:3 abspielen können soll und eventuell auch mehrere Sampleraten beim Ton unterstützt. Zusätzlich kann ich mir auch noch so Spielereien wie Vor- und Zurückspulen vorstellen. Zusätzlich muss ich auch noch ein paar Hilfstools schreiben, um die Erstellung von Videodateien zu vereinfachen. Dieses Testvideo habe ich nur mit rudimentären Tools und Handarbeit zusammengestellt.

Wie vor einiger Zeit hier geschrieben, hatte ich vor zu versuchen, ob ich das DoReCo-Video von Der Retroluzzer auch mit Samplewiedergabe auf dem C64 zum laufen bekommen kann, sodass man auch den Originalton zu hören bekommt. Die Antwort lautet nach einiger Probiererei nun JA, es geht ! Ein paar kleine Einschränkungen gibt es aufgrund des begrenzten Speichers von 16 MB, die die REU der 1541ultimate bietet: ich musste Frames sparen, was sich manchmal in etwas ruckeliger Wiedergabe äußert und die Timings sind, insbesondere bei den "Slideshows" nicht immer perfekt. 16 MB sind zwar für den C64 viel Speicher, bei Videos stößt man dann aber doch an Grenzen.

Hier eine Aufnahme des Ergebnis auf Youtube:

Wer es auf seinem echten C64 mit 1541ultimate, einem Ultimat 64 oder einem geeigneten Emulator ausprobieren möchte, kann sich das Video hier herunterladen: Download

Dieses Experiment legt auch den Grundstein für einen universellen Videoplayer, der dann wie der Nuvieplayer verschiedene Koala-Videos abspielen können soll, sodass man nicht für jedes Video einen eigenen Player braucht. Desweiteren muss ich auch noch ein paar Tools schreiben / verbessern, damit man sich seine eigenen Videos konvertieren kann. Der universelle Videoplayer wird mein nächstes Projekt.

Das Spiel Nono Pixie hat Mausunterstützung, Lemmings auch.

Quote from Snoopy

Es geht darum, dass der Bug nun mal in den orginialen REUs drin ist.

Es gibt aber keine originale REU von Commodore, die diesen Bug hat. Die REUs von Commodore hatten maximal 512 KB, damit kann der Bug nicht auftreten. Die REUs, die den Bug haben sind die, die nachträglich "aufgebohrt" wurden, indem weiterer RAM eingelötet wurde. Das ist aber nicht original und dass es zu Bugs kommen kann, wenn mann Modifikation an der Hardware vornimmt, die von den Entwicklern nicht vorgesehen waren, ist nicht sehr verwunderlich.

Der Wrap Bug wird aber von keiner Software benötigt, der ist nur lästig und man muss drumherum programmieren. Wenn man dies tut, läuft die Software aber auch, wenn der Bug nicht existiert, z.B. der Nuvieplayer und Breadamp laufen sowohl mit als auch ohne Wrap Bug.

Es handelt sich hierbei um einen Adressierungsbug, der auftritt, wenn man einen Transfer über eine 512K-Grenze hinaus macht (Grenzen sind $080000, $100000, $180000, ..., $E80000, $F00000, $F80000).

Um das zu umgehen, sorgt man in seiner Software dafür, dass man keinen Transfer über diese Grenzen hinaus macht. Das kann man entweder machen, indem man die Daten in der REU so anordnet, dass z.B. ein Bild / Datenpaket nicht über solch eine Grenze geht (z.B. bei Nuvies oder bei Breadamp) oder im Programm dafür sorgt, dass ein "grenzübergreifender" Transfer in zwei Transfers gesplittet wird (z.B. von $07xxxx - $07FFFF und von $080000 - $08yyyy).

Macht man das nicht und überschreitet beim Transfer z.B. die Grenze von $080000, liest er nicht ab $080000 weiter, sondern ab $000000 oder ab $F80000 (habe beides schon erlebt, hängt offenbar von der Emulation ab), was natürlich nicht das ist was man möchte (ergibt dann Datenfehler, z.B. korrumpiertes Bild).

Ist der Bug nicht vorhanden und das Programm erwartet den Bug und splittet den Transfer in zwei Teile passiert gar nichts: dann macht das Programm trotzdem den gesplitteten Transfer, auch wen er nicht nötig wäre und erhält die korrekten Daten.

Mir ist kein Programm bekannt, dass diesen Adressierungsbug benötigt / ausnutzt. Mir fällt auch kein Szenario ein, wo man diesen Bug sinnvoll zu seinem Vorteil nutzen könnte, er ist in der Regel einfach nur lästig und zieht die Performance der Programme runter, weil sie mit zusätzlichen Prüfungen und Transfers um den Bug herumarbeiten müssen (musste ich z.B. bei meinen Videoplayer mit dem DoReCo-Video, da kam "Daten ausrichten" nicht in Frage, weil ich da so große Lücken gehabt hätte, dass das Video nicht in die 16 MB gepasst hätte).

Original von Commodore gabs doch nur die REUs bis 512 KB, alles andere waren doch "aufgebohrte" REUs, die nachträglich mit mehr Speicher erweitert wurden und genau die haben diesen Wrap Bug. Ich vermute mal, dass Commodore das so nicht rausgegeben hätte, wenn sie eine größere REU angeboten hätten, sondern auch den Adressbereich des DMA-Chips erweitert hätten.

Gib mal ein Beispiel für so eine Stelle (Zeitstempel) und schreib mal wie groß die Abweichung ist. Kleinere Abweichungen kommen dadurch zu Stande, weil das SID-File ja eine Neuinterpretation des Originalstücks ist und daher nicht zwangsweise 1:1 von der Geschwindigkeit mitläuft. Ich habs an markanten Punkten synchronisiert, z.B. beim "Trinkt".

Quote from Der Retroluzzer

Meinst Du man kann das noch ein bischen synchronisieren, dass der Text zur Melodie passend läuft?

Läuft das Video bei dir unsychron ? Eigentlich habe ich das so gut es ging synchronisiert, sodass es maximal Abweichungen von wenigen Zehntelsekunden gibt. Wie groß ist bei dir die Abweichung zwischen Text und Melodie ? Falls es mehr als eine Sekunde oder sogar noch mehr ist, mal einen anderen Browser probieren, ein ähnliches Problem hatte ein Vereinskollege mal beim Anschauen eines unserer Vereinsvideos, da half auch ein Browserwechsel oder sogar nur ein Neustart, weiß nicht mehr genau.

Da nun der Anmeldethread eröffnet wurde gibts nun Party auf dem C64:

Ich habe ein kleines Programmierexperiment gemacht und das DoReCo-Video, das Der Retroluzzer auf der 2021er-DoReCo veröffentlicht hat in eine Folge von 1900 Koala-Bildern umgewandet und einen Player in Assembler geschrieben, der das ganze mit 10 Bildern/Sekunde abspielt. Dazu läuft wie beim Nuvie die SID-Musik "SIDs in America" von Nordischsound .

Manche hatten sich ja über die 4 fps beim Nuvie beschwert. Mit Koalavideo schafft man nun das 2,5-fache, allerdings bei etwas geringerer Bildqualität, da Koala weniger Informationsgehalt hat als Nufli (das in Nuvies genutzt wird), dafür passen aber mehr Bilder in die REU und Koala ist im Gegensatz zu Nufli nicht timingkritisch, sodass sogar Samplewiedergabe möglich sein könnte (das werde ich als nächstes probieren).

Hier das ganze als Aufnahme auf Youtube:

Hier kann man sich das Koalavideo samt Player herunterladen: Downloadlink

Ich melde mich hiermit an für alle Tage und hätte gern den Platz 57.

Danke dass ihr diese tolle Party wieder organisiert, ich freu mich schon drauf !

Hier wurde das Thema Zurücksetzen auf Werkseinstellung diskutiert. Funktionieren soll es wohl mit dem Firmwareinstaller von markusC64, ob es mit den neusten Firmwareversionen noch geht, weiß ich nicht, der Thread ist schon fast 3 Jahre alt.