BREADAMP - ein "Winamp" für den C64 [1541u / TC64]

Der Bühnenmensch bin ich eher nicht, aber wer sich für das Programm interessiert, kann mich gern an meinem Platz dazu ausfragen und sich das Programm + Musikfiles bei mir auf einen USB-Stick kopieren, um es am eigenen C64 mit 1541u zu benutzen. Ich werde das sicher regelmäßig benutzen und an meinem Platz ein bisschen Musik hören, dafür habe ich mir das Programm ja zusammengebastelt.

Nach einigen Wochen Programmierarbeit ist es nun soweit: BREADAMP v03 ist fertig !

Hier kann man sie herunterladen: von meinem Webspace oder von der CSDB

Diese neue Version bietet folgende neue Funktionen:

- Stereo-Unterstützung für C64 mit 2 SIDs oder FPGASID (zweiter SID muss auf Speicheradresse $D500 liegen, wird beim FPGASID automatisch eingestellt)- Longplayformate, die eine geringere Tonqualität, aber deutlich längere Spielzeit bieten (bis zu 97 Minuten und 44 Sekunden)

- automatische Konfiguration bei Nutzung eines FPGASIDs, dieser kann alle Dateien abspielen, egal für welchen SID sie erstellt wurden

- NTSC-Unterstützung (NTSC-C64 mit "neuen" VIC, der Player funktioniert aber auch mit dem "alten" VIC, da er dafür nicht optimiert ist, ist dann aber die Tonqualität geringer)

- Möglichkeit die Abspielreihenfolge der Titel zu ändern

- Steuerung mittels Joystick(s)

- Formatanzeige, die Informationen über die Datei gibt (SID-Typ, TV-Norm, FPGASID-Modus)

- Rahmen-, Hintergrund und Textfarbe kann geändert werden

- "Diskomodus", bei dem beim Abspielen jede Sekunde die Rahmen- und / oder Hintergrundfarbe gewechselt wird

- erweiterte Fehlererkennung (falsche TV-Norm / Gerätetyp und Datei für FPGASID, aber kein FPGASID eingebaut)

- Rückwärtskompatibilität: der Player spielt auch Dateien der v02

Sollte jemand einen Bug entdecken, bitte melden. Aufgrund der Komplexität, die das Programm mittlerweile erreicht hat (ca. 3000 Assembler-Befehle), können sich immer mal Bugs einschleichen, ich habe die letzten Tage noch einige entdeckt und gefixt, die nur unter ganz bestimmten Umständen aufgetreten und somit nur durch Zufall zu finden sind.

In zukünftigen Versionen habe ich noch geplant:

- Trackrepeatfunktion (wollte ich eigentlich schon in dieser Version machen, habe ich aber vergessen, da es nicht so wichtig ist, habe ich es auch nicht noch "schnell reingepatcht")

- Aufnahmefunktion für C64er mit FPGASID (der FPGASID hat einen Audio IN mit dem man samplen kann)

- eventuell weitere Funktionen

Die Erstellung von eigenen Musikdateien mit dem BREADAMP_v03_REUmaker wurde auch vereinfacht:

Als Eingabedateien dienen nun wav-Dateien, die mit den für den Konverter nötigen Parametern mit Hilfe von Audacity erstellt wurden. Dadurch entfällt bei der Verwendung von mp3-, ogg- oder flac-Dateien der Zwischenschritt über die Konvertierung in eine "normale" wav-Datei und man kann seine Musik direkt in das benötigte wav-Format konvertieren.

Durch die Verwendung des wav-Formats haben die konvertierten Dateien einen Header, der zum einen das Abspielen in einem normalen Audioplayer wie Winamp ermöglicht (zwecks Kontrolle) und zum anderen vom REUmaker ausgewertet werden kann, der bei Unstimmigkeiten (z.B. nicht unterstützte Samplerate) die Datei beanstandet, wodurch einige Fehler schon beim Konvertieren und nicht erst beim Anhören erkannt werden können.

Wie man eigene Musikdateien erstellen kann, welche Tonformate mit welchen Spielzeiten unterstützt werden und weitere Informationen zum Player findet man in der im Archiv enthaltenen Dokumentation.

Hier der Player in Aktion in Form zweier Youtube-Videos:

Der Player mit den Standardabspielmethoden 8 Bit Mahoney und 4 Bit "classic":

