ZitatEin hochinnovatives, multifunktionelles Gehäuse aus 100% recycelten Pflanzenfasern
Das Gehäuse ist super!
Retro Chip Tester Pro vom 8Bit-Museum.de (vormals "SRAM/DRAM-Tester")
-
-
CuriousMarc hat sich auch einen RCT gekauft; We attend the Vintage Computer Festival (VCF East 2024) (youtube.com) @13:48
-
CuriousMarc hat sich auch einen RCT gekauft; We attend the Vintage Computer Festival (VCF East 2024) (youtube.com) @13:48
Echt jetzt?
-
Guten Abend
Anbei noch ein paar Bilder vom realen Einsatz des RCT,
Überprüfung von Piggy Pack Bausteine aus dem IBM Mainboard Version 1
Endziel sieht so aus, aus den unterschiedlichsten teildefekten wieder jeweils einen funktionsfähigen Baustein zu generieren,
um den Ablauf zu verifizieren habe ich noch zusätzlichen eine funktionsfähige Baugruppe zerlegt, um dann Bottem /Top einzeln zu überprüfen
-
Hallo Slabbi!
Bei der Reparatur eines alten Terminal konnte ich ein defektes IC vom Typ N8T28 identifizieren.
Der Bustreiber funktioniert ein paar Sekunden bevor er wohl durch Erwärmung aussteigt.
Mit der Wärmebildkamera ließ sich eine Temperatur im Betrieb von ca 50°C messen. Ab üngefähr
42°C bekommt er Probleme.
Läßt sich das IC im RCT unter Belastung testen?
Gruß
Axel
-
Alles anzeigen
Hallo Slabbi!
Bei der Reparatur eines alten Terminal konnte ich ein defektes IC vom Typ N8T28 identifizieren.
Der Bustreiber funktioniert ein paar Sekunden bevor er wohl durch Erwärmung aussteigt.
Mit der Wärmebildkamera ließ sich eine Temperatur im Betrieb von ca 50°C messen. Ab üngefähr
42°C bekommt er Probleme.
Läßt sich das IC im RCT unter Belastung testen?
Gruß
Axel
5,2V, den Test mehrfach durchlaufen lassen, notfalls extern erwärmen.
-
Alles anzeigen
Hallo Slabbi!
Bei der Reparatur eines alten Terminal konnte ich ein defektes IC vom Typ N8T28 identifizieren.
Der Bustreiber funktioniert ein paar Sekunden bevor er wohl durch Erwärmung aussteigt.
Mit der Wärmebildkamera ließ sich eine Temperatur im Betrieb von ca 50°C messen. Ab üngefähr
42°C bekommt er Probleme.
Läßt sich das IC im RCT unter Belastung testen?
In der Config den Loop Modus auf Max (11) stellen, dann läuft dieser unendlich bis Tastendruck. Den Logik-Test mit langem Druck auf OK starten.
-
Danke!
Probiere morgen mit dem defekten IC mal aus.
Hab mir mal das Video von der VCF East mal angeschaut. Wie auf der CC
Und ja, Marc hat sich wohl einen RCT zugelegt, wie er sagt. (Ab Minute 13 ff. im Video)
-
Und ja, Marc hat sich wohl einen RCT zugelegt, wie er sagt. (Ab Minute 13 ff. im Video)
Das witzige an der Sache: Er setzt demnächst meinen RCT ein und dabei hätte ich gerne sein Test-Equipment zur Verfügung.
-
Hmm, er hats ja gekauft. Das wird dann teuer...
-
Wäre es eigentlich auch möglich (rein theoretisch) mit dem RCT die Gatelaufzeit von Logikbausteinen zu messen, um 74LS und 74F z.B. zu unterscheiden oder ist der zu langsm dafür?
-
So ein ähnliches Thema hatten wir schon mal... der ATMega2560 mit 16MHz dürfte dafür zu langsam sein...
-
Dachte ich mir schon. Man könnte die Zeit extern vergleichen, aber das würde wohl immer nur für ein Gatter in einem Chip laufen oder ein komplexes Board erfordern.
Man gibt ein Signal an den Testchip-Gateeingang und ein 74AS Gate (1,5ns). Die Ergebnisse kommen in sich sperrendes Flipflop (Quiz-Buzzer-Schaltung). War der Testchip langsamer, nimmt man ein 2. 74AS Gate usw.
Fehlt ja nur noch die Möglichkeit einen Bauteiltester (kein Analog) und einen TL866 Programmer (keine EPROM Spannung) zu ersetzen und man bräuchte nichts anderes mehr ...
Was ich noch vermisse wäre USB C und einen Ein/Ausschalter.
Übrigens: coole MikroUSB-Buchse, sowas auch noch nicht gesehen
-
-
Was ich mich frage, ist, warum du slabbi nicht die Variante gewählt hast, wo man einfach einen AT Mega Board auf den RCT aufsteckt.
Da gibt es einige Gründe:
Nicht alle Ports herausgeführt. Bootloader nimmt Platz weg (den könnte man beim Arduino Mega auch noch weg lassen). Sehr umständliches Routing (die Ports müssen gesichert werden, gleichzeitig aber auch mit Spannungstreibern an den ZIF Sockel geführt werden. Und vor allem: sieht billig und bescheiden aus und man hätte überhaupt keinen Vorteil, nur dass es teurer wird (anstelle eines ATmega2560 ein komplettes AT Mega Board).
-
Es gibt jetzt ein kleines User-Projekt, was auf dem Beispielcode basiert.
Damit können Dallas DS12887 getestet werden (u.a. die RTC, wird ausgelesen und der Takt gemessen).
Download von der Firmware-Seite meiner Homepage.
Witzig, genau das wäre meine nächste Frage gewesen, ob auch RTCs dabei wären. Das fände ich super für die nächste Firmwareaktualisierung (die gibt es auch mit mehr Pins für z.B. Compaq EISA-Geräte)
Der 82S100 wäre mein heutiger Kandidat, der sich leider nicht auslesen lässt (ein 28 Pin Tri-State-PAL).
Lassen sich Tri-State-Ausgänge überhaupt mit dem AtMEGA erfassen (z.B. 74LS125)?
Da gibt es einige Gründe:
Nicht alle Ports herausgeführt. Bootloader nimmt Platz weg (den könnte man beim Arduino Mega auch noch weg lassen). Sehr umständliches Routing (die Ports müssen gesichert werden, gleichzeitig aber auch mit Spannungstreibern an den ZIF Sockel geführt werden. Und vor allem: sieht billig und bescheiden aus und man hätte überhaupt keinen Vorteil, nur dass es teurer wird (anstelle eines ATmega2560 ein komplettes AT Mega Board).
Wie hoch ist eigentlich die Gefahr den zu schrotten? Da wäre ein einfacher Austausch mit einem Sockel (wie ein SMD-80486 auf PGA-Platine) vllt. eine Lösung?
-
Wieso lässt sich der 82S100 nicht auslesen? Der wird doch unterstützt (siehe CBM PAL, gibt es ein eigenes Kapitel zu).
Hier meine praktische Bestätigung dessen: RE: Der CBM-II&PET als Terminal und die C-900 (aus: Erste Schritte in VAX Pascal)
-
Die MicroUSB Buchse gibt es auch als USB-C Buchse nur für die 5V Spannungsversorgung.
Als THT kann die von jedem gelötet werden. Es gibt auch eine SMD Variante bei der die Pins nach hinten herausgelegt sind. Die nehme ich eigentlich sogar noch lieber, denn wenn man die um 90 Grad biegt, entspricht die der THT Variante, die Pins sind aber etwas länger.
Hallo slabbi, das bringt mich zu der Frage, die ich Dir schon länger stellen möchte. Der Z80 CPU NOP-Tester hat ja auch so eine elegante Micro-USB Buchse zur Stromversorgung vorgesehen. Ich finde aber auch nach längerem Suchen keine Bezugsquelle. Kannst Du da helfen?
Grüße vom Karsten
-
Frage in die Runde:
Ohne alle Beiträge vorher gelesen zu haben, hier mein Problem:
Mit @JoeIBM zusammen habe ich in letzter Zeit oft Apple II und Sinclair Computer repariert.
Dabei haben wir auch immer mal die ROMs von den Apple und einem ZX81 überprüft.
Die Zuordnung im Chiptester ergab dann z.B.: 341-0012 Apple II -J.do
Checksum: xxxxxxx
Weil der ganze Satz ROM bis auf Eines Apple ii -J hieß, haben wir auf der Seite von dem Neuseeländer einen 6er Satz ROMs runtergeladen und in 2716 EPROM gebrannt.
Wenn wir die ROMs in den Chiptester gesteckt haben, dann kam da eine bunte Mischung aus APPLE II, Franklin ACE 1000 und Laser128 raus, laut der Checksumme.
Daher: Kann es sein, dass ein original Apple Ii ROM und ein Laser128 ROM die gleiche Checksumme haben?
Gibt es ein Tool für Linux / Windows mit dem ich die Checksumme der .bin Datei schon vor dem Brennen auf dem PC berechnen kann und dann weitersuchen,ohne x-Mal das EPROM zu brennen ->falsches ROM, weil nicht kompatibel ->EPROM löschen, Suchen, nochmals Brennen, Testen, usw ?
Ansonsten einen Riesen Respekt für den Chiptester Pro. Ich will das Gerät nicht mehr missen.
-
Weil der ganze Satz ROM bis auf Eines Apple ii -J hieß, haben wir auf der Seite von dem Neuseeländer einen 6er Satz ROMs runtergeladen und in 2716 EPROM gebrannt.
Wenn wir die ROMs in den Chiptester gesteckt haben, dann kam da eine bunte Mischung aus APPLE II, Franklin ACE 1000 und Laser128 raus, laut der Checksumme.
Mir sieht das eher aus, als ob ihr da Schwachsinn herunter geladen habt. Gibt es keine zuverlässigere Quelle? Ich hoffe ihr habt die ROMs vorher gesichert?
-
Also:
Ich selbst habe eine Datensicherung von Adrian Black für Apple IIe und Apple II plus.
Die hat mir Adrian von den ROMs aus seinem Apple II plus, den er auf seinem Hauptkanal bei YouTube live repariert hat, gemacht.
Leider läuft der Apple II Rev. 0 von Mike Wilegal nicht und der Apple II Clone läuft damit auch nicht.
Also habe ich gegoogelt und von (fast) jeder Quelle, die irgendwo verlinkt wird und 2k ROMs anbietet jeweils den 6er Pack ROMs heruntergeladen.
Alle ROMs mal gebrannt und in den Chiptester gesteckt.
Nicht 1/4 davon zeigt zur Checksumme auch an Apple II plus.xx (xx von d0 bis f8)
75% der ROMs sind laut Checksumme Franklin Ace 1000, Laser128, Apple II J-Plus oder nach Checksumme nicht zuzuordnen.
Wenn rund 30 Satz ROMs aus 30 verschiedenen Quellen, zu 75% nicht aus dem Apple II sind laut Retro ChipTesterPro, dann sind entweder die ROMs alle gleich und beim Erstellen der ID Liste eben so übernommen worden, von Demjenigen der halt gerade das D0 ROM aus seinem ACE1000 gelesen hat und die Checksumme in die Datei einträgt, oder es gibt wirklich nicht einen einzigen kompletten und 100% autentischen Satz ROMs in dem Teil des Internets,dass ich mit einer großen Hand voll Suchbegriffen mit Google durchsuchen kann
Im Moment habe ich einen Satz ROMs, bei dem nur das F0 ROM aus einem Franklin ACE 1000 ist und Alles Andere aus einem Apple II J-plus.
Allerdings stürzt der Rechner noch ab und an in dem Maschinenmonitor ab.
-
Wenn wir die ROMs in den Chiptester gesteckt haben, dann kam da eine bunte Mischung aus APPLE II, Franklin ACE 1000 und Laser128 raus, laut der Checksumme.
Daher: Kann es sein, dass ein original Apple Ii ROM und ein Laser128 ROM die gleiche Checksumme haben?
Gibt es ein Tool für Linux / Windows mit dem ich die Checksumme der .bin Datei schon vor dem Brennen auf dem PC berechnen kann und dann weitersuchen,ohne x-Mal das EPROM zu brennen ->falsches ROM, weil nicht kompatibel ->EPROM löschen, Suchen, nochmals Brennen, Testen, usw ?
Ansonsten einen Riesen Respekt für den Chiptester Pro. Ich will das Gerät nicht mehr missen.
Ja, oft haben ROMs aus unterschiedlichen Systemen dieselbe Checksumme. Ganz einfach, weil es sich im denselben Inhalt handelt (z.B. Character ROMs).
In der MAME Datenbank sind die dann mehrfach verzeichnet, also z.B.
0x12345678,rom_08.d15, Character ROM XY
0x12345678,rom_08.d15, Character ROM AB
0x12345678,rom_08.d15, Character ROM MN
Der RCT kann aber nur ein ROM anzeigen und nimmt den ersten Fund.
Man müsste die gesamte Datenbank bereinigen und auf den z.B. obigen drei Einträgen einen einzelnen machen:
0x12345678,rom_08.d15, Character ROM AB,MN,XY
Bei 300k Einträgen ist das aber sehr viel Arbeit. Und letztlich ist der Inhalt des ROMs identisch.
Beispiel aus der MAME Datenbank:
0xe47045f4;342-0132-c.e12;Apple //c
0xe47045f4;342-0132-c.e12;Apple //c (Original Memory Expansion)
0xe47045f4;342-0132-c.e12;Apple //c (UniDisk 3.5)
0xe47045f4;342-0132-c.e12;Apple //c (rev 4)
0xe47045f4;342-0132-c.e12;Apple //e
0xe47045f4;342-0132-c.e12;Franklin ACE 2200
0xe47045f4;342-0132-c.e12;Franklin ACE 500
0xe47045f4;342-0132-c.e12;Laser 128
0xe47045f4;342-0132-c.e12;Laser 128 (original hardware)
0xe47045f4;342-0132-c.e12;Laser 128ex (version 4.5)
0xe47045f4;342-0132-c.e12;Laser 128ex2 (version 6.1)
0xe47045f4;342-0132-c.e12;Microprofessor III
0xe47045f4;342-0132-c.e12;Pravetz 8C
0xe47045f4;342-0132-c.e12;Spectrum ED
0xe47045f4;342-0132-c.e12;TK3000//e
".e12" ist das Keyboard ROM. Ist schon erstaunlich, dass es nur so selten verwendet wurde. Bei Character ROMs, Keyboard ROMs, etc. sollte man nicht so auf das System achten. Wenn man wissen will, in welchen Systemen das ROM noch verwendet wurde, dann einmal eine Textsuche in der "MAME full list" durchführen.
Die "MAME full list" enthält noch alle doppelten Einträge, da wird dann der erste Treffer angezeigt. Die "Full list" wurde um doppelte Einträge verkleinert. Da wurden per Skript einfach alle doppelten Einträge gelöscht. Oben würde "Apple IIc" stehen bleiben, der Rest wurde entfernt.
Aber noch einen Hinweis:
Es handelt sich um eine CRC32, kein Hash (wie z.B. SHA1, SHA256 etc). Die Wahrscheinlichkeit einer Kollision ist zwar gering, aber bei 400000 Einträgen ist es durchaus wahrscheinlich, dass eine CRC32 verschiedene Inhalte beschreibt. Mathematiker anwesend?
-
slabbi vielen Dank für den Hinweis.
Um ganz ehrlich zu sein, habe ich gestern bei der ganzen Aktion gar nicht daran gedacht, dass der Inhalt der ROMs wirklich 100% identisch sein kann.
Ist mir irgendwie durchgegangen.
Also werde ich in Zukunft das ROM im RCT Pro auslesen, oder aus der Datei auf der SD Karte die CRC32 Checksumme notieren und die heruntergeladene .bin dann mit CRC32 prüfen um sicherzugehen, dass ich das richtige ROM erwischt habe.
An Alle: Danke für eure Hilfreichen Antworten.
