Posts by daddlertl

Mir war das mit den fehlenden Leerzeichen auf der DoReCo-Party aufgefallen, weil diverse Bugs auftraten (verschobene Kartendarstellung, zu geringer Abstand der $-Werte im Betting-Screen, wenn man verloren hat, ist die Anzeige $0 2 Zeichen zu weit links, vermutlich Grafikfehler beim Verschieben der Chips beim Betting - die ersten 3 Bugs hatte ich gefixt, den 4ten nicht, das hatte ich mir für später vorgenommen, da er mich nicht so sehr gestört hat). Dank jahrelanger Basic-Erfahrung konnte ich die Fehlerstellen (sowohl von selbst gemachten Tippfehlern als auch von fehlenden Leerzeichen schnell finden), weil ich den Programmcode beim Eintippen weitestgehend verstanden habe und so wusste, wo ich nach den Fehlern suchen musste.

Mir reicht eine gepostete Korrektur aus, die ich mir ausdrucken und dem Listing beilegen kann, aufwändiger Versand ist dafür nicht nötig.

Anbei mal vier Bilder, die ich auf der DoReCo-Party nach Erfolgreichem Abtippen für mein Nuvie gemacht habe (das dritte zeigt eine kleine "Programmerweiterung", die ich am Ende gemacht habe, so nach dem Motto "Juhu, ich hab die drei Seiten geschafft" und Nummer vier zeigt, wer der wahre Dealer ist :P).

Ich habe mal eine Anpassung am wave-Parser vorgenommen, sodass der Datenblock (data) der Wavedatei auch bei vorgelagertem LIST-Feld korrekt erkannt wird.

Erklärung des Fehlers: In den Beschreibung zum Wave-Format, die ich im Netz gefunden habe, steht, dass das erste Feld immer "data" ist, weshalb ich das auch nicht extra überprüfen lassen habe. Da FFMPEG sich offenbar nicht an den Standart hält, wurde von meinem Programm das LIST-Feld als Datenblock gelesen, weshalb auch eine "Musiklaenge" von nur 112 Bytes angegeben wurde, was der Länge des LIST-Felds entspricht. Die angepasste Version überprüft nun den Feldname und wenn der nicht "data" ist, wird zum nächsten Feld gesprungen und der Name auf "data" überprüft.

Natürlich ist auch das kein Garant, dass Wave-Dateien von allen Konvertern funktionieren, denn man weiß nie, was manche Konverter noch für obskure Standartabweichungen machen. Die angepasste Version "versteht" jetzt mindestens Audacity- und FFMPEG-Wave-Dateien. Ich konnte damit deine beiden Testdateien konvertieren und das Ergebnis mit Breadamp abspielen.

vorher:

gefixte Version:

Probiere mal diese Version aus: BREADAMP_v03_REUmaker_ffmpeg_fixed.rar

@andi6510 Ich kann dir gern vor Ort das Programm genauer vorführen und zeigen, wie man Audiofiles konvertiert (das ist schnell erklärt).

Im Prinzip liese sich eine Unterstützung einbauen, wahrscheinlich sogar recht einfach. Dazu müsste man aber wissen, an welche Adresse die Samples geschoben werden und in welchem Format sie sein müssen (ich vermute mal unsigned integer 8 bit)

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.

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.

@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 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

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:

Danke für den tollen Ausflug !

Ich habe meine Aufnahmen des ESA-Besuchs, das von bytequest gepostete Gruppenfoto sowie eine Slideshow mit Bildern vorhergehender Stammtische als "Zeitreise" zu einem Nuvie (Video, das auf einem Commodore 64 mit 1541ultimate abgespielt werden kann) verarbeitet:

Quote from detlef

Quote from daddlertl

In Basic: RF = PEEK(53280) : RF = RF + 1 : POKE 53280,RF (der erste Befehl kann entfallen, wenn man die Rahmenfarbe bereits in der Variable RF gespeichert hat)

In Assembler: inc $D020

Warum kann man da nicht einfach POKE53280, PEEK(53280)+1 schreiben?