Die Samplewiedergabemethode, die nur auf einem FPGASID funktioniert, indem dessen "Digifixregister" benutzt wird:

Mir wurde gemeldet, dass es momentan Probleme mit dem Download gibt. Dies liegt vermutlich an einem DNS-Eintrag, der noch auf den alten Webspace zeigt.

Wer Probleme mit dem Download hat, kann diesen Alternativlink nutzen: http://w244471.virtualuser.de/c64/BREADAMPv03+Demofile.rar

@Squidward An eine On-the-fly-Konvertierung hatte ich auch gedacht - das Problem sind die verfügbaren Takte, insbesondere in den Bad Lines des VIC, da werden einem nämlich von den 63 Takten der Zeile mindestens 40 vom VIC "geklaut", d.h. man hat an diesen Stellen maximal 23 Takte übrig, meist weniger (hängt davon ab, welcher Befehl im Moment des IRQ ausgeführt wird). Problematisch sind also 2 aufeinanderfolgende Samples von denen einer vor und einer nach der Bad Line gespielt werden muss.

Der Player-IRQ macht das beim Abspielen eines Samples:

-Akku auf Stack sichern (nötig, weil er zum Senden des REU-Kommandos gebraucht wird)

-IRQ bestätigen

-per REU-Kommando das Sample in den SID schieben lassen (braucht 2+4+1 = 7 Takte) ***

-Adresse (Lo) der REU um 1 erhöhen

-wenn nicht 0, dann zum Ende gehen

-sonst die (Hi)-Adresse der REU und ggf. auch noch die REU-Bank erhöhen (letzteres braucht eine Hilfsvariable, weil direktes Erhöhen den REU-Wraparound-Bug auslöst)

-am Ende Akku vom Stack zurück holen und IRQ verlassen

In Summe verbraucht man dabei schon ca. 32 Takte (oder mehr, wenn die Hi-Adresse und evtl. sogar die Bank erhöht werden muss), d.h. ein paar Samples bekommen schon einen "Bad Line - Treffer" und werden dadurch etwas verzögert, aber wesentlich weniger als wenn man die Bad Lines gar nicht beachtet. Ich habe durch Hörtests ausprobiert, an welcher "X-Kordinate" des Rasterstrahls man den IRQ am besten starten lässt und den Wert genommen, der sich für mich am besten angehört hat.

*** Würde man jetzt noch eine On-the-fly-Konvertierung durchführen bräuchte man folgendes:

-per REU-Kommando das Sample in eine Variable in der Zeropage schieben lassen (braucht auch 7 Takte)

-die Variable (Samplewert) ins X-Register laden (3 Takte)

-den Mahoneywert x-referenziert aus der Lookuptabelle holen (4 Takte)

-den Mahoneywert in den SID schieben (4 Takte)

--> d.h. das ganze würde 17 Takte brauchen, also nochmal 10 mehr wie beim direkten Schreiben der Mahoney-Werte, somit wäre der Jitter im Bereich der Bad Lines deutlich größer und das ganze würde zumindest bei 15,6 kHz nicht mehr gut klingen (bei den geringeren Sampleraten würde es sicher funktionieren, aber bei Stereo hätte man kaum eine Chance einen vernünftigen Klang hinzubekommen)

Der Quellcode des Programms liegt im Archiv vor, wer eine Idee hat, wie man eine On-the-fly-Konvertierung bei vernünftigen Klang hinbekommt, kann das Programm gern modifizieren. Dies ist mein erstes größeres Assemblerprojekt, d.h. ich kenne ganz sicher nicht alle "Szenetricks" für maximalen Speed und maximale Präzision, aber vielleicht kennt ja jemand eine Möglichkeit wie man das ausreichend schnell hinbekommen kann.

Das ist auch der Grund, warum ich den Quellcode beilege: damit interessierte Programmierer ihre Ideen am Programm ausprobieren oder das Programm an eigene Bedürfnisse anpassen können (auf Facebook meinte z.B. jemand, dass er gern eine andere Schriftart für die Texte hätte, da konnte ich ihm mitteilen, dass er gern eine eigene Schriftart einfügen kann, was recht einfach ist, weil auch das verwendete Charset im Archiv liegt -> man kann es mit einem Charset-Editor, z.B. Charpad, bearbeiten und anschließend das Programm neu kompilieren - dabei wird dann das geänderte Charset ins Programm integriert).

