OTP-EPROM nachprogrammieren?

Gerrit Heitsch schrieb:

Masken-ROMs waren bei den Stückzahlen billiger als Eproms. Meiner Erfahrung nach gehen die ROMs von Commodore recht häufig oder schneller kaputt als EProms. Kann aber auch daran liegen das die Masken-ROMs in NMOS gefertigt waren und im Betrieb sehr warm wurden.

Ich hatte noch kein defektes. Allerdings ersetze ich die Masken-ROMs gerne durch CMOS-EPROMs, so möglich. Beim gerne verbauten 2364 ist ohne Adapter aber nichts zu machen und beim 2332 bräuchte man ein 2532 EPROM als direkten Ersatz. Die gibts auch nicht in CMOS. Lohnt also erst ab dem 23128, da kann man einfach ein 27C128 für verwenden.

Leider ist die Belegung des Sockels meist falsch. Das EPROM wird so über _OE gesteuert, _CS liegt fest auf GND. Steuerung über _CS würde noch ein paar mA mehr sparen. _CS fest auf GND und _OE als Freigabe macht man doch nur wenn es bei der Zugriffszeit knapp ist.

Das 'sehr' stimmt so nicht. Sie wurden warm, ja. Aber mehr auch nicht. Keine Spur von der Hitze eines SID 6581 oder VIC 6569 (diese Chips wollten zusätzlich zu +5V noch +12V).

Gerrit

Ich denk eher es lag am auf der Rückseite offenliegenden Bus. Ich erinner mich dass die RAMs die häufigste Ausfallursache war.

Gerrit Heitsch schrieb:

Ok, für mich ist >45 Grad schon viel. Die VIC, SID, PLA sowie die CPU wurden auch immer gut warm.. VIC und SID auch ohne die 12V. Meistens ist zuerst die PLA (ein 82S100) gestorben, der VIC sogut wie nie obwohl er Temperaturmässig an der Spitzenposition ist.

Aber mal aus der Nähkiste: Ich habe so gefühlte 160 C64 Boards repariert und versuch mal ne Hitliste der kaputten Chips wagen:

1. CIA wegen ESD (die alten C64 Boards hatten genau garkeinen Schutz)
2. PLA wegen Überhitzung
3. SID auch wegen ESD
4. MaskenROMs, hier sehr gerne das Basic-ROM
5. TTL-Chips die von Commodore in Lizenz gefertigt wurden (77xx mit MOS Logo drauf)
6. RAM-Multiplexer (74LS257)
7. RAM selbst, aber meistens erst dann wenn Das Netzteil versagt und Überspannung raushaut.

Bei dem bekannten Disklaufwerk 1541 gab es sehr oft diese Fehler:

1. Gleichrichter defekt > Dauerlauf
2. DOS-ROM defekt > Dauerlauf
3. Liest schlecht und schreibt nicht > Regeltransistor für die analoge Schreib-Lese Elektronik defekt oder Kopf selbst.

Es gab natürlich auch noch jede Menge andere Fehler, aber das sind die mit Abstand häufigsten vorgekommenen.

Gernot Fink schrieb:

Der offenliegende Bus namens Expansionsport ist eine unsaubere Sache für sich, spielt aber erst dann eine Rolle wenn versucht wird per Abzweiger das ganze nochmals zu erweitern. Da gab es abenteuerliche Konstruktionen die das ganze auf 3-4 Ports hochgejubelt haben und letztendlich nur VCC an/aus schalten konnten.

Bessere konnten dann den Takt, IO-Melder und einiges anderes noch umschalten aber krankten daran das man nicht beliebig die Daten und Adressleitungen länger machen kann ohne ein Problem mit Signalrelexion zu bekommen.

Deswegen sind diese Portweichen ein NO-GO und auch hartgesottene C64-User können bestätigen das Ungereihmtheiten im Betrieb direkt durch entfernen der besagten Weiche sofort aufhören.

Und das mit dem kaputten RAM, das liegt hauptsächlich daran das die beigelegten Netzteile leider im Fehlerfall eher dazu neigten auf der 5V Schiene mehr Spannung rauszugeben als sie sollten. Das RAM war da früher deutlich empfindlicher als die 74LSxx.

Die PLA war im Original ein 82S100 und konnt auch später durch ein solchen, korrekt programmierten ersetzt werden. Die Frage ist aber, was war in dem Chip mit dem Aufdruck 906114-01 wirklich drin? Ein echter PLA-Chip oder ein Custom-Chip der gar nicht erst programmiert werden musste? Letzteres müsste bei den beim C64 vorgekommenen Auflagen billiger gewesen sein wenn man, wie C=, die Fertigung solcher Chips in house hatte.

Die kam mir gar nicht so heiss vor. Ist wohl im Gegensatz zum VIC nicht besonders hitzefest.

