Das mit den verschiedenen Pattern hebe ich mir dann doch besser für eine "Vollversion" des Players auf. Für eine "Machbarkeitsstudie" halte ich das dann doch für übertrieben.
Nochmals Danke an alle für die guten Tips.
Gruß WTE
Das mit den verschiedenen Pattern hebe ich mir dann doch besser für eine "Vollversion" des Players auf. Für eine "Machbarkeitsstudie" halte ich das dann doch für übertrieben.
Nochmals Danke an alle für die guten Tips.
Gruß WTE
Das ROM macht beim Reset einen nichtdestruktiven Speichertest - sonst würde ja beispielsweise ein "OLD" nach einem Reset nicht funktionieren.
Stimmt, das hatte ich irgendwie völlig ausgeblendet.
Der von dir festgestellte Unterschied in den Anfangswerten liegt an den verbauten Rams, je nach Grösse und Hersteller finden sich nach dem Einschalten andere Werte darin.
Ok, dann ist das ja "sehr verläßlich" dort im RAM auf Nullen zu hoffen wo das SID-File sie erwartet
. Hmm, da fällt mir ein, dass mein C128 jeweils inmitten der $ff ein einsames $00 anzeigte. Der Wert läßt sich mit $ff überschreiben und bleibt auch stabil. Kann man das erklären oder darf ich die RAMs als defekt ansehen und muss sie austauschen?
Gruß WTE
Danke für die Hilfestellungen, aber es war ein total blödes Speicherinitialisierungsproblem. Genau genommen ein entweder schlecht programmiertes SID oder schlecht geripptes/gespeichertes SID-File. Damit vielleicht kein Einzel- aber immerhin ein Sonderfall. Die Besonderheit, dass es mit dem EMU geht und einem echten Rechner nicht, habe ich jetzt auch geklärt. Man, man, Sachen gibts. Doch der Reihe nach.
Das problematische SID-File liegt bis $1a0d im RAM. Ich habe ermitteln können, dass in den Speicherstellen $1a1e und $1a1f, also hinter dem SID, gewisse Inhalte problematisch sind. Steht hier $00 klingt es "normal" einige andere Werte gehen auch. Bei anderen z.B. pfeift bzw. rumpelt es; $ff und $aa ergeben solche Probleme. Die Werte in der Nähe haben vemutlich ebenfalls gewissen Einfluß, das ließ sich jetzt nicht im Einzelfall verifizieren und hängt wohl von den Werten in den zuerstgenannten Speicherstellen ab. Wirklich kritisch sind jedoch vor allem die beiden genannten Stellen.
Der kritische Bereich hinter dem geladenen SID geht also mindestens bis $1a1f. Hier stehen ggf. Reste eines zuvor geladenen Tunes. Wie ich feststellen konnte, wird dieser Speicherbereich beim Abspielen nicht beschrieben, dient also nicht als Puffer. Sein Einfluß kann also nur darin bestehen, dass dieser Bereich ausgelesen wird. Entweder irrtümlich (schlecht programmiert) oder absichtlich (schlecht gerippt). Im letzteren Fall stellt sich die Frage, was hier eigentlich für Werte stehen sollten. Nullen sind ja nun wirklich einfacher als Vorgabewerte zu gewinnen, da braucht es keinen Zugriff auf undefinierten Speicherinhalt.
1. Ergebnis: Das SID-File ist unvollständig, es hätte die erforderlichen Bytes mit beinhalten müssen, dann gäbe es kein Problem.
C64: Auf einem "sauberen" C64 spielt das SID "ordentlich". Das liegt daran, dass der C64 den Speicher Blockweise initialisiert. 64 Bytes $00 und dann wieder 64 Bytes $ff. Von $1a00 bis $1a3f liegt zum Glück ein $00-Block. Damit alles fein auf einem nackten C64. Wobei ich nicht weiß, ob jeder C64 so initialisiert.
VICE X128: Im VICE-Emulator wird der Speicher wie beim C64 initialisiert. Deshalb funktionierte mein SID-Player auch mit diesem speziellen SID tadellos.
C128: Auf echter Hardware gab es die angesprochenen Probleme. Auch der C128 initialisiert mit $00 und $ff. Zuerst dachte ich daher, mein Problem könne etwas mit der SuperCPU zu tun haben, die (nur) mit $AA initialisiert. Und tatsächlich klingt der SID (nur der) mit SuperCPU schräg. Und dann habe ich festgestellt, das mein C128 (ohne SuperCPU) zwar mit $00 und $ff initialisiert, das aber in 256-Byte-Blöcken macht. von $1980 bis $1a7f steht daher $ff im RAM! Anders als im EMU und anders als beim C64.
2. Ergebnis: entweder initialisiert VICE den Speicher "falsch" oder es gibt verschiedene ROM-Versionen mit unterschiedlichen Initialisierungen beim C128 und ich habe gerade die unpassende.
Da nach dem Laden eines SID Speichermüll zurückbleibt, füllte das zu Anfangs im Thread beschriebene SID B den fraglichen Speicherbereich mit Werten <$20 und machte damit das problematische SID-File (SID A) spielbar. Ich habe dann noch ein anderes SID-File (SID C) gefunden, das genau den gegenteiligen Effekt hat. Es füllt den fraglichen Speicherbereich mit Daten > $60. Danach rumpelt SID A wieder (ach wie schön, jetzt kann ich das Rumpeln an- und ausschalten).
Fazit: Ich muss den gesamten "unbenutzten" Speicher zuvor initzialisierten. Am besten mit 64-Byte-Blöcken wie beim C64. So ein Dreck!
Na, immerhin ist das Mysterium gelöst.
Gruß
WTE
bei einem solchen player ist das vmtl auch keine gute idee... da der kernal eine ganze reihe zeropageadressen benutzt die ein tune eventuell auch nutzen will.
Naja, das restliche Programm will ja auch bedient werden, so mit Tastatureingaben z.B. Da ist ein "abgebrochener" Interrupt keine gute Idee ![]()
Die ZP ist hier aber sicher, dank Bankswitching auf einem C128 steht sie allein der SID-Abspielroutine zur Verfügung.
Gruß WTE
Danke für die Hinweise.
SID-Register initialisieren ist ja schonmal ganz gut (Am besten einfach $D400-$D417 mit #$00 füllen). Allerdings brauchen gerade die Envelopes manchmal dann noch eine ganze Zeit, damit ein evtl noch laufender ADSR-Durchgang beendet wird. Also evtl noch ein paar Frames warten.
Warten kann nicht das Problem sein. Initialisiert wird immer. Also auch nach SID B findet SID A den gleichen Zustsnd bei den SID-Registern vor wie sonst auch. Und wenn ich 2 x SID A spiele, rumpelt es sowohl beim ersten als auch beim zweiten Mal.
Noch was fällt mir ein aus TheRyk's Fehlerkiste (vor einem gutem Jahr): Beendest Du etwaige IRQs korrekt? Wenn die Abspielroutine in einer IRQ liegt würde ich diese sauber beenden, bevor ich wieder eine neue Musik-IRQ (bzw. die gleiche mit modifiziertem Inhalt bei self-modyfing code) aufrufe. Wenn IRQ2 aufgerufen wird, während IRQ1 noch irgendwo rumhampelt, kann es durchaus zu Missklängen kommen.
Da ich das ganze entwickle, um es auch in einem Spielchen zu benutzen wird der IRQ super sauber beendet. D.h. der normale Kernal-IRQ wird auch abgearbeitet.
Und NOCH was/Idee für Patch/Workaround: Du sagst, Du initialisierst ZP und SID. Vielleicht etwas abwegig, aber vielleicht wäre es einen Versuch wert, den Stack
a) auch mal zu initialisieren oder
b) mal ZP, STACK und SID Werte bei dem Fall zu sichern, in dem es geht (also nach dem Abspielen von Tune A). Entweder Du nimmst diese Werte einfach als neue Ini-Werte für die fraglichen Register oder Du studierst die mal genauer und schaust, ob/was auffällt.
zu a): habe ich bisher nicht gemacht, weil das natürlich Auswirkungen auf das Hauptprogramm hätte und ich dann in einer Endlosschleife hinge oder ins Nirwana zurückspränge.
zu b): SID-Werte sind erwiesenermaßen irrelevant, da diese ja zuvor immer neu initialisiert werden. ZP habe ich gesichert und verglichen und keine Veränderungen gefunden. Außerdem wird die ja sowieso auch jedesmal neu initialisiert auf Startwerte. Was ich nicht getestet habe ist der STACK. Eventuell versteckt sich da was im Low-Bereich ab $0100, der ist ja weitgehend "frei" und wird auch vom Betriebssystem mißbraucht.
Die richtige Reihenfolge beim Resetten der Register ist auch nicht ganz unwichtig. Ich hatte hier auch diese Rumpel-Effekte.
Also alles auf Null setzen und ganz zum Schluß nochmal die Waveformen auf 0 setzen.
Interessanter Aspekt. Da das Init bei mir aber immer auf die gleiche Weise gemacht wird kann es das auch nicht sein.
d418 auf 0 zu setzen ist keine gute idee
Das Register steht nach dem Init auch auf 15 (besser ist das!)
Ich werd' mal sehen, ob ich auf der HomeCon in der Sache weiterkomme.
Danke und Gruß
WTE
Mir hat damals das hier ganz gut geholfen, heißer Tipp von unserem anderen Groepaz
Faces - Music-Wizard
Danke für den Tip, das werde ich mal probieren.
Was RAM-Pattern angeht, ist ja der Witz, dass ich ja nur 1x SID B spielen muss und schon läuft SID A sauber. Neu initialisiert wird zwischen jedem SID (wie oben angegeben: ZP & SID-Chip) sonstiger Speichermüll wird aber nicht bereinigt. X und Y-Reg sind auch jedesmal beim Aufruf von SID A identisch, daran kann es also auch nicht liegen. Vielleicht doch nur irgendein Speicherbereich, der einfach <> 0 sein muss oder so'n seltsamer Kram.
Sonst läuft ja > 80%. RSID allerdings nicht und auch solche nicht, wo der Interrupt mit $0000 (Dummy-Wert) angegeben wird.
Gruß WTE
Ich habe ein kleines Problem mit meinem selbstgebasteltem SID-Player. Die SID-Register werden vor jedem Tune vorsichtshalber vorher alle auf Null initialisiert, die "Zeropage" in den Startzustand des C64 versetzt (0002-00ff, 0200-03ff). Trotzdem habe ich folgendes Problem:
Abspielen von SID A: Sound mit gerumpel (abnehmend, aber nicht verschwindend)
Abspielen von SID B: sauberer Sound
Abspielen von SID A: sauberer Sound
Irgendwie werden vom SID B Daten? Register? Ports? gesetzt, die SID A "gut gebrauchen" kann. Da fragt man sich, wieso SID A das nicht alles selber initialisiert. In einem SID-Player auf dem PC treten diese Probleme nicht auf.
Die Zeropage (s.o.) habe ich schon geprüft. Da gibt es keine Unterschiede, die das erklären könnten. Gibt es CIA-Register mit Einfluß? (Es ist kein PAL/NTSC-Problem!) Kann es was mit $00/01 zu tun haben? (ROM ist immer ausgeschaltet).
Mir sind die Ideen ausgegangen.
Gruß WTE