Aufgrund der Bad Line - Problematik habe ich die maximale unterstützte Samplerate auf 15638 Hz (=Zeilenfrequenz des VIC) festgelegt, weil mehr bei eingeschalteter Bildausgabe einfach keinen Sinn macht (bei 44,1 kHz hat man pro Sample nur 22 Takte, d.h. eine Bad Line "frisst" 2 komplette Samples und das hört man sehr deutlich, weswegen ich eine Samplewiedergabe bei Zeilenfrequenz wesentlich angenehmer empfinde, als eine von Bad Lines zerhackte 44,1 kHz - Wiedergabe. Bei der Entwicklung des Players war mein oberstes Ziel eine möglichst gute Wiedergabequalität bei eingeschalter Bildschirmausgabe zu erzielen (aufgrund der technischen Limitierungen erreicht man damit natürlich keine Bose-Qualität, aber für den Zweck für den ich den Player programmiert habe, nämlich auf Retropartys Musik mit dem C64 hören zu können, reicht mir die Tonqualität).

Mir ist gerade eine Idee gekommen, wie ich noch mehr Takte sparen kann, wenn ich das gesamte Programm so umbaue, dass ein Register (z.B. y) immer frei bleibt (ist natürlich eine Menge Arbeit):

-den IRQ nicht mit lda $dd0d, sondern mit bit $dd0d bestätigen (das gilt auch als Lesen, benutzt aber den Akku nicht)

-das freigehaltene Register statt dem Akku zu benutzen, um der REU das Kommando zu geben -> da dieses vom Hauptprogramm nicht mehr geändert werden soll, braucht nicht jedes mal der Wert reingeladen werden -> spart 2 Takte, so wie du geschrieben hast

-da der Akku nicht mehr benutzt wird, können die Befehle pha und pla entfallen, somit werden weitere 3 + 4 = 7 Takte eingespart

In Summe werden also 9 Takte pro Sample eingespart, macht bei einer Samplerate von 15638 Hz eine Ersparnis von 140742 Takten pro Sekunde, d.h. es werden 14,2% CPU-Last eingespart, die dann das Frontend noch schneller machen (es ist jetzt schon rasant schnell mit ca. 100 fps bei 15,6 kHz Mono), aber vor allem den Samplejitter im Bereich der Badlines verringert, was für einen etwas besseren Klang sorgen könnte (zumindest theoretisch, ob man wirklich einen Unterschied hört, wird sich dann zeigen). Erstmal brauche ich eine Weile Pause, aber wenn ich wieder Lust drauf habe und die großen Retropartys vorbei sind, werde ich das sicher mal ausprobieren.

Das einzige, wo ich in der Playerschleife ein Register bräuchte, wäre beim Umschalten der REU-Bank, weil ich die in einer Variable verwalten muss (das direkte Inkrementieren der REU-Bank löst leider den REU-Wraparound-Bug aus), somit müsste ich das "reservierte" Register kurz benutzen und anschließend wieder auf 253 setzen, kostet 2 Takte mehr, aber nur alle 65536 Samples, also ca. alle 4 Sekunden bei höchster Qualitätsstufe.

Die eingesparten Takte lassen sich nicht für "On-the-Fly-Konvertierung nutzen", da man dafür ja wieder die Register bräuchte, aber eben zur Verringerung des Samplejitters.

Momentan nutze ich tatsächlich nur die oberen 128 Zeichen, das kann sich in den nächsten Versionen aber ändern (wird es wahrscheinlich auch, weil wirklich alle oberen 128 Zeichen verbraucht sind, und für neue Features dann auch unwichtige Zeichen im oberen Bereich benutzt werden müssen).

Ich habe mal auf die Schnelle was zusammengehackt, sodass die unteren 128 Zeichen aus dem Systemrom und die oberen aus meinem Custom-Charset geladen werden. Ich habe mir mal auf die Todoliste für die nächste Version geschrieben, dass auch da alle unveränderten Zeichen aus dem Systemrom geladen werden sollen.

Hier mal ein Screenshot, wie es jetzt aussieht: links Standardfont, rechts Alternativfont:

Im Anhang die veränderte Version. Dies ist keine offizielle Releaseversion, sondern ein schnell zusammengebasteltes Proof-of-Concept. Ich habe auch nur einen Schnelltest gemacht, ob mir Fehler auffallen, scheint soweit ok zu sein.