Wer hat den hier alles welche von den 20.000 Disketten gekauft und will vielleicht welche los werden 🤔😇
Der Großteil der Disketten ist seinerzeit an BP gegangen. Ja, die Ölfirma. Heute würde ich die nicht mehr beliefern.
Posts by Wiesel
-
-
Beim testen reicht es schon jeweils eine LED zu brücken. Natürlich nicht zu viele
Wenn es ein richtiger LED-Driver ist, dann ist es egal, wie viele LEDs Du brückst - LEDs treiben bedeutet nämlich "Strom regeln" und nicht "Spannung regeln". Wenn das das übliche Fehlerbild ist, dann werden die LEDs entweder mit zu viel Strom betrieben, oder sie sind zu schlecht gekühlt. Das kann natürlich beides sein, und es kann auch gewollt sein - ich habe selbst schon einen Stapel Ikea-LEDs bei denen trotz Aluminium-Platine eine von sechs LEDs kaputt ist (Rest ist OK), und ich habe daraufhin auch die "Dubai-Lampen" gefunden. Seltsam, dass das nicht häufiger in den Mainstream-Medien benannt wird. Und seltsam, wie viele Leute einfach akzeptieren, dass Dinge nach einer bestimmten Zeit kaputt gehen. Ich bin doch sehr froh, dass unsere 64er noch anders gebaut wurden
-
Riecht ganz danach. Ich denke ich werde die Backlight-Zeilen tauschen.
Bevor Du das machst, würde ich messen, ob die Versorgung der Hintergrundbeleuchtung noch in Ordnung ist. Meist sind das viele LEDs die in Reihe geschaltet sind, damit sie auf jeden Fall alle gleich hell sind. Das hat zur Folge, dass man eine recht hohe Spannung braucht, um diese LEDs alle gleichzeitig an zu bekommen. Das wird mit boost-Konvertern gemacht, wo im Ausgangskreis auch Elkos eine Rolle spielen - und diese Elkos sind die Sollbruchstellen in heutigen Geräten. Es würde mich nicht wundern, wenn Deine Reparatur in Teilen am Ende nur 20 Cent kostet, keine 30,- EUR.
-
Ich hatte 2017 mal die Idee verfolgt - aber noch ein paar Verfeinerungen gemacht, nämlich gemessen was die Originaltastatur an Widerstand hat, mit dem Datenblatt des HC4066 abgeglichen und einen Vorwiderstand für jede einzelne Taste entsprechend errechnet. Den Prototypen habe ich dann geroutet und produzieren lassen, aber nie in Betrieb genommen:
Da mich mein 8051-Entwicklungssystem in den letzten Wochen echt geärgert hat, habe ich ein Neues aufgesetzt - ohne USB->seriell Wandler, sondern mit nem schönen alten Mainboard, das zwei echte COM-Ports hat. Das nur als Nebenschauplatz; da ich vergangenes Wochenende mit einem guten Freund darüber diskutiert habe, wie unmöglich es ist, jeden noch-so-kaputten software-scanner in einer rein digitalen/softwaremäßigen Lösung zu bedienen (prinzipiell also die hier vorangehende Diskussion "reloaded"), habe ich den Prototypen von 2017 wieder herausgekramt und ihn in Betrieb genommen. Erstmal ohne PS2-Code, sondern nur um zu prüfen, ob meine Schaltungsidee zur Weitergabe von left-shift und shift-lock auch funktioniert. Und das tut sie: Ich kann "linke shift" und "shift lock" mit dem Microcontroller getrennt übertragen, und die einschlägigen Testroutinen für diesen Spezialfall zeigen absolut zuverlässig entweder nur linke Shift, oder sowohl linke Shift, als auch Shift lock.
Ich hatte noch einen C64, bei dem die shift-lock Erkennung nicht sauber funktionierte - da flimmert das shift-lock Bit nur, wenn man an der shiftlock-Taste wackelt. Den Rechner fand ich besonders interessant, denn ich hatte befürchtet, dass da eine besonders obskure CIA drin ist, die evtl. andere Schaltschwellen hat. Entwarnung: Es liegt bei diesem Computer nicht an der CIA, sondern an der Shift-lock Taste selbst. Diese Taste ist alt, kratzt vermutlich ein wenig und hat einen recht hohen ohmschen Widerstand, deswegen funktioniert die Shift-lock-Erkennung da nicht zuverlässig. Mit meinem Prototypen kann ich auch mit dem Computer zuverlässig die linke Shift und shift-lock übertragen.
Wenn also "irgendwo im Internet" steht, dass die Erkennung von Shift-lock nicht zuverlässig ist, dann ist das möglicherweise die gleiche Ursache wie bei meinem Computer: Eine alte/verschlissene Shift-lock Taste.
Auf dem Bild seht Ihr, dass ich noch einen Anschluss für die C64-Tastatur unter die Platine gelötet habe - sonst kann ich das Testprogramm nicht laden. Der Anschluss über Kabel ist auch nicht gerade der Weisheit letzter Schluss. Ich kann aber sagen, dass ich ein proof-of-concept habe, eine PC-Tastatur an einen C64 anzuschließen und dabei nicht fürchten muss, dass irgendwelche kaputte Software nicht funktioniert. Ab hier ist es noch "Fleißarbeit", den PS2-Code aus Lyra in diesen Microcontroller zu portieren und sich ein vernünftiges Mapping auszudenken. Für ein Produkt reicht es aber meiner Meinung nach noch nicht, weil der C128D nicht abgedeckt ist. Ich vermute mal, dass es sehr viel mehr C128D ohne Tastatur gibt, als C64 ohne Tastatur.
(Thread-Ruhe nach über 12 Jahren gestört - ist das Rekord?)
Jens
-
Wobei Pagefox dort nicht als Profitör gelistet ist.
Kann sein, dass das noch ein Artefakt älterer Versionen ist. Wir hatten lange Zeit das Problem, dass Schreibzugriffe, die auf der "echten Hardware" in zwei Zielen gleichzeitig landen, nicht im Chameleon abgebildet werden konnten. Und genau das passiert bei Pagefox: Das Löschen einer Seite nutzt die Tatsache, dass Schreibzugriffe auf das C64-Ram auch im Pagefox-Ram landen (je nach Config, siehe meine Beschreibung im PDF). Seit wir das auf dem Chameleon abbilden können, funktioniert Pagefox auch ohne "hickups". Ich geb's mal an Tobais weiter - vielleicht hat(te) er noch andere Gründe.
-
Wenn's eins gibt das ich sehr schlecht kann, dann ist das "Videos machen". Siehe die Seminare die ich für die Revision dieses und letztes Jahr gemacht habe. Ich glaube, das sollten Andere machen.
Dinge die vom Turbo profitieren werden in unserem WIki gelistet: http://wiki.icomp.de/wiki/Chameleon#Turbo
-
Mit Original-Speed ist es "so gerade eben" benutzbar. Spaß macht das erst wenn der Chameleon-Turbo an ist
-
Ich lade einfach mal alles hier hoch was ich noch habe. Den Schaltplan habe ich nicht selbst gezeichnet, Credits in der jeweiligen Datei.
Unglaublich - das ist schon zehn Jahre her...
-
"EPROMMer"-Schaltplan gesehen hatte, der die eine 9VAC-Leitung direkt mit Masse verbindet.
Das scheint ein Fehler zu sein - so ein Prommer würde auch einen normalen C64 in die Knie zwingen.
dabei vollkommen verdrängt, daß das ständige Umladen eines Kondensators mit signifikanter Kapazität bereits ohne Strom zu dauerhaft hohen Strömen durch die Brücke führt, was so gar nicht mein Ziel war.
Eben - ein Design, das einen Sinus erzeugt, ohne dabei ewig viel Energie zu verbrennen, ist nicht trivial. Machbar, aber für ein Hobbyprojekt meiner Meinung nach zu viel.
-
aber da sehe ich irgendwie keine Kondensatoren an 9VAC.
Die wären wenn, dann auf einem externen Produkt (ich nehme diese Lasten an, weil Benutzer da natürlich Produkte anstecken, von denen ich nichts weiß). Die 9VAC auf dem C64R haben natürlich den gleichen GND-Bezug wie bei einem alten C64 auch. Nur dass der Bezug beim C64R offensichtlicher ist.
Wenn Du etwas Sinus-ähnliches machen willst, brauchst Du mehr als nur ein paar FETs - ohne "Intelligenz" geht da meiner Meinung nach nichts, also eine PWM erzeugen, die den Sinus erzeugt - nur dann kannst Du mit LC-Filtern arbeiten. Wenn Du mit einem LC-Filter aus 50Hz-Rechteck einen 50Hz-Sinus machen möchtest, werden die Bauteile wahrscheinlich größer als das C64-Gehäuse sie aufnehmen könnte
-
Oder ist der Schaltplan irgendwo veröffentlicht?
Ja klar - siehe Wiki, da finden sich alle technischen Infos über iComp Produkte.
ob das für 100mA o.ä. überhaupt ein tauglicher Ansatz ist.
Das kommt auf den Innenwiderstand des Kondensators an - Frequenz ist ja vorgegeben. Und mit den steilen Flanken die Du da produzierst, kannst Du (je nach Kondensatortyp) schon in die Bereiche kommen, wo Deine H-Brücke an ihre Grenzen kommt. Ich habe die FETs aus dem Grund etwas überdimensioniert: Low-side mit 45mOhm Rdson und High-side bei 98mOhm. Beide mit Puls-Belastbarkeit satt über 20A. Das klingt zwar "unkaputtbar", aber wir hatten wirklich schon einen (!) C64 Reloaded, der diese H-Brücke kaputt hatte. Das war in der Garantiezeit, und der Kunde wollte nicht verraten, was er mit dem Teil gemacht hat.
-
Nebenbei: darf ich fragen, wie Ihr das Problem im Reloaded gelöst habt?
Dein Schaltplan sieht so aus, als hättest Du den C64R-Schaltplan gesehen - nur dass ich diskrete N- und P-Kanal FETs verwende, wobei die P-Kanal FETs mit einfachen Transistoren angesteuert werden. Eine kleine "Totzeit" zwischen der Aktivierung der zwei Brücken macht ein simples RC-Glied.
aber halt keine negativen Spannungen erzeugen.
Das kannst Du unabhängig von der Brückengleichrichter-Diode. Dafür sind Kondensatoren da - die machen den DC-Anteil zu 0, und Du kannst mit einer Diode die positive Seite gegen GND clampen. Voila: Negative Spannung, obwohl 9VAC positiven GND-Bezug hat.
-
höchstwahrscheinlich auch die Register betroffen sind
Warum? Alle Fehlerbilder die bisher *beobachtet* wurden, passieren bei der Übertragung RAM->VIC. Reigster sind aber eine Übertragung CPU->VIC. Die kann durchaus fehlerfrei sein und trotzdem können die beobachteten Fehler auftreten. Ich bleibe bei "VIC oder RAM", mit sehr starker Tendenz zum RAM auf U12.
-
Der LS373 schein auch ein guter Kandidat zu sein.
Nein, ist er nach Deiner Darstellung nicht mehr: Wenn der Fehler auch bei Sprites auftritt, dann ist der LS373 unschuldig.
-
Wenn es nur beim Char-ROM passiert,
...kann auch der LS373 schuld sein, denn der ist einzig dafür da, die Multiplex-Adressen aus dem VIC in statische Adressen für die ROMs (Char oder extern) zu übersetzen.
-
isolierte 9VAC-Lösung
Warum isoliert? Falls Du damit "galvanisch getrennt" meinst: Im C64 werden die 9VAC direkt mal mit einem Brückengleichrichter nach DC gewandelt, und der hat eine direkte Verbindung nach GND. Somit ist klar, dass die Referenz immer GND ist - mit undershoot in Richtung "eine Diodenstrecke unter GND". Sprich: Galvanisch getrennt ist nicht nötig, denn sobald Du versuchen würdest, die 9VAC von GND weg zu bewegen, fließt Maximalstrom durch die Gleichrichter-Dioden.
Wobei mir ehrlich gesagt einigermaßen rätselhaft ist, wie diese Schaltung stabile 25V DC liefern soll.
Der Dela-Eprommer II ist auch für den C64 Reloaded (MK1/MK2) mein test case gewesen. Da ist eine doppelte Diodenkaskade drauf, ähnlich wie bei den alten C64-Boards. Es werden auf der ungeregelten Seite ca. 42V generiert, die dann mit Reglern wieder herunter gesetzt werden. Da jedoch der eine große Regler nicht für diese hohe Eingangsspannung ausgelegt ist, geht der gern auf diesem Prommer kaputt (ein schnöder 7805 wenn ich mich richtig erinnere).
Jens
-
die Schwelle für 0/1-Erkennung ist eher bei 2,0V als bei 5,0 V ...
Bei TTL liegt sie ehr bei 1,4V. Ob sie sich aber proportional mit der Versorgungsspannung verschiebt, kann ich gar nicht sagen - Halbleiter sind arg nicht-linear. Jedenfalls funktioniert bei dieser Maschine so viel, dass man recht luxoriös Diagnose betreiben kann. Lass' uns mal Rückmeldungen abwarten, ehe wir weiter Kaffeesatz lesen
-
Gegen das RAM spricht, dass der Fehler beim RAM-Test des Diags nicht aufpoppt, dass er nicht immer da ist und dass Spiele usw. laufen. Bei einem RAM-Fehler würde ich erwarten, dass der nicht immer nur genau den Videospeicher betrifft. Kann natürlich immer noch sein, wäre aber ein komischer RAM-Fehler. Ein Problem z. B. mit dem 40x12-Linebuffer des VIC ist da für mich wahrscheinlicher.
Einspruch. Wenn auch nicht auf dem Level "das Ram selbst ist der Fehler" - der Gedanke ist, dass bei der Kommunikation zwischen RAM und Ziel immer Zwei beteiligt sind. Zwischen RAM und CPU scheint's problemlos zu klappen, sonst würde der Computer nicht laufen. Da jedoch bei der Übertragung vom RAM in den VIC das Zielbauteil eine eigene Versorgung hat, ist auch der Schwellwert für das Erkennen von 1 oder 0 möglicherweise ein Anderer. Eine etwas zu niedrige Versorgung des VIC würde den Schwellwert ebenfalls herabsetzen, und wenn dann noch das RAM ein wenig schwach auf der Brust ist, treten hin und wieder Übertragungsfehler auf Bit 7 auf - und zwar immer "von 0 auf 1", nie anders herum.
Korrekte Beschriftung der CPU zweifele ich nicht mehr an
-
Die MOS-TTLs sind auf jeden Fall verdächtig. Die CPU ist wohl sowas wie eine "blaue Mauritius", denn da hat sich der Maschinenbediener vertippt: Da steht 6610, nicht 6510. Das ist aber kein technischer Fehler. Edit: Oder ist das überhaupt so? Bei genauerem Hinsehen könnte das auch 6510 sein.
Bit7 sehe ich auch - kann einfach das entsprechende RAM sein, was mein erster Kandidat nach Prüfen der VIC-Versorgungsspannung wäre (7805 versorgt nur den).
-
Irgendwie schien es sich zwischen den Zeilen zu lesen, dass ihr im Streit auseinander gegangen seit.
Solange es "keine" Informationen gibt, gibt es immer Gerüchte. Nein, Streit hat es nicht gegeben, auch wenn's bisher ein Verlustgeschäft für mich war. Ich bin Geschäftsmann, da muss man so etwas einkalkulieren bzw. aussitzen können. Tommes hat schon etwas dran verdient, und das ist gut so - er hatte ja auch Arbeit damit. Ich habe mich wohl nicht drum gerissen, die Arbeit hierher zu holen - davon haben wir nämlich schon genug. Aber warum sollte ich Tommes böse sein, wenn er es einfach gesundheitlich nicht kann? Ich freue mich auf den Tag, an dem er wieder voll dabei ist, und wir wieder zusammen arbeiten können.
Was HDMI für C64 angeht: Da gibts nen Thread in unserem Supportforum.
