Die Lötbrücke bzw. Lötbrücken müssen noch gesetzt werden
Hello, Guest the thread was viewed90k times and contains 944 replies
last post from SkulleateR at the
SIDKick pico Aufbau, Tipps und Fragen
- banman
- Thread is Unresolved
-
-
Super, das war es! Danke euch drei!
-
Ich bin mir nicht sicher ob das immer so ist, oder nur bei diesem C128?
Verwende ich einen SKpico2040DAC meckert die C128 Diagnose den 6581 (U5) an, nutze
ich den originalen 6581 tritt der Fehler nicht auf.
Tausche ich den SIDKick gegen einen anderen SKpico2040DAC kommt der Fehler wieder,
ich habe auch schon die Settings 6581/8580 und XPot raw/smooth/... probiert.
Das muss ich Morgen glatt mal an einem anderen C128 probieren!
PS:
Bei den Settings zu XPot werden im Menü für raw - 29/29 angezeigt, bei smooth waren es ca. 48/48,
alle Werte mit gestecktem Harness.
Mfg Jood
-
Das muss ich Morgen glatt mal an einem anderen C128 probieren!
... oder Du liest einfach mal in der Anleitung nach
-
... oder Du liest einfach mal in der Anleitung nach
Das hatte ich, aber bin scheinbar zu doof, und verstehe nicht was das bewirken soll.
Auch die Werte sind mir ein wenig suspekt, was sollen diese z.B. "0x2Ah" aussagen?
Ich hätte "0x7Fh" erwartet bei einer 8Bit-Wandlung, bei "0x3Fh" wäre ich auch dabei,
wenn man z.B. das LSB weglässt, oder ist das eine 6-Bit Wandelung (0x00h..0x3Fh)?
*Wobei der Wert "0x2Ah" (dezimal 42) bei einer Range von 0..63 schon mittig wäre!
Werden diee Kondensatoren C108/C109 (1800pf) vom SIDKick genutzt?
Mfg Jood
-
Auch die Werte sind mir ein wenig suspekt, was sollen diese z.B. "0x2Ah" aussagen?
The answer to the “Great Question” of “Life, the Universe and Everything” is “forty-two.”
-
Auch die Werte sind mir ein wenig suspekt, was sollen diese z.B. "0x2Ah" aussagen?
Ich hätte "0x7Fh" erwartet bei einer 8Bit-Wandlung, bei "0x3Fh" wäre ich auch dabei,
wenn man z.B. das LSB weglässt, oder ist das eine 6-Bit Wandelung (0x00h..0x3Fh)?
*Wobei der Wert "0x2Ah" (dezimal 42) bei einer Range von 0..63 schon mittig wäre!ich weiss jetzt nicht, wo das 0x2A herkommt, die normalen Paddle-Werte liegen, bspw. bei einer Maus zw. 64 und 192 (grob).
Das hatte ich, aber bin scheinbar zu doof, und verstehe nicht was das bewirken soll.
Du kannst damit entweder einen fixen Wert auf die gemessenen Paddle-Werte addieren (Parameter <80), oder Du kannst einstellen, dass der SKpico nur wenn ein Diag erkannt wird die Werte schrittweise erhöht (Parameter > 80, Erhöhung um bis zu Parameter - 80).
Werden diee Kondensatoren C108/C109 (1800pf) vom SIDKick genutzt?
die sind direkt an der PotX/Y-Eingängen, die kann man nicht nicht-nutzen
-
ich weiss jetzt nicht, wo das 0x2A herkommt,
Das ist jetzt ein anderer C128, ohne Harness werden 0xFFh/0xFFh angezeigt, mit Test-Harness
die besagten 0x2Ah, wobei dieser C128 keine Probleme macht, und auch eher 0x29h anzeigt.
pasted-from-clipboard.pngpasted-from-clipboard.png
Der Problem-C128 ohne Harness auch 0xFFh/0xFFh an, mit Harness dagegen 0x2Ah/0x2Ah!
pasted-from-clipboard.pngpasted-from-clipboard.png
Wobei die Diagnose meistens mit "U5 6581 bad" & "Controlport bad" beendet wird, selten
kommt auch ein "4066@U2 bad", manchmal läuft die Diagnose anfänglich fehlerfrei, aber
mit rot markiertem Controlport, und schließlich wieder "U5 6581 bad"...
Mfg Jood
-
Ich habe den Schaltplan vom C128 nicht griffbereit, aber ein 4066 ist doch bei den PotXY auch involviert...
-
aber ein 4066 ist doch bei den PotXY auch involviert...
Ja schon, U2 halt, sagt ja auch die Meldung, und wenn ich den Schaltplan richtig interpretiere,
werden über PA6/PA7 von CIA1 die Analogschalter in U2 geschaltet, um den Port zu wechseln.
Das ist beim C64 ähnlich gelöst, hier ist es U28 wimre, aber daran lag es bislang nie, vielleicht
sind einfach nur die Kondensatoren gealtert (vergleichbar mit Problemen beim R4AR).
Edit:
Ich habe jetzt kurzerhand C108 & C109 ausgelötet und gemessen, ich komme hier auf 2081pf,
bzw. 2105 pf (nominal 1800pf), wobei die Messergebnisse stark streuen, das könnte aber auch
am billigen Komponententester liegen, aber besser als nix!
pasted-from-clipboard.pngpasted-from-clipboard.png
Aus einem anderen Projekt hatte ich noch 2200pf Kerkos liegen, also habe ich auch hier kurz
gemessen (1945pf bzw. 2013 pf), das sollte passen...
Eingelötet, Fehler weg!
Mfg Jood
-
Hast Du mal versucht, andere CIAs in das Board zu stecken? Beim letzten C64, den ich repariert hatte (noch nicht gepostet), ging diese Fehlermeldung mit 4066@U28 BAD auch erst bei bestimmten CIAs in U1 weg. Die CIAs liefen aber in einem anderen Board ohne Probleme ...
-
Ich sehe gerade, dass es eine neue Firmware 0.211 gibt. Sehe ich das richtig, dass ich diese nur mit einem USB Adapter draufspielen kann? Ein Update der Firmware über das Konfigurationsmenü ist nicht möglich?
-
Wie kommst Du da drauf? Die Firmware wird wie immer beim Pico geupdated.
Taster festhalten während man den Pico per USB mit einem Windows-Rechner verbindet. Da erscheint ein neues Laufwerk, da das passende .uf2-File draufziehen und die Firmware wird geflashed.
-
Wie kommst Du da drauf? Die Firmware wird wie immer beim Pico geupdated.
Es sei denn er meint den SKpico2040DAC, da ist tatsächlich ein Adapter notwendig.
Mfg Jood
-
Ich sehe gerade, dass es eine neue Firmware 0.211 gibt. Sehe ich das richtig, dass ich diese nur mit einem USB Adapter draufspielen kann? Ein Update der Firmware über das Konfigurationsmenü ist nicht möglich?
Ein Update ist wirklich nur dann notwendig, wenn Du beim Jupiter Lander Cartridge (oder anderen alten Ultimax Cartridges) manchmal die SID-Melodie nicht hörst...
Edit: theoretisch ließe sich ein Update machen, nur ist die Firmware (eher aus Gründen der Bequemlichkeit für den Ersteller) sehr groß für ein Update per SD2IEC o.ä. Mir fällt gerade ein, ein Update via GeoRAM ließe sich machen, aber da ist die Zielgruppe dann wohl auf Sidekick64- und U64-Nutzer beschränkt.
-
Jupiter Lander ist es nicht, aber es gibt ein paar andere Spiele und Demos, die nicht korrekt funktionieren. Diese hatte Lynx hier genannt, weil sie auf dem U64 nicht korrekt funktionieren, und ich hatte sie rein aus Interesse mal mit dem SIDKick pico abgespielt. Folgende Probleme treten bei mir auf:
https://csdb.dk/release/?id=189483 Sabrina 2020 Digimusic: läuft nicht im korrekten Tempo ab, wird stellenweise langsam (wie eine eiernde Kassette, ohne die Tonhöhe zu ändern)
https://csdb.dk/release/?id=190301 Fix it Felix Jr. Speech Titlepic: Im Titelbildschirm hört man nur einzelne Knackser, keine Sprache
https://csdb.dk/release/?id=151275 Wonderland 13 Digimusic Side 3: Smack my bitch up von Prodigy: Auch hier nur einzelne Knackser.
Die Sachen sind wohl extrem trickreich programmiert, aber mit einem 8580 klappt es einwandfrei. Ich habe auch im Konfig-Menü das reSID+digi detect eingestellt, das brachte aber keine Änderung. Gibt es sonst noch etwas, was ich ausprobieren könnte?
Falls das Update irgendwie über das Konfigurationsmenü machbar wäre, wäre das eine tolle Option. Über das SD2IEC müsste man doch auch große Dateien lesen können, aber GeoRAM über U64 wäre ja auch eine Option (zumindest für mich).
-
ich habe eben mal getestet/reingeschaut...
https://csdb.dk/release/?id=190301 Fix it Felix Jr. Speech Titlepic: Im Titelbildschirm hört man nur einzelne Knackser, keine Sprache
ich kann keine Probleme feststellen, Sprache klingt so, wie sie soll (ist auch nur eine der $d418-Techniken, ob 4-Bit oder Mahoney habe ich jetzt nicht geschaut)
https://csdb.dk/release/?id=189483 Sabrina 2020 Digimusic: läuft nicht im korrekten Tempo ab, wird stellenweise langsam (wie eine eiernde Kassette, ohne die Tonhöhe zu ändern)
auch hier funktioniert der SIDKick (die Audioausgabe besteht auch nur aus Schreiben auf $d418, also nichts besonderes -- vermutlich Mahoney's Technik, daher auch der Hinweis "für 8580, nicht 6581"). Was sein kann: wenn Du ein Sidekick64 verwendest -- hier verursacht das Cache-Vorwärmen auf dem RPi (kostet immer ein paar Zyklen) eine Kollision mit dem Warten auf Strahlrücklauf, daher das ziehen. Müsste ich ggf. nochmal anschauen, hat aber nichts mit dem SIDKick zu tun.
https://csdb.dk/release/?id=151275 Wonderland 13 Digimusic Side 3: Smack my bitch up von Prodigy: Auch hier nur einzelne Knackser.
kann ich gerade nicht auf echter Hardware testen, weil ich keine Floppy zur Hand habe und Pi1541 funktioniert nicht beim Diskettenwechsel (oder ich bin nicht in der Lage es richtig zu konfigurieren). Den Audioteil gibt's vermutlich nicht separat, weil ständig nachgeladen wird? (Start von Disk #3 geht nicht, weil nochmal Disk #2 benötigt wird...)
Aber: ich habe kurz in Vice reingeschaut, es scheint die SIDVicious-Technik (https://codebase64.org/doku.ph…id_demo_routine_explained) zu sein, die kann der SKpico (auf jeden Fall mit der "+digi"-Option).
Kannst Du das vl. nochmal testen? Bist Du sicher, dass sonst alles funktioniert? (auch Bus-Timings stabil) Etwas anderes kann ich mir gerade nicht vorstellen.
-
Was sein kann: wenn Du ein Sidekick64 verwendest -- hier verursacht das Cache-Vorwärmen auf dem RPi (kostet immer ein paar Zyklen) eine Kollision mit dem Warten auf Strahlrücklauf, daher das ziehen.
Verstehe ich nicht, was muss ich machen? Ich habe den SKpico2040DAC.
Kannst Du das vl. nochmal testen? Bist Du sicher, dass sonst alles funktioniert? (auch Bus-Timings stabil) Etwas anderes kann ich mir gerade nicht vorstellen.
"Eigentlich" bin ich sicher, allerdings konnte ich zuerst sys 54333 nicht aufrufen. Habe den SIDKick dann herausgezogen und wieder eingesteckt, danach ging das. Ich werde das daher nochmal in einem anderen Board ausprobieren und dann berichten.
-
Verstehe ich nicht, was muss ich machen? Ich habe den SKpico2040DAC.
das heisst nur: am SKpico liegt es nicht (Sidekick64 != SIDKick). Ich habe das CRT mit Cartridges laufen lassen, die es derzeit nur bei mir gibt
-
SideKick64 meinte ich auch gar nicht, ich rede hier nur vom SKpico2040DAC. Ich habe es jetzt nochmal in meinem MK2 getestet, aber auch damit klappt es nicht. Anscheinend kann ich mit gesteckten SKpico2040DAC noch nicht einmal andere Diskettenspiele korrekt laden, warum auch immer (Space Taxi, Impossible Mission). SYS54333 klappt, damit komme ich in das Konfig Menü. Space Pilot als Onefiler hat geklappt, da kam auch ein richtig klingender Ton.
Ich könnte es jetzt nochmal in einem anderen C64 ausprobieren, und ich könnte noch einen zweiten SKpico2040DAC zusammenbauen. Das dauert aber etwas. Sobald ich was neues weiß, melde ich mich. Komisch ist das jedenfalls, ich habe erstmal keinen vernünftigen Erklärungsansatz.