Stimmt, so gehts natürlich auch ohne Variablen. Eines muss man aber trotzdem beachten, egal ob mit oder ohne Variable: bei Basic darf der zu pokende Wert nicht größer als 255 werden, sonst gibt es eine Fehlermeldung, bei Assembler rollt das dann einfach auf 0 über, was man mittels Flags auswerten kann, wenn es wichtig ist den Überlauf zu detektieren. Wenn es nicht wichtig ist, braucht man gar nichts weiter zu machen.

Ich habe mich auch lange vor Assembler gesträubt, habe aber vor kurzem damit begonnen, weil Basic für viele Sachen einfach viel zu langsam ist, z.B. für einen Samplemusikplayer. Grund dafür ist, dass Basic eine Interpretersprache ist, der Computer also zur Laufzeit des Programms erst jeden Befehl in Echtzeit in für den Prozessor verständliche Kommandos umwandeln muss. Bei einem Assembler wird dies bei der Erstellung der ausführbaren Datei erledigt und der Prozessor bekommt zur Laufzeit direkt die für ihn verständlichen Kommandos in Maschinensprache geliefert.

Anfangs ist es tatsächlich gewöhnungsbedürftig, da das Basic vom C64 ziemlich beschränkt ist und man bei Sound- und Bildausgabesachen viel mit "Poke-Orgien" machen muss, ist der Umstieg auf Assembler gar nicht so schwierig. Manche Sachen gehen in Assembler sogar einfacher, ein simples Beispiel: Rahmenfarbe um 1 erhöhen, wenn diese noch nicht in einer Variablen gespeichert ist:

In Basic: RF = PEEK(53280) : RF = RF + 1 : POKE 53280,RF (der erste Befehl kann entfallen, wenn man die Rahmenfarbe bereits in der Variable RF gespeichert hat)

In Assembler: inc $D020

An diesem Beispiel sieht man auch, dass manche Sachen in Assembler sogar ohne die Nutzung von Variablen funktionieren, indem man direkt auf die Hardwareregister zugreift.

Ein Assembler hat den Vorteil, dass man auch dort Adressen Variablen zuweisen und Sprungmarken setzen kann, es wird einem also einiges von der Speicherverwaltung abgenommen, man muss nicht alles "bare metal" programmieren.

Als Hilfen, um Assembler zu lernen habe ich folgendende Internetseiten zurückgegriffen:

https://www.retro-programming.de/ - dort gibt es viele Tutorials, von einfachen Anfängerprogrammen bis hin zu komplizierten Themen wie Rasterzeileninterrupts

https://codebase64.org/doku.php - dort sind viele Beispielprogramme, z.B. für mathematische Aufgaben (die sind in Assembler tatsächlich komplizierter als in Basic)

https://www.c64-wiki.de/wiki/%…cht_6502-Assemblerbefehle - Liste aller Assemblerbefehle, man kann jeden Befehl anklicken und es wird ausführlich seine Funktion erläutert

Am besten man lädt sich mal einen Assembler herunter, z.B. das C64-Studio und fängt einfach mal an anhand der Tutorials im Netz einfache Programme zu schreiben, z.B. solche, die den Bildschirmspeicher ab $0400 verändern, da hat man dann auch gleich die optische Rückmeldung, ob der Computer das macht was man wollte. So habe ich auch angefangen in Assembler zu programmieren.

Ich habe einen Standard-C64C, also keine Erweiterungen drin (außer Bluetooth, das sollte aber keine Helligkeitsschwankungen abhängig vom Bildinhalt verursachen). Die Helligkeitsschwankungen treten sowohl beim direkten Betrieb am Monitor als auch beim Betrieb an einem HDMI-Recorder auf. Am Display dürfte das nicht liegen, da ich im normalen PC-Betrieb solche Schwankungen nicht gesehen habe, außerdem sind die Schwankungen auch in den Aufnahmen des HDMI-Recorders zu sehen, z.B. in dieser Nuvie-Aufnahme. Firmwareupdate hat auch bei mir nichts geändert (habs ohne Einstellungen zu sichern gemacht und bin anschließend alle Einstellungen durchgegangen in der Hoffnung den Übeltäter zu finden, leider erfolglos, hab nichts in Richtung automatische Helligkeitskorrektur gefunden und auch alle möglichen Einstellungen variiert ohne Erfolg). Vielleicht schwankt die Helligkeit auch bei manchen VICs