Komisch... Wegen der Belastung durch den VIC hätte ich eher an das Character-ROM gedacht.

Wobei das Netzteil ein interessantes Beispiel von 'auf Kante genäht' ist. Ein Gleichrichter aus 1N4001, aber 1.5A Strom liefern. Bei den ersten noch der Schaltungsfehler dass der Spannungsteiler, der den GND-Pin des 7805 um 0,2V anheben soll nicht funktioniert (Widerstand zwecklos :))

Defekte RAMs hab ich allerdings bei solch alten Rechnern inzwischen deutlich häufiger. 4164 oder 41464, manchmal sterben nur Teile (Wirre Zeichen auf dem Monitor), manchmal ist der Chip einfach tot und manchmal hat er Kernschmelze (wird extrem heiss). Das ohne weitere Fehler im Rechner, RAM gewechselt, alles geht wieder.

Das mit dem defekten Kopf scheint bei den Laufwerken von Mitsumi haeufiger vorzukommen als bei denen von Alps.

Gerrit

Gerrit Heitsch schrieb:

Du kannst mit der Option -b9600 in der Kommandozeile dafür sorgen, daß mit 9600 Bd. gearbeitet wird. Allerdings wirst du die DIP-Schalter im EPROG auf 9600 setzen müssen, damit der dich überhaupt versteht. Die Kiste kann sich nunmal nicht automatisch auf die passende Baudrate einstellen.

Holger

Gerrit

Gerrit Heitsch schrieb:

Naja, ich kann nur für meine Software sprechen. Die "Langsamkeit" beim Auslesen hat, sweit ich das sehe, drei Gründe:

1. Es gibt die Möglichkeit eines Verboose-Modus. Damit kann man den Datenverkehr vom und zum EPROG beobachten und mitschneiden.
2. Es wird ein Byte-Zähler hochgezählt und auf dem Bildschirm angezeigt. Das kostet Rechenzeit und verlangsamt den Download.
3. Zwischen den einzelnen Lesezugriffen werden kurze Pausen eingelegt, um die RS-232 vom EPROG nicht zu überfahren.

Ich halte diese Verzögerungen für vertretbar, weil ich Datenfehler vermeiden will. Auch die Anzeige des Fortschritts halte ich für wichtig, weil man so abschätzen kann, wie lange die Datenübertragung noch dauert. In einer späteren Version wird der Datentransfer ggf. geringfügig schneller sein, muß ich nochmal sehen. "Korrekt" ist mir allerdings wichtiger als "schnell".

Grüße, Holger

Kann die andere Software auch, statt 'r' ein 'rv' als Option und ich bekomme einen Zähler im Format 'x von y Bytes' wobei das x hochzählt und das y die Grösse angibt.

Scheint nicht so das Problem zu sein. Ich hab extra einiges an Tests gemacht, und bisher gab es beim Auslesen eines korrekt programmierten EPROMs (also nicht mein morsches OTP) nie einen Fehler.

Klar, mir auch, es darf allerdings gerne so schnell wie ohne Fehler machbar sein. Ich werde an meinem Setup hier erstmal nichts ändern, deine Software erledigt das Programmieren und die andere das Auslesen. Zumindest hier tun beide das zuverlässig.

Gerrit

Gerhard Hoffmann schrieb:

Kaa Problem, wir hätten da noch einen Protonenbeschleuniger, 2 mA bei 590 MeV. Man bräuchte nur noch ein genügend schnelles DSO um festzustellen, ob Löschen schneller war als Verdampfen.

Das sind ca. 1.2MW. Ist das die Eingangsleistung oder tatsächlich die Leistung des Strahls? Was passiert, wenn der auf Luft trifft?

Viele Grüße, Martin

Martin Laabs schrieb:

Hmf, war eigentlich als Witz gedacht, ich sehe aber gerade:

Irgendwie dumpf in Erinnerung ist mir auch was mit Latch-Up bei grossen IGBT in Lokomotiven aufgrund kosmischer Strahlung. War vor einigen Jahren mal top-Thema.

Dauerleistung des Strahls, wenn alles funzt, 24/7. Input für die Anlage dürfte in der Gegend von 18 MW liegen. Im Moment krieg ich das Java Applet hier nicht zum Laufen, nur Daten vom August letzten Jahres...

Keine Ahnung. Gibt wohl eh kein Fenster dafür, die müssten doppel- wandig gekühlt sein. Bei der Neutronenquelle muss der Strahl ja auch irgendwie durch ein Fenster. Mit geringeren Leistungen geht das schon, wird in der Protonentherapie genutzt. Die Reichweite dürfte im Meterbereich liegen, kenn mich da aber nicht so aus. Die grösste Leistung wird dann kurz vor dem Stopp deponiert, so dass "Zielen" auch in der dritten Dimension möglich ist.