Hello, Guest the thread was called22k times and contains 122 replays

last post from Squidward at the

Bad Reception TV (BR-TV)

  • Ich habs grad mit meinem TC64 getestet: da tritt der REU-Bug nicht auf, weil das TC64 bei einer REU-Größe von 16 MiB keinen REU-Bug emuliert, das machen nur die 1541ultimate und viele Emulatoren, was ich für unnötig und störend halte, da es nie eine echte 16 MiB-REU gegeben hat und man somit gar nicht sagen kann, ob mit die Emulation mit oder ohne REU "korrekt" ist.


    Der REU-Bug trat bei echten REUs auch nur auf, wenn man z.B. eine 512 KiB REU durch Hinzufügen von weiteren RAM auf 1 oder 2 MiB erweitert hat (was offiziell nicht vorgesehen war). Bei derartig "aufgebohrten" REUs tritt folgender Bug auf, der durch den Controllerchip ausgelöst wird: liest man von der REU einen Adressbereich, der die 512 KiB-Grenze (oder ein vielfaches davon) überschreitet, so wird alles nach der 512 KiB-Grenze von Adresse 0 an gelesen (der sog. "Wrap around bug").


    Vermeiden kann man dies, indem man solche Transfers in zwei Transfers splittet: der erste Transfer liest bis zur dieser Grenze und der zweiter hinter dieser Grenze (in der nächsten REU-Bank) weiter. Durch das Setzen der neuen REU-Bank beim zweiten Transfer wird dieser Bug umgangen.

  • i can upload a small tutorial video explaining the basics (Personal Jesus Video).

    Das wäre wirklich gut, wenn du das machen könntest, kann ruhig auf Englisch sein, mich haben auch schon englischsprachige Leute gefragt, wie man solche Videos macht und ich könnte durch so ein Video vielleicht auch noch ein paar Tipps bekommen (bisher habe ich es immer nur durch Lesen von Anleitungen und Ausprobieren gemacht).

  • Zeit hab ich leider immer noch keine, aber ich hab mal kurz deine Hires Bad Apple Files angeschaut - übrigens genau das, was ich damals auch machen wollte. Aber es war mir zu viel Arbeit mit einem Zeichensatz pro Frame. Deshalb habe ich das "1 Charset" Beispiel draus gemacht :)


    Das Problem ist im Header. Er listet das Video als "Single Charset" und "Colorram every Frame". Beides sollte nicht so sein, da ja jedes Frame einen eigenen Zeichensatz hat und das Colorram fix ist (nämlich einmalig auf Hires Black gestellt). Die Grafik Fehler entstehen wohl, weil er zwischendurch (eventuell durch ein Flag in den Screen Meta Daten) falsche Daten fetcht.


    Wenn ich den Header auf "Charset every Frame" (geht nur im Header) und Colorram auf " $0 Hires" (kann auch im Player verstellt werden) ändere gibt es wohl keinen Fehler mehr. Eventuell reicht auch schon eine der zwei Änderungen, richtig sind aber beide.





    Schreib mal in den Header an Stelle $14 eine $00 statt $02
    und an Stelle $19 eine $00 satt $30






    Hoffe, das funktioniert... :)

  • Ich habe es gerade im VICE getestet: es funktioniert :) Das hatte ich nicht erwartet, dass ein Video mit derartig falschem Header trotzdem erstmal fehlerfrei abgespielt wird, aber gelegentlich einen REU-Bug verursacht.


    Ich werde in den nächsten Tagen einen Bugfix für den BR-TV-Maker rausbringen, der diesen Fehler und einen anderen, den ich noch gefunden habe, behebt.

  • Ich habe den Bug im BR-TV-Maker gefixt (hoffentlich). Hier ist die neue Version: Download BR-TV-Maker v02


    Das ganze war ein Folgefehler: ich hatte für $14 noch eine falsche Variable drin (die eigentlich nur Testzwecken dienen soll und die ich vergessen habe anzupassen), wodurch dort $02 reingeschrieben wurde, was dazu führte, dass das Video trotz $00 an der Stelle $19 nicht lief (weil er keine Charsets geladen hat und bei $ff.f400 - $ff.fbff in der REU natürlich auch nichts stand). Fälschlicherweise habe ich gedacht, dass der Fehler an der Stelle $19 liegt, weil in der Readme zum Player hinter der Beschreibung zum Wert $00 an der Stelle "(not implemented yet)" -> dadurch habe ich fälschlicherweise vermutet, dass $00 ein nicht unterstützter Wert ist und habe einfach den nächsten Wert probiert, wo nicht "not implemented yet" dahinter steht und damit lief es, obwohl es von der Logik her damit auch nicht laufen dürfte. Es gab lediglich die REU-Bugs, die ich aber nicht mit dem Header in Verbindung gebracht habe und stattdessen nach dem Fehler im Bilddatenbereich gesucht habe und dort natürlich keinen Fehler finden konnte. Wie dem auch sei: dank deiner Info konnte ich den Bug beheben und nun funktioniert es ja fehlerfrei :)



    Hier noch das buggefixte Video:




    Der Downloadlink bleibt der Gleiche, ich habe nur die fehlerhafte Datei auf meinem Webspace gegen die buggefixte getauscht: Download BR-TV Bad Apple



    (PS: das Konvertieren hat bei Bad Apple gar nicht so lang gedauert - jeweils nur ein paar Stunden - weil wegen der einfachen Grafik bei CSAM Super der Pixel Error bei den meisten Frames sehr schnell auf 0 ging - ich habe meinem AutoIt-Script die Anweisung gegeben, bei Erreichen von Pixel Error 0 das Processing sofort zu beenden und das konvertierte Bild abzuspeichern, denn besser als Pixel Error 0 geht es nun wirklich nicht)

  • Ich habe zwei weitere BR-TV-Videos erstellt, die ich beide auf der Retrolution 2018 veröffentlicht habe:


    Das erste ist eine Konvertierung des Retroluzzer Theme Song -Videos:


    Youtube:


    Download: BR-TV Retroluzzer Theme Song




    Das zweite ist ein Zusammenschnitt von kurzen Ausschnitten verschiedener Hellcat-Streams:


    Youtube:



    Download: BR-TV Hellcat

  • Ich möchte an dieser Stelle mal mein Spaß-Projekt vorstellen, dass den BR-TV-Player "missbraucht", um einen Musikplayer ähnlich Winamp auf dem Bildschirm vorzutäuschen.


    Das ganze habe ich BReadAMP genannt: eine Mischung aus "BR-AMP" (Musik mit schlechtem Empfang) und Breadbox Player (Player, der auf einem "Brotkasten" läuft).


    Der bei BReadAMP gezeigte Player kann nicht durch Tastenbedienungen beeinflusst werden (ausser Wiedergabeabbruch mit RESTORE) da er nur ein BR-TV-Video mit einer Bildrate von 1 Bild pro Sekunde ist.


    Die Tonqualität von BReadAMP ist nicht wirklich gut, was vorallem daran liegt, dass BR-TV eigentlich ein Videoplayer ist und die Bildausgabe aktiviert ist, wodurch u.a. auch Störgeräusche vom VIC entstehen. Andere Sampleplayer bieten zwar eine bessere Tonqualität, zeigen dafür aber keinen "Player" an, sondern nur einen schwarzen Bildschirm oder bunte Streifen.


    BReadAMP-Dateien werden mit dem gleichnahmigen PC-Programm BReadAMP erstellt: hierzu zieht man eine oder mehrere wav-Dateien auf die BReadAMP_vxx.exe und folgt den Bildschirmanweisungen (diese erklären wie man die wav-Dateien mit Audacity konvertieren muss, damit sie von BReadAMP verarbeitet werden können und bieten verschiedene Optionen für die Konvertierung).


    Als Ergebnis der Konvertierung erhält man die Datei BReadAMP.reu. Diese wird im Verzeichnis abgelegt, in dem die wav-Dateien liegen. Die Datei kann mit einem Emulator oder am echten C64 mit 16 MB REU - Erweiterung (z.B. 1541ultimate oder Turbo Chameleon 64) mit Hilfe des BR-TV-Players abgespielt werden. Ist man mit dem Ergebnis zufrieden, sollte man die Datei umbenennen, um ein Überschreiben bei der nächsten Konvertierung zu vermeiden.


    BReadAMP unterstützt Sampleraten von 3,5 bis 51 kHz. Es wird abhaengig von der Spielzeit und Sampleraten der wav-Dateien automatisch die passende Samplerate fuer die BReadAMP-Datei ausgewaehlt, damit die Musik samt "Player" in die 16 MB grosse *.reu-Datei bei maximal möglicher Tonqualität passt.


    Die maximale Spielzeit beträgt ca. 61 Minuten bei sehr schlechter Qualität. Empfohlen werden Spielzeiten von 10 bis 20 Minuten, um eine akzeptable Tonqualität zu erreichen.


    Hinweise:
    -Bei der Wahl der Konvertierungsart (64/128/256 lineare Werte), muss man ausprobieren, was besser klingt, das ist abhängig von der Art der zu konvertierenden Musik. Die Erfahrung hat aber gezeigt, dass bei stark ausgesteuerter Musik die 256 lineare meist am besten klingen, da hierbei 64/128 lineare Werte zum Clipping führen, bei mittelstark ausgesteuerter Musik klingen die 128 linaeren Werte meist am besten und bei leiser Musik die 64 linearen Werte (bei kleineren Werten wird die Lautstärke höher und man hat weniger Rauschen).
    -Das programm rundet die Tracklänge technisch bedingt auf volle Sekunden und füllt den überschüssigen Bereich mit Stille. Möchte man erreichen, dass ein Track in den nächsten ohne Pause übergeht, muss man die wav-Dateien so schneiden, dass sie exakt xxx,00000 Sekunden lang sind. Dadurch wird beim Konvertieren keine Stille eingefügt.
    -BReadAMP unterstützt bis zu 14 Tracks, wobei bei 13 oder 14 Tracks die Infozeile aus Platzgründen entfällt.
    -Die Datei infobar.txt enthält die Texte der Infozeile und deren Anzeigedauer, welche durch Bearbeitung der Datei vor der Konvertierung geändert werden können. Hinweise dazu befinden sich in der Datei selbst.
    -Die Datei infobar_standard.txt enthält die Standardtexte und -einstellungen. Der Inhalt der Datei kann in die Datei infobar.txt kopiert werden, um den Standard wiederherzustellen.
    -In der Datei wavedelays.txt sind alle unterstützten Sampleraten und die jeweils zugehörigen Wave- und Spritedelays für den BR-TV-Player enthalten. Mit diesem Werten wird bei der Kovertierung die korrekte Abspielgeschwindigkeit der Musik festgelegt. Die Werte sollten nicht verändert werden, man kann jedoch bestimmte Samplefrequenzen von der Nutzung durch BReadAMP ausschließen, indem man die komplette Zeile löscht (falls man aus irgend einem Grund bestimmte Samplefrequenzen ausschließen möchte).
    -Die anderen Dateien sollten nicht verändert werden !
    -Die Datei BReadAMP_v01.bas enthält den Quellcode des Programms. Dieser kann mit der Entwicklungsumgebung qb64 geöffnet und bearbeitet oder mit einem Texteditor eingesehen werden.



    Den BReadAMP-Konverter kann man hier herunterladen: http://daddler-t-l.de/downloads/BR-TV-Tools/BReadAMP_v01.rar


    Die im unten angehängten Video gezeigte Demonstrationsdatei gibt es hier: http://daddler-t-l.de/downloads/C64_BR-TV/BReadAMP_Demo.rar


    So sieht das ganze auf dem C64 aus:


    (als Musik zur Demonstration von BReadAMP habe ich genommen: zwei Tracks von PC-Action-CDs - das waren meine ersten zwei mp3s, die ich je besessen habe, ein witziger Anti-C64-Song - bitte nicht böse nehmen..., ein lustiges Kinderlied zum Thema Zimmer aufräumen und den Song "Hey hey 16k", bei dem es um Heimcomputer geht)

  • So sieht das ganze auf dem C64 aus:

    8o Ganz großes Kino!! :thumbsup: Das gefällt mir, einfach klasse. :zustimm:

  • @daddlertl: Lol, geile Idee :thumbsup::hatsoff:


    Kurz ein-zwei Sachen dazu:
    Laut Player-Info zu jedem Frame ein Colorram gefetcht, sprich je einmal pro Sekunde holt er einen 1kb Colorram. Das dürfte aber vermutlich nicht stimmen. Beim Colorram lieber einen fixen Wert einstellen, zB. "$07 Hires". Dazu Colorfetch auf "Global" stellen, da sich nie die Farben ändern (was sie aber könnten, zB. bei jedem neuen Song).

    Du könntest auch noch einen "Unique Colorram" nutzen, der dann zB. den oberen Abschnitt rot anzeigt, den mittleren blau und die Scrollleiste weiß oder so ähnlich.


    Und ich weiß nicht, ob du auch in Assembler schreibst, aber:
    Du könntest eine eigene 2kb Routine einschmuggeln*, die dann den Timer hochzählt, ohne, dass dafür ein Frame gefetch werden müßte. Das wäre blitzschnell und würde das Playback quasi nicht stören. Auch könnte man in dieser Routine die Tastatur abfragen und alles "echt benutzbar" machen - wäre aber etwas aufwändiger.


    :)


    * Wenn man nämlich statt Wave auf SID stellt werden 2kb aus der REU nach $1000 kopiert und beim Start des Videos ausgeführt.

  • Ich möchte an dieser Stelle mal mein Spaß-Projekt vorstellen, dass den BR-TV-Player "missbraucht", um einen Musikplayer ähnlich Winamp auf dem Bildschirm vorzutäuschen.

    :thumbsup: mir gefällt so etwas auch :thumbup: danke

  • Laut Player-Info zu jedem Frame ein Colorram gefetcht, sprich je einmal pro Sekunde holt er einen 1kb Colorram. Das dürfte aber vermutlich nicht stimmen.

    Die Anmerkung ist korrekt, ich habe sie auch erwartet.


    Es gibt aber einen Grund dafür: stelle ich in der Datei an Adresse $000019 die Metadaten auf $0x (fixed color for entire video) oder auf $4x (unique global), dann führt er dies farbtechnisch auch korrekt aus, beginnt die Samplewiedergabe aber versetzt, d.h. es fehlen die ersten Sekunden vom Song. Dies ist um so schlimmer, je geringer die Samplerate ist, grob geschätzt überspringt er die erste REU-Bank.


    Dies führt auch dazu, dass dann die Track- und Zeitanzeige unsynchron zur Musik ist und man das ganze natürlich auch nicht durch Ändern der Delays synchronisiert bekommt, da ja die ersten Sekunden der Musik fehlen und nicht die Geschwindigkeit unkorrekt ist.


    Aus diesem Grund lasse ich den BReadAMP-Konverter die eigentlich falsche Einstellung vornehmen, weil dann die Musik korrekt von Anfang an gespielt wird.


    Merkwürdigerweise lässt sich der Fehler nicht reproduzieren, wenn man die falsche Einstellung manuell im Player auf die korrekte ändert, dann spielt er die Musik auch von Anfang an und führt auch die korrekte Farbeinstellung aus, d.h. der Fehler tritt nur auf, wenn man die korrekte Einstellungen in der Datei an der Stelle $000019 vorgenommen hat.


    Die Idee mit dem Einfärben hatte ich auch, wegen des o.g. Fehlers habe ich dies jedoch nicht umgesetzt.


    Assembler kann ich leider (noch) nicht, zumal für ein Reinschmuggeln von Tastaturroutinen auch genaue Kenntnisse des Players nötig wären (an welcher Stelle im Speicher steht, an welcher Position er gerade ist etc.).


    An der Stelle kam mir auch mal eine Erweiterungsidee für den Player: eine Kapitelliste, wo man eintragen kann, an welchen Speicherstellen in der REU bei jedem Kapitel die Bild- und Tonwiedergabe beginnt und wo man im Startmenü oder per Tastaturbedienung während der Wiedergabe (sofern die Tastaturabfrage die Wiedergabe nicht übermäßig stört) das Kapitel wählen kann. Das wäre auch bei Videos mit mehreren Clips (z.B. das mit den C64-Werbungen) nützlich, da man dadurch zu einem bestimmten Clip springen könnte und nicht das gesamte Video gucken und abwarten muss, bis der gewünschte Clip kommt.

  • Bei einem anderen BR-TV-Experiment bin ich auf eine weitere Grenze des Players gestoßen: ich habe ein Video mit 50 fps, also der maximalen Framerate erstellt und wollte, da Samplesound bei dieser hohen Framerate wegen die vielen Unterbrechungen nicht so gut klingt, SID-Musik einfügen.


    Dies habe ich auch hinbekommen, die SID-Musik spielte, jedoch lief das Video dann nicht mehr mit 50 fps, sondern deutlich langsamer, vermutlich mit 25 fps. Ich vermute, dass durch den SID-Player eine bestimmte Rasterzeile verpasst wird und er auf das nächste Frame wartet.


    Da das Video mit SID-Musik zu langsam lief, habe ich mich dann doch dazu entschieden, in die verbleibenden 300 KB der reu-Datei noch einen Sampletrack reinzuquetschen, damit das Video kein Stummfilm ist, was natürlich nicht so gut klingt, weil dadurch nur eine Samplerate von ca. 4 kHz möglich ist und durch die hohe Framerate der Ton oft unterbrochen wird.


    Hier das Video auf Youtube:


    Herunterladen kann man das BR-TV-Video hier: BR-TV Bobbahn Visegrád

  • Das erste Problem steht, glaube ich, schon im Readme. Da hatte ich auch Probleme mit einem "verschluckten" Start der Wave Datei.


    Das zweite Probleme könnte in der Tat die SID-Routine sein, falls sie zu langsam ist. Ich hatte mit Goattracker probiert, evtl. aber nicht bei 50fps.


    Mal sehen, ob ich morgen am Rechner bin. Dass Problem 1 nur beim Reu-Header, aber nicht beim Editieren auftritt, ist vielleicht ein guter Hinweis...


    Ps: Vielleicht kannst du das entspr. Sidfile nochmal hier anhängen, dann kann ich's mal testen.

  • Hey guys, thanks for making this awesome video player ... hoping to receive more updates on this project.
    I came across interesting video the other day, it's show video like I've never seen it before on the C64. This looks amazing ... check it out.


    Commodore 64 video capture

    [External Media: https://youtu.be/dvv6Uwdl0eY]


    This guy is from Italy, and the project is described in detail with schematics and all this Italian site, you must use a website translator to read in your language.
    http://ready64.org/articoli/le…2hiA2v5ETddnL50fFkAkBptFo


    Can this hardware be replicated, I just love the look of it.


    Sajtron