Mein Framemeister macht das auch mit der schwankenden Helligkeit, ich habe leider auch keine Einstellung dafür gefunden.

Firmware ist ein guter Hinweis, bei meinem ist glaube ich die 2.00 drauf, im Netz habe ich eine 2.04E gefunden. Da werde ich mal ein Update machen, wenn ich dazu komme.

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.

Ich nenne diese Gegner immer "Mini-Trumps".

Wir haben den Fehler gefunden, es waren gleich 2: 1. es wurde 8 Bit signed statt 8 Bit unsigned ausgewählt, 2. aus irgendeinem Grund hat sein Audacity die Projektfrequenz beim Exportieren nicht berücksichtigt. Es lag also an der Knvertierung von *.wav zu *.raw/*.aiff.

Quote from Ebster

Wäre diese geniale Software nicht etwas für die Doreco Bühne?

Wie meinst du das genau ?

Ich hab dir mal eine PN geschickt mit einer von mir konvertierten Breadamp-Datei mit dem Lied, da kannst du mal testen, ob meine Konvertierung besser klingt.

Ob die Konvertierung von mp3 nach wav fehlerfrei war, kannst du einfach testen, indem du die wav-Datei abspielst. Wenn die fehlerfrei klingt, liegt es schonmal nicht an diesem Schritt.

Mit v03 wird auch die Konvertierung von mp3s leichter: da kann man dann alles in einem Rutsch mit Audacity machen ohne den Zwischenschritt (man konvertiert dann die gewünschten Titel direkt nach *.aiff, aber dann mit Header und zieht diese auf den Konverter, das hat auch den Vorteil das man die *.aiff-Dateien mit Winamp vorhören kann, das geht momentan nicht, da die Dateien jetzt ohne Header gespeichert werden und damit kein normales Musikabspielprogramm das abspielen kann).

Was noch zu prüfen wäre: ist der Ton gut ausgesteuert ? (die blaue Wellenform sollte nahe an den oberen und unteren Rand herankommen) Wenn nicht: vor dem Exportieren Effekt -> Normalisieren oder Effekt -> Kompressor anwenden.

Bei zu geringer Aussteuerung steigt das Quantisierungsrauschen, da dann die 8 Bit nicht mehr vollständig ausgenutzt werden.

Schreib mir mal (gern auch per PN), welchen Song du konvertiert hast, dann kann ich es selbst mal probieren. Es gibt auch ein paar Songs, die sich nicht perfekt konvertieren lassen und zu verstärktem Rauschen neigen, habe ich selbst schon festgestellt.

OK, wenn die Demodatei korrekt abgespielt wird, liegt es an der Konvertierung

Hier eine bebilderte Anleitung zur Konvertierung von Wave-Dateien für Breadamp v02 (bei v03 wird der Ablauf anders sein) :

1. hat man einen Stereosong, muss man ihn zuerst in Mono umwandeln:

2. nun legt man als Projektfrequenz 15638 Hz fest (links unten, mit Numpad eingeben) :

3. Datei -> Ton exportieren ...:

Im Speicherdialog den Dateiname unverändert lassen, aber das Verzeichnis angeben, in der die Original-wav-Datei liegt, folgende Einstellungen vornehmen und speichern:

Bei der Erstellung der Anleitung habe ich die Audacity-Version 2.1.2 verwendet, bei anderen Versionen können die Menüs anders angeordnet oder beschriftet sein und es kann sein, dass das Programm die Endung *.raw statt *.aiff verwendet.

Ich habe die Anleitung auch verifiziert, indem ich die in der Anleitung gezeigte Datei mit den angegebenen Schritten konvertiert habe.