Posts by Lipti

    Beide Möglichkeiten sind ja auch valide Punkte. Jedoch fände ich persönlich es besser wenn SIDKick pico eher in der Emulation näher an die echten SIDs rückt, als wenn man ihn im Ultimate-II+ als Emulation erkennt. Schließlich hat man schon mit SYS 54333 ein eingebautes Konfigurationsmenü, welches für alle nicht-Ultimate-Nutzer eh drin bleiben müsste. Dann hätte man eine Dopplung der Konfiguration, sofern das auch im Ultimate-II+ möglich wäre. Da erkenne ich keinen wirklichen Mehrwert.


    Die Ultimate-II+ kam nur ins Spiel, weil mir dort aufgefallen ist, dass der SIDKick pico nur als "unknown" erkannt wird. Und da habe ich mich gefragt, ob man auch den Teil so emulieren könnte, dass die Erkennung den eingestellten SID-Typ ohne Anpassung der Ultimate-II+ erkennt.

    Nun ja, die Routine des SID-Players kann man auch ohne Ultimate ausführen und testen, man braucht nur den zu testenden SID-Ersatz.

    Könnte für Frenetic dann noch einfacher sein als für die ersten Versuche immer auf mein Testfeedback zu warten :) Dennoch übernehme ich dann gerne den Test dann mit der Ultimate-II+...

    In 99,9% der Fälle braucht man es nicht (das einfache Recovery). Aber wenn beim Erstellen der Firmware oder beim Update was schiefgeht, dann freut man sich, dass man nicht per JTAG ran muss.

    Ist wie mit einer Versicherung, meistens braucht man die nicht - aber wenn doch, ist man froh, eine zu haben.

    Richtig, aber es wäre ja kein FW-Update der Ultimate II+ sondern des SIDKick pico.


    Frenetic : Mir ist nebenbei auch aufgefallen, dass die Konfiguration im Setup-Menü des SIDKick pico bei "x" gespeichert werden zu scheint? Worin besteht der Sinn von Laden und insb. Speichern der Konfiguration, wenn das auch beim Beenden des Menüs automatisch geschieht? Ich hatte vermutet, dass "x" den Chiptyp etc. zwar für die aktuelle Session umstellt, aber nach Neustart (bzw. Powerloss) die gespeicherte Einstellung wieder aktiv wird. Also im Sinne einer temporären Umstellung die beim nächsten Reboot wieder auf die gespeicherte Einstellung rückgestellt wird.

    Ultimate II+ ist für so etwas ideal, weil die die beste Recovery von allen hat, falls doch mal was schiefgeht.

    Warum brauche in eine Recovery beim Ultimate II+ wenn ich davon ausgehe, dass mit einem SIDKick pico Firmwareupdate die originalen SIDs auch in dem von der Ultimate II+ genutzten Variante der Erkennung nachbilden könnten?

    Das würde ich mal nicht in einen Topf werfen. So ein SD2IEC und diese schweineteuren Emulationssachen sind für mich grundverschiedene Dinge.

    Genau deshalb hatte ich die zwei Cluster SD2IEC und "diese schweineteuren Emulationssachen" gebildet.

    Der Preis reicht doch als Begründung aus. Und es reicht für die allermeisten Zwecke.

    Liegt im Auge des Betrachters. Wenn man Fälle hat, für die es nicht ausreicht, braucht man das andere ja noch zusätzlich (dann sehe ich keinen preislichen Vorteil). Und ich hatte ja explizit danach gefragt, ob es außer dem Preis noch andere Vorteile gibt - für mich steht die Funktion im Vordergrund. Aber andere haben hier ja bereits weitere Aspekte geliefert (Einfachheit, die Fähigkeit größere Dateien abzulegen, ...), danke dafür! :)

    Jetzt habt ihr mich abgehängt :D


    Ich kriege gedanklich das

    Nachtrag: Der SID-Player der 1541 Ultimate II* verwendet in der Tat die gleiche Detektion wie beim Ultimate 64 - und daher kann man den dort auch testen. Dann muss der SID-Ersatz halt im C64 / C128 rein.

    vom Posting vor dem folgenden

    Für die vom SID-Player kann ich nichts sagen, dazu ist mir nichts bekannt.

    nicht zusammen. Wenn der SID-Player der Ultimate-II* die gleiche Detektion verwendet, ist es doch der von markusC64 referenzierte Code? Oder kam der Nachtrag des Vorpostings zeitlich nach dem späteren Posting?

    vielleicht mache ich mal "blind" einen Test, ob ich die Erkennungsroutine glücklich machen kann, aber testen muss es jemand anders.

    Testen kann ich. Allerdings derzeit nur mit dem SID-Player der Ultimate-II+, da ich die anderen Ultimates suchen müsste.


    Ich persönlich würde es cool finden, wenn die Detektion der Chip-Variante ebenso emuliert werden könnte und nicht innerhalb der Ultimate-II+ als SIDKick pico erkannt werden würde (jedenfalls nicht über die Prüfroutine, die derzeit "unknown" zurück gibt. Denn diese Routine könnte ja theoretisch auch von anderen verwendet werden, die dann weiterhin den Typ nicht richtig erkennen würden?

    könnte jemand Test ob ein Pull Up-Widerstand zwischen Pin 25 und Pin 26 des SID-Sockels (finden sich auf der SKpico Platine leicht zugänglich) die Erkennung triggert?

    Jetzt bin ich verunsichert: Nach meiner Pin-Zählung ist da doch der Pi Pico drüber? Leicht zugänglich ist doch die untere Hälfte der Pins?

    Ich hab sowohl ein Pi1541 als auch ein 1541-Rebuild. Das Pi setze ich nie ein, da ist mir das Gehampel zu groß und es funktioniert bei mir zu wenig zuverlässig. Auch am Rebuild ist (mir) die "Image-Einlegerei" (zu) umständlich.

    Ich habe zu Ultimate-II+ und Ultimate-II u.a. auch ein Pi1541. Letzteres wegen der Ultimates nur aus Interesse verprobt, aber dort zumindest nie Probleme gehabt. Was meinst du mit "zu wenig zuverlässig"? Hatte es in der letzten Firmware zu viele Bugs?

    Und gerade am VC-20 und am C16/Plus4 ist "Kompatibilität" genau NICHT das Kriterium. Auch am C128 (nativ) nicht, wenn man nicht gerade CP/M starten will.

    Ging mir da auch eher um den C64 bzgl. Kompatibilität und dass man das Pi1541 zusätzlich halt noch bei den anderen Rechnern einsetzen könnte (das geht mit den aktuellen Ultimate-II+ aufwärts glaube ich nicht mehr). Da könnte ein SD2IEC wirklich eine gute Ergänzung zu der Ultimate-II+ sein.

    Das SD2IEC ist "rock solid" und super einfach zu bedienen - einfach ein "CD" in ein Image und fertig. Das zusammen mit dem unschlagbaren Preis macht es zu meinem absoluten Liebling. Und ich denke, das geht sehr vielen anderen auch so.

    Danke für die Einblicke in andere Einsatzgründe, genau deshalb hatte ich gefragt :) Aber da scheinen Meinungen auseinander zu gehen, was ja nicht schlimm ist. Mir persönlich bringt rock solid und einfachere (die des Ultimate-II+ würde ich jetzt nicht als schwierig bezeichnen) Bedienung als Allroundspeicher nichts, wenn dort nicht alles läuft. Als zusätzliches Gerät für die von dir genannte Einfachheit könnte ich es mir aber durchaus vorstellen. Steht nun auf meiner Liste ;)

    Die "Rechnung" hinkt aber auch - jemand kann Pi1541, U2, U64, .. gleichzeitig angeben, aber nur 1 x SD2IEC.

    Ja, das geht aus der Datenbasis der Summen nicht hervor. Für mich wäre tatsächlich interessant, wie viele eine "echte" (ich weiß, dass ist auch nicht genau ;) ) Floppynachbildung haben im Vergleich zu denen, die nur so etwas wie SD2IEC haben (insb. wenn keine originale Floppy vorhanden ist). Ich würde vermuten, dass es nur sehr wenige gibt, die nicht mindestens das Original bzw. eine möglichst gute Emulation haben. Ausschließlich auf funktionierende bzw. angepasste Software zu setzen, schränkt doch schon ziemlich ein - meine Meinung.

    Ich bezweifle, dass man in diesen Fällen z. B. mehrere U2 anschaffen würde.

    Aber ist das nicht wieder der Kostenpunkt? Pi1541 könnte man auch an VC-20, C16, C128 etc. betreiben und man wäre deutlich kompatibler.

    Bisher liegt das SD2IEC vorn.

    Als einzelne Produktart, ja. Wenn man aber die Auswahlmöglichkeiten, die eine 1541 genau nachbilden können (1541 Ultimate, Pi1541, Disk-Emu auf Ultimate64, ...) zusammen zählt, relativiert sich das. Alles andere hätte mich auch gewundert; Wenn man schon in diesem Hobby echte Hardware nachbilden will, dann doch möglichst genau. So dass auch Nachlade-Demos, sämtliche Spiele etc. ohne spezielle SD2IEC-Anpassung laufen. Gerade bei Hobbys ist der Preis ja oft nicht das primäre Kriterium.


    Mit SD2IEC bin ich irgendwie nie warm geworden. Entweder ein echtes Laufwerk oder eine Emulation, die es bestmöglich (also mit möglichst wenig Einschränkungen) nachbildet. Hab mich gefragt, ob es außer dem Preis noch einen Grund gäbe, SD2IEC einzusetzen...

    Nein, er meint das Ultimate 64, denn in ein Modul kann man ja schlecht die SIDs reinstecken.

    Es ging ja ursprünglich darum, warum der SID-Player im (1541-)Ultimate-II+ die SIDKick-pico-Einstellung nicht richtig erkennt ("unknown") und darauf Frenetic mit der Testnachfrage geantwortet hat. Der SID-Player dürfte vom Code gleich oder ähnlich sein zwischen Gideons Ultimate-II+ und Ultimate64.

    ich habe nachgefragt und im icomp-Forum gestöbert: das Reloaded MK2 erkennt SIDs indem die Spannung am Audio In gemessen wird. Da ich weder ein Reloaded noch ein Ultimate Board habe suche ich Tester: könnte jemand Test ob ein Pull Up-Widerstand zwischen Pin 25 und Pin 26 des SID-Sockels (finden sich auf der SKpico Platine leicht zugänglich) die Erkennung triggert? Im Forum steht ein Wert von 1kOhm, aber man kann auch mal erstmal größere Werte testen, wenn man vorsichtig sein möchte.

    Kann ich gerne testen, falls du mit Ultimate Board auch mein Cartridge (1541-)Ultimate-II+ meinst. Suchen müsste ich bei mein altes Ultimate64, außerdem hätte ich noch eine (1541-)Ultimate-II (ohne Plus - ebenfalls zu suchen ;) )


    Was mir aber noch nicht klar ist: Selbst wenn ich es mit einem Pull-Up-Widerstand teste, so könnte es doch nur von "unknown" auf einen der beiden Chip-Typen springen? Oder wird dann noch ein anderes Kriterium ausgewertet?


    Ich werde es heute mal austesten!

    Vielen Dank Frenetic was du da mit der Firmware zauberst! :)


    Mir ist aufgefallen, dass im SID-Player der Ultimate-II+ als System-SID-Typ "unknown" steht. Das Cartridge kann dies doch auch nur indirekt ermitteln, könnte man das beim SIDKick pico nachbilden? Also dass 6581 und 8580 erkannt werden, je nachdem was man im SIDKick pico eingestellt hat? Evtl. gibt es ja noch andere Hard-/Software, die automatisch den SID-Typ ermittelt und ggf. aktuell fehlgeleitet wird?

    Danke Pat Power für das Initiieren dieser Competition! Ich habe so Spiele kennengelernt, die ich noch nicht kannte. Hatte es zwar erst sehr spät mitgekriegt, aber dabei sein ist alles :)


    Mini Putt: 25


    Jolly Jumper: 491


    Test Drive: 1056


    Rick Dangerous II: 3680


    Rocket Smash Ex: 21375

    Man hört da gelegentliche Knackser, wenn es dieselben sind, wie Du meinst - das müsste die jeweils neue Initialisierung der SIDs sein, wenn ein neues Stück beginnt.

    Interessant, das sind scheinbar noch andere. Aber ich höre die, die ich meine, auch in deiner Aufnahme (vielen Dank dafür!): Ganz deutlich ab 8:45 Min. rum, "Another visitor (BLUBB) stay a while (BLUBB) staaay forever (BLUBB)" ... Am Anfang des Folgesongs extrem: (BLUBB) Ping (BLUBB) Pong (BLUBB) Ping (BLUBB) Pong (BLUBB) Ping (BLUBB) Pong (BLUBB) Pong (BLUBB) Pong (BLUBB) ... Wenn dann die Töne durch was Gleichzeitig anderes (anderer Kanal?) überbrückt werden, hört das (BLUBB) auf. (ja, ich bin nicht sonderlich stolz auf meine wortbasierte Beschreibung der Töne ;)

    Ich habe durch Zufall nach einiger Zeit nach einem Firmware-Update geschaut und bin begeistert, dass v0.20x meine Paddle-Probleme komplett gelöst haben. Sie spielen sich nun wie bei einem anderen C64 mit Original-SID bei mir. Vorher war BLAF für mich unspielbar mit dem SIDKick pico.


    Im Anschluss war ein wenig Entspannung mit Anschauen von Demos angesagt, dort fiel mir ein Soundverhalten auf, an welches ich mich in v0.14 nicht erinnern konnte und auch mit einem echten SID nicht so klingt: Es kommen manchmal so niedrig-frequente Knackgeräusche (kann ich nicht besser beschreiben), es hört sich an als wenn etwas kurz für die folgende Soundausgabe initialisiert werden würde. Ein wenig so, als wenn man früher ein Cinch-Kabel an den Verstärker angeschlossen hat wenn der Eingang ausgewählt war :)


    Frenetic : Ist dir so etwas bekannt? Es handelt sich um die erste Hardwareversion mit Firmware v0.202 (für Rev. 1) mit PWM-Ausgabe ohne LED. Datei: SKpico1_PWM.uf2 (aus SKpico_FW0.202.zip) - und vielen Dank für deine Verbesserungen bzgl. Paddle-Support in den neuen Versionen!!


    Stark nachvollziehen konnte ich es bei dem Demo "Next Level" von Performers.

    war das nicht so, dass man auch oft zwischen den orig. Spielekassetten den Tonkopf nachjustieren musste?

    da gab es doch noch nie diese eine korrekte Lage der Tonspur nach der sich alle richten mussten

    Bei Originalspielen hatte ich das noch nicht, wenn die Datasette auf den korrekten Azimuth eingestellt wurde. Und genau das ist das Problem: Jede Aufnahme unterliegt gewissen Toleranzen, und den Azimuth danach einzustellen setzt die Abweichung dann zum "Standard". Weicht eine andere Kassette dann "in die andere Richtung" ab, die mit korrektem Azimuth noch lesbar wäre, ist es ggf. relativ zur anderen Kassette zu viel.


    Nicht umsonst gibt bzw. gab es professionelle Azimuth-Kassetten, die waren zum Einen meist mit anderen Geräten aufgezeichnet (teilweise spezielle Spulenmaschinen mit gleicher Bandbreite, soweit ich weiß) und zum Anderen sind die Kassettenhüllen auch oft massiver (so dass beim Abspielen zum Einstellen des Azimuths der Bandlaufpfad möglichst genau ist).


    Ich habe selbst diverse Azimuth-Einstellkassetten für Tapedecks, die man dann mit Oszilloskop exakt einstellt. Bei der Datasette ist es mit Monokopf schwieriger, da man da nur nach Amplitude gehen kann. Es gab m.E. auch Verfahren, in denen linke und rechte Spur phasenverkehrt aufgezeichnet wurden um beim Monokopf auf möglichst niedrige Amplitude einzustellen (wäre ggf. mal ein Experiment wert selbst so ein Tape auf einem sehr guten und exakt eingemessenem Tapedeck zu erstellen), da die sich in Summe bei optimaler Einstellung aufheben müssten.


    Nun kann man die billige Kassettenmechanik dieser Datasette nicht mit einem hochwertigen Kassettendeck mit Doppel-Capstan vergleichen, dennoch hilft meiner Meinung nach eine exakte Einstellung dort enorm, um möglichst viele Kassetten lesen zu können (vor allem Originale). Ich habe keine Information darüber, wie genau Commodore die Datasetten einstellte, mache mir da aber keine Illusion.


    Das Problem waren doch eher die selbstaufgenommenen Kassetten, die die Leute lesen können wollten. Welche, die teilweise mit fraglich eingestellten billigen Doppelkassettendecks oder anderen Alternativen aufgenommen wurden. Wenn tatsächlich eine Originalkassette nicht in einem Laufwerk mit optimal eingestelltem Azimuth (aber manuell anderer Einstellung) gelesen werden kann, dann war die Produktion sehr fraglich. Unternehmen, die Kassetten professionell vervielfältigt haben, hatten Personal um die Geräte optimal einzustellen bzw. zu warten. Das wäre schon für Musikproduktionen negativ aufgefallen, wenn dort die Höhen fehlen - Kaufkassetten waren doch eher qualitativ hochwertig aufgenommen.


    Ein korrekter Azimuth ist in der Theorie keine Hexerei, weshalb es da auch nur eine Einstellung gibt: exakt rechtwinklig zum Bandlauf. In der Praxis ist es vom Gerät und vor allem von dem verwendeten Referenzmaterial bei Einstellung abhängig, wie gut man den optimalen Azimuth trifft.


    Das Drama beginnt ja erst, wenn man sich auf eine Aufnahme mit schlechtem Azimuth selbst einstellt, nur um die Aufnahme lesen zu können. Nicht nur, dass man dann korrekt aufgenommene Originalkassetten nicht mehr lesen kann, man verursacht nur weitere Schrottaufnahmen, wenn man selbst Daten mit der Datasette speichert. Diese Selbstjustagen sind für mich das schlimmste was der Datasette passieren konnte, dadurch musste man sich regelmäßig neu einstellen und Lesefehler waren ein Ablehnungsgrund für die Akzeptanz. Und dass überhaupt Modifikationen wie eine LED als Justagehilfe erstellt wurden, zeigt welch Ausmaß es genommen hat. Statt dass lieber alle Geräte sich auf den einzig richtigen Azimuth einstellen, der über Referenzbänder bei Tape Decks Standard ist.


    Praktisch kann man diese verstellten Aufnahmen nachträglich nicht mehr rückgängig machen, deshalb empfehle ich Datasettenliebhabern zwei Datasetten: die schönere auf korrektem Azimuth für alle sauber produzierten Originale und Eigenaufnahmen ohne verstelltem Azimuth, und eine schlecht erhaltenere (um die es nicht schade ist) für Rumorgeln an der Azimuth-Einstellung für schlechte Aufnahmen (und ja markieren, dass man damit keine neuen Aufnahmen anfertigt).


    Sorry für die lange Nachricht, aber als absolutem Datasetten- und allgemein Kassettenliebhaber, der auch die Justageseite mittels Azimuthkassetten kennt, finde ich es wirklich traurig was da in der Vergangenheit speziell bei Datasetten abgegangen ist.

    Wenn man vom Hundertsten ins Tausende kommt:


    Ich schreibe derzeit nebenbei ein einfaches Testprogramm, um die Time-Of-Day-Funktion der CIAs einfacher zu testen. Dies mache ich auf dem PC mit Hilfe von VICE, verifiziere die Ergebnisse aber von Zeit zu Zeit mit einem echten C64. Dabei ist mir aufgefallen, dass die aktuelle Version 3.8 einen Bug im Umgang mit dem AM/PM-Bug beim Setzen der Stunde 12 hat.


    Es geht um core\ciacore.c im Sourcecode von VICE. Dort wird in ciacore_store_internal im Falle des Setzens der Stunden erst geprüft, ob sich der zu schreibende Wert vom gespeicherten unterscheidet und erst danach im Falle der Stunde 12 AM/PM geflippt. Der CIA-Bug muss aber vor dem Prüfen auf den zu schreibenden Wert angewendet werden (war in einer der Vorversionen der Fall). Aktuell lässt sich AM/PM nicht mehr umschalten, wenn die Time-of-Day des CIAs bereits auf Stunde 12 steht.


    Ich werde mal versuchen einen Bug bei VICE aufzumachen und dann das Testprogramm fortsetzen.