Announcement: there is an English version of this forum on Ich möchte ein batteriegepuffertes RAM aus einem Prema 5000-Multimeter auslesen (dasselbe Problem gibt es z.B. auch bei HP3478A und eigentlich allen Mikropozessorsystemen aus dieser Ära.) Dabei kam ich auf die grundsätzliche Frage: Kann man bei solchen Systemen prinzipiell die CPU ausbauen und dann mit einer eigenen Bastelei auf dem Bus rumspielen? Ich habe nie Z80, 6502-etc. Systeme gebaut, könnte mir aber vorstellen, daß das zum Testen sehr praktisch ist und üblich war, ohne CPU zu starten? Mir geht es dabei erstmal um die Digitalbausteine, die dranhängen. Sind die alle auf Tristate hochohmig und fühlen sich auch sonst nicht angesprochen, wenn die CPU fehlt? Oder kann da bereits etwas beschädigt, gelöscht etc. werden? Meist gibt es ja noch eine Logik für den Chip Select, die muß man eventuell auch lahmlegen. (Der zweite Punkt ist natürlich viel schwieriger bis gar nicht zu beantworten: Was macht das Gerät als solches, wenn die Initialisierung bestimmter Bausteine fehlt. Aber das sei erstmal egal.) Ein Dallas-Ram mit der eingegossenen Batterie kann man ja ausbauen, wenn es gesockelt ist, und mit einer beliebigen Art von Lesegerät bearbeiten. Aber wenn Standard-RAM-Bausteine mit externer Batterie verwendet wurden, geht das nicht. Die Leute nehmen dann einen Logikanalysator, klemmen 30 Klepse an die IC-Beinchen, hoffen auf keinen Kurzschluß und schalten das Gerät ein. Man bekommt so aber nicht zwingend ein komplettes Abbild des RAM. Denn vielleicht wird auf manche Zellen erst am 29. Februar zugegriffen und da muß man jetzt wieder sehr lange warten. (Wenn man Glück hat, wird beim Einschalten das ganze RAM für die eine Prüfsumme gelesen.) Und vielleicht möchte man in manchen Fällen ja auch in das RAM schreiben, dafür fällt der Logikanalysator aus. Für das Prema werde ich mir voraussichtlich jemanden mit einem 16-Kanal-LA besorgen, weil das einfacher ist. Aber ich möchte grundsätzlich wissen, ob auch der Ansatz mit einer eigenen simulierten CPU möglich ist. Vielleicht haben ja sogar die Bastler an Arcade-Automaten sowas erfunden (oder verworfen), denn 10 EPROMs rausreißen nur um sie auszulesen ist aufwendiger als einmal die CPU zu entfernen.
> Sind die alle auf Tristate hochohmig und fühlen sich auch > sonst nicht angesprochen, wenn die CPU fehlt? Oder kann da bereits etwas > beschädigt, gelöscht etc. werden? Wenn du echt die CPU ausbaust dann sind die Eingange natuerlich ungetrieben und floaten lustig rum mit allen Folgen die sowas haben kann. Aber natuerlich kannst du das banal mit einem Widerstand an einer CS Leitung beheben. Vermutlich waer es klueger mal genau im DAtenblatt der CPU zu lesen wo ihre Datenleitungen sind wenn man sie dauerhaft im Reset haelt. VIelleicht eruebricht sich dann ein Ausbau. > Für das Prema werde ich mir voraussichtlich jemanden mit einem > 16-Kanal-LA besorgen, weil das einfacher ist. Und ich haette gedacht es ist einfacher irgendein Microcontroller da eben dran zu knallen den man sowieso rumliegen hat, aber was denke ich schon.... Vanye
Wenn Du ein 6502-System hast, kannst Du (prinzipiell) mit der /RDY-Leitung die Adress- und Datenleitungen hochohmig schalten. Ob Dein Schaltplan das erlaubt musst Du nach gucken und versuchen zu verstehen. Problem ist eventuell auch der dynamische Speicher oder z.B. Video-Ausgabe. Bei Z80 kannst Du prinzipiell BusRQ/BUSACK benutzen um die Adress/Datenleitungen hochohmig zu schalten. Auch hier, das kann klappen oder auch nicht (Refresh vom dynamischen RAM auch zu beachten). Beide CPUs sind nicht unbedingt statisch, bei der NMOS-Z80 war ca. 10 - 50kHz Mindest-Takt. RAM hat uebrigens willkuerliche Inhalte nach dem Einschalten :-)
Vanye R. schrieb: > Und ich haette gedacht es ist einfacher irgendein Microcontroller da > eben dran zu knallen den man sowieso rumliegen hat, aber was denke ich > schon.... Tja, da haben andere schon die Idee gehabt: https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer Ein ATMega32 treibt eine 8-Mhz-Z80-CPU. Bietet Dir CP/M.
Diese Generation hatte meist ein gesockeltes ROM. Gibt Leute, die Game Carts für alte Spielekonsolen bauen. Man kann auch ROM Adressen für I/O missbrauchen. Vielleicht wird es einfacher, wenn du das ROM statt der CPU ersetzt.
offensichtlich willst Du nur U8 auslesen: U6/U7 ist ein ganz Kilobyte RAM, Zeropage und Stack sind schon mal die Haelfte (und muessen bei 0x0000 sein), das Betruebssystem des Messgeraetes muss am Ende des Speichers sein (Startvektoren sind am Ende des Speichers). Du muesstest mal U10 (LS138) analysieren, U8 ist nur 4Bit/1K der in den Adressraum eingemappt wurde.
Am einfachsten waere es wohl, die gut dokumentierten Zugriffssequenzen von Z80/6502 mit einem FPGA nachzubilden. Dann kann man sich per FPGA die gelesenen Daten ganz einfach vom Datenbus pfluecken, und z.B. per RS-232 auf einem Host mitzuloggen. Egal ob es ROM, RAM oder IO ist. Dazu muss man sich nur einen Adapter auf DIP40 basteln. Die 3.3 V Pegel eines FPGA sollten genuegend TTL-kompatibel sein. In Leserichtung waeren wohl Pegelwandler angezeigt. Wenn du der Anwendung eines FPGA nicht maechtig bist, geht es moeglicherweise mit einem Controller mit genug IO. Bei zeitkritischen Sequenzen, z.B. dRAM, koennte das dann aber schiefgehen. Die dritte Moeglichkeit waere ein Monitor-ROM statt der Originalfirmware. Den Monitor muesste man aber an die Zielhardware anpassen. Viel Erfolg!
Den Scan kann man kaum lesen, aber A15/A14/A13 gehen zum Adressdekoder (U10, LS138, selektieren immer 8K Bloecke), U6/U7 (RAM) bei 0x0000-0x1fff (aber nur ein 1k ist belegt, der Rest ist nicht definiert), U16 (68488) ist bei 0x2000, U8 ist bei 0x4000-0x5fff (auch wieder ein 1k, aber nur D0-D3 belegt). ROM ist wohl 0xC000 - 0xFFFF (das 27128 ist ein 16kByte ROM) Prinzipiell koenntest Du die CPU rausnehmen und den Adressbereich 0x4000 - 0x43FF auslesen (die 6502 macht memory-mapped-IO). Kaputt machen im Sinne irreversibel veraendern sehe ich nichts, Du musst aber die obereren Bits maskieren weil U8 nur ein 4bit/1K-Baustein ist und die oberen Bits nicht definiert sind. Die /WE-Leitung von U8 (uPD444) ist auf +5V gezogen (mit 10K), geht irgendwo hin und hat nichts mit R/W der CPU zu tun -> Ich weiss nicht, wie geschrieben wird. Das Schreibsignal (/WE des U8) muss aber mit R/W der CPU mit dem /CE verknuepft werden (d.h. da fehlt was). Lesen sollte immer funktionieren (/CE reicht). Und eine Sache noch: Auf dem Schaltplan 15/3 ist die Zuordnung Adressbits <-> Adressram aufgeschrieben (wenn man den Datenblaetter anguckt, da sind die Adressbits bei den RAMs vertauscht, z.B. A0 von der CPU ist mit A2 beim RAM verschaltet). Zumindest so wuerde ich das interpretieren, und ein Sinn sehe ich nicht so richtig (daher bitte mal mit einem Durchgangspieper pruefen). So, genug geschrieben
:
Bearbeitet durch User
Thomas W. schrieb: > Wenn Du ein 6502-System hast, kannst Du (prinzipiell) mit der > /RDY-Leitung die Adress- und Datenleitungen hochohmig schalten. Ob Dein > Schaltplan das erlaubt musst Du nach gucken und versuchen zu verstehen. Laut Schaltplan ist da RDY mit Vcc verbunden, aber das läßt sich ja ggf. mechanisch ändern. :) Mir fehlen halt 10 Jahre basteln mit solchen Systemen, um mir meine Frage selbst beantworten zu können. So wie ich das Datenblatt verstehe, S. 6, bleibt die CPU mit stabilem Adreßbus stehen. Also sie ist nicht einfach "weg". > RAM hat uebrigens willkuerliche Inhalte nach dem Einschalten :-) Nicht wenn seit 30 Jahren eine Batterie dranhängt, um Kalibrierdaten zu speichern. :) Was im 31. Jahr passiert, wenn die Batterie versagt, kann man allerdings nur schwer voraussagen, daher meine Gedanken zur Sicherung des Inhalts. Thomas W. schrieb: > offensichtlich willst Du nur U8 auslesen: U6/U7 ist ein ganz Kilobyte > RAM, Zeropage und Stack sind schon mal die Haelfte (und muessen bei > 0x0000 sein), das Betruebssystem des Messgeraetes muss am Ende des > Speichers sein (Startvektoren sind am Ende des Speichers). > > Du muesstest mal U10 (LS138) analysieren, U8 ist nur 4Bit/1K der in den > Adressraum eingemappt wurde. Für den konkreten Fall mit dem Prema ist voraussichtlich ein Logikanalysator am laufenden System das einfachste. Es hätte aber seinen Reiz, wenn ich das so wie angedacht mit irgendeinem rumliegenden Arduino machen könnte. Gerade weil es bloß 1024 halbe Bytes sind, die man zur Not mit 10 Kippschaltern und 4 LED auslesen kann. Aus den C64-Heften früher haben wir längere Hex-Listings abgetippt. :)
Thomas W. schrieb: > Den Scan kann man kaum lesen, Es gibt einen besser lesbaren Schaltplan, siehe Anhang, der gehört aber zu einer neueren Gerätevariante, wo das RAM seine Batterie schon eingebaut hat und auch sonst ein paar Änderungen enthalten zu sein scheinen. Aber um eine unlesbare Beschriftung zu entziffern hilft er vielleicht. > aber A15/A14/A13 gehen zum Adressdekoder > (U10, LS138, selektieren immer 8K Bloecke), U6/U7 (RAM) bei (...) > Prinzipiell koenntest Du die CPU rausnehmen und den Adressbereich 0x4000 > - 0x43FF auslesen (die 6502 macht memory-mapped-IO). Kaputt machen im > Sinne irreversibel veraendern sehe ich nichts, Du musst aber die > obereren Bits maskieren weil U8 nur ein 4bit/1K-Baustein ist und die > oberen Bits nicht definiert sind. Zur Not könnte ich U10 auch noch rausnehmen und U8 direkt an seinem /CS ansprechen. Daß ich nur die unteren 4 Bit brauche weiß ich, das zu verarbeiten ist ja kein Hexenwerk. > Die /WE-Leitung von U8 (uPD444) ist auf +5V gezogen (mit 10K), geht > irgendwo hin und hat nichts mit R/W der CPU zu tun -> Ich weiss nicht, > wie geschrieben wird. Das Schreibsignal (/WE des U8) muss aber mit R/W > der CPU mit dem /CE verknuepft werden (d.h. da fehlt was). Lesen sollte > immer funktionieren (/CE reicht). Das ist ein Schutzmechanismus. In dem RAM stehen die Kalibrierdaten, die nicht verändert werden sollen, außer man geht mit einem Schiebeschalter auf der Platine in den Kalibriermodus. > Und eine Sache noch: Auf dem Schaltplan 15/3 ist die Zuordnung > Adressbits <-> Adressram aufgeschrieben (wenn man den Datenblaetter > anguckt, da sind die Adressbits bei den RAMs vertauscht, z.B. A0 von der > CPU ist mit A2 beim RAM verschaltet). Zumindest so wuerde ich das > interpretieren, und ein Sinn sehe ich nicht so richtig (daher bitte mal > mit einem Durchgangspieper pruefen). Ich sehe da nur "A Schmotz" in verschiedenen Fleckgrößen. :) Die Busleitungen sind in dem Schaltplan ja eh zusammengefaßt. Laut der Anleitung wird beim Start das RAM gelesen und so die Prüfsumme gebildet und kontrolliert. Spätestens damit sollte man die Adreßleitugen richtig zuordnen können. > So, genug geschrieben Danke dafür!
Der Schaltplan kann nicht komplett sein: Es fehlt der Clock-Generator der CPU (d.h. Phi_1 [pin 3 Output zum System], Phi_2 [Pin 39 zum System], Pin 37 [Phi_0, Signal zum CPU]). Auch die Syncronisierung R/W - WE zum U8 fehlt, daher kannst Du nicht schreiben (oder sind da nur Kalibrierungsdaten drin? Lesen wuerde ja reichen, und ich nehme mal an, Kalibrieren nur mit Spezialstecker beim Hersteller?) wg. RDY: Ich habe es mit DBE verwechselt (nur bei 6512). Nach 45 Jahren ist halt mein Speicher nicht mehr up-to-date... Und ein bischen ueber die 6502 erzaehlen. Die Junior-Computer-Buecher vom Elektor-Verlag sind anscheinend frei verfuegbar: http://retro.hansotten.nl/uploads/junior/books/de/ElektorJuniorComputerBuchDE1.pdf http://retro.hansotten.nl/6502-sbc/elektuur-junior/elektor-junior-literature/elektor-books/ Vielleicht mal Kapitel 1 ueberfliegen wie ein einfaches 6502-System in den 80-Jahren des vorherigen Jahrhunderts aufgebaut war.
Wollvieh W. schrieb: > Kann man bei solchen > Systemen prinzipiell die CPU ausbauen und dann mit einer eigenen > Bastelei auf dem Bus rumspielen? Das geht selbstredend immer. Wenn man denn genug analysiert hat was man dazu tun muss und dabei nicht den Speicher ausversehen löscht den man so dringend sichern will. Statt dessen das Ram auszubauen und auszulesen scheint mir aber einfacher zu sein. Wenn die versagende Batterie Deine Sorge ist, dann klemm doch bei Betrieb einen Nimh Akku drann mit schwacher Dauerladung über Vcc.
Wollvieh W. schrieb: > Thomas W. schrieb: >> Den Scan kann man kaum lesen, > > Es gibt einen besser lesbaren Schaltplan, siehe Anhang, der gehört aber > zu einer neueren Gerätevariante, wo das RAM seine Batterie schon > eingebaut hat und auch sonst ein paar Änderungen enthalten zu sein > scheinen. Aber um eine unlesbare Beschriftung zu entziffern hilft er > vielleicht. Auf der Seite fuer CPU-Board ist bei dem neuen Modell auch der Clock-Generator zu sehen. Das passt. >> Und eine Sache noch: Auf dem Schaltplan 15/3 ist die Zuordnung >> Adressbits <-> Adressram aufgeschrieben (wenn man den Datenblaetter >> anguckt, da sind die Adressbits bei den RAMs vertauscht, z.B. A0 von der >> CPU ist mit A2 beim RAM verschaltet). Zumindest so wuerde ich das >> interpretieren, und ein Sinn sehe ich nicht so richtig (daher bitte mal >> mit einem Durchgangspieper pruefen). > Ich sehe da nur "A Schmotz" in verschiedenen Fleckgrößen. :) Die > Busleitungen sind in dem Schaltplan ja eh zusammengefaßt. Ja, dachte ich auch. Wenn Du die Daten nur sichern willst, ist das kein Problem (2 x Permutation = Orginal). Wenn Du aber den Rom-Code verstehen musst ist das natuerlich eine Huerde (Z.B. ein String "1234.56" ist fuer die CPU "1234.56", fuer Dich erstmal unlesbar weil die Adresse verwuerfelt sind).
Wollvieh W. schrieb: > Ich habe nie Z80, 6502-etc. Systeme gebaut, könnte mir aber vorstellen, > daß das zum Testen sehr praktisch ist und üblich war, ohne CPU zu > starten? Mir geht es dabei erstmal um die Digitalbausteine, die > dranhängen. Sind die alle auf Tristate hochohmig und fühlen sich auch > sonst nicht angesprochen, wenn die CPU fehlt? Oder kann da bereits etwas > beschädigt, gelöscht etc. werden? Meist gibt es ja noch eine Logik für > den Chip Select, die muß man eventuell auch lahmlegen. Wenn Du so etwas nie selbst gebaut hast, würde ich in so einem speziellen Fall (Kundengerät oder generell ein wichtiges Exemplar) sagen – lieber nicht versuchen, denn schnell ist etwas geschrottet und dann hat man wirklich ein Problem, wo es vorher keines gab oder nicht in dieser Dimension. Ich habe solche kleinen Systeme in minimalistischem Sinne vor mehr als 30 Jahren selbst entworfen und (als Jugendlicher nur für mich) gebaut – 8085, Z80, 68000, 68008 – da gibt es bei jedem dieser Prozessoren andere Tücken und Fallen, wer sie nicht gut kennt, schrottet schnell kollateral etwas. Das ist das eine, das andere ist die veraltete MOS-Technologie – überwiegend mit N-MOSFETs z.B. als HMOS etc. hergestellt – die Teile sind deutlich empfindlicher als die heutige CMOS-Technologie, die z.B. fast überall, wo es geht, integrierte ESD-Schutzdioden beinhaltet. Und noch das dritte: in den Prozessorsystemen waren oft mehrere Master an den Hauptbus angeschlossen, z.B. außer der CPU gab es noch eine DMA-Einheit usw, manchmal sogar in einem anderen Chip quasi versteckt untergebracht, die man im eingebauten Zustand auch noch gut kennen und berücksichtigen müsste – die dürfte dann auf gar keinen Fall eine unkontrollierte Busübernahme starten, wenn man z.B. „von außen” gerade etwas auslesen will. Solche Spielereien am Hauptbus können ganz schnell zu Ende sein; und das komplette Gerät selbst dann auch, weil viele von diesen ICs gar nicht mehr beschafft und ersetzt werden können. Verbieten – solche Versuche zu unternehmen – kann man es aber keinem, da würde ich dann sagen: „viel Glück und Erfolg!”, denn manchmal kann es auch mal zufällig einfach so ohne Hintergrundinformationen und -wissen klappen. Wer aber so ein kleines CPU-System für sich mal nachbauen möchte, um für sich ein wenig forschen zu können und Erfahrung zu sammeln, darf das gerne tun – dann sieht man wenigstens einmal und weiß wieviel in so einem einzigen µC von heute drinsteckt und schon schön im Silizium miteinander verbunden ist (ähnelt ein wenig einer Kleinstadt mit vielen Bezirken, Straßenverbindungen und Stadtteilen). Bei einer nackten CPU muss man sich um all das selbst kümmern und alles erstmal selbst auf einer oder aus mehreren Platine(n) zusammensetzen – das fängt bei der Taktquelle für die CPU – oder generell mit dem Systemtakt – an und geht dann weiter mit der Resetschaltung (beim 68000 mussten es – sofern ich mich richtig erinnere – explizit Schmitttrigger & OC-Gatter sein, also hier schon ziemlich anspruchsvoll gestaltet), einem Adressdrekoder, dem Dekoder für die Steuerleitungen für die Zugriffe auf das RAM, EPROM und I/O-Bausteine, die man auch noch kaufen und an das System selbstverständlich anschließen muss. Dabei habe ich so etwas wie Timer, UART noch gar nicht erwähnt, was aber prinzipiell auch extrem wichtig für die spätere Prgrammierung und Kommunikation mit dem Ding sein dürfte. Und wenn man das ROM in einem SRAM für die vielen Programmierversuche emuliert/untergebracht haben will, muss man dann noch eine Art Bus-Switch in Echtzeit einbauen, um von einem anderen System heraus erstmal das SRAM mit dem Programm zu beschreiben und dann damit auf das eigentliche System umzuschalten – alles unter Spannung natürlich, damit der SRAM-Inhalt nicht verlorengeht. Wenn das alles wegen der parasitären Kapazitäten und langen Leitungen dann noch mit 8MHz läuft, hat man Glück gehabt. Die heutige Arduinogeneration hat in der Regel von dem Aufbau ihres µC, der auf dem Arduino verbaut ist, nicht wirklich viel Ahnung, zumindest nicht darüber wie das dadrin alles zusammenverdrahtet ist oder verdrahtet sein könnte. Auch die TTL-Bausteine, mit denen man alles miteinander verbinden kann, kennen die Arduinojünger gar nicht so, dass sie sie heute sinnvoll für sich nutzen könnten, denn seit alles in einem µController versteckt und verbaut ist, ist es grundsätzlich auch nicht nötig und sinnvoll, irgendetwas von den alten Koteletts zu nehmen und sich damit zu plagen.
:
Bearbeitet durch User
Wollvieh W. schrieb: > Dabei kam ich auf die grundsätzliche Frage: Kann man bei solchen > Systemen prinzipiell die CPU ausbauen und dann mit einer eigenen > Bastelei auf dem Bus rumspielen? Ja, das geht. So habe ich z.B. die eingelöteten ROMs meines HP 8116A gesichert. Du nimmst Dir einen Mikrocontroller mit genügend Pins und baust den Lesezyklus gemäß Datenblatt nach. Bei batteriegepuffertem RAM musst Du natürlich sicherstellen, dass Du nicht aus Versehen einen Schreibzugriff erzeugst. Also den Code lieber erstmal in einer Testumgebung erproben.
Wollvieh W. schrieb: > Ich möchte ein batteriegepuffertes RAM aus einem Prema 5000-Multimeter > auslesen (dasselbe Problem gibt es z.B. auch bei HP3478A und eigentlich > allen Mikropozessorsystemen aus dieser Ära.) So habe ich vor Jahren bei meinem HP3478A die Abgleichdaten aus dem batteriegepufferten RAM ausgelesen, mittels ATmega16 über die RS232 auf den PC. Es gibt beim HP aber auch einen eleganteren Weg über den GPIB, siehe: https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/ Grüßle, Volker
:
Bearbeitet durch User
Volker B. schrieb: > Es gibt beim HP aber auch einen eleganteren Weg über den GPIB, siehe: Bei meinen beiden Geräten habe ich das so gemacht wie dort beschrieben. GPIB-IF angeschlossen, etwas Python-Script und dann hätte ich die Daten. Zurückspielen geht auch, hab ich ausprobiert ;) Falls jetzt die Batterie ausfallen sollte, ist das kein Problem mehr, die Daten dann zurückzuspielen.
Volker B. schrieb: > Wollvieh W. schrieb: >> Ich möchte ein batteriegepuffertes RAM aus einem Prema 5000-Multimeter >> auslesen (dasselbe Problem gibt es z.B. auch bei HP3478A und eigentlich >> allen Mikropozessorsystemen aus dieser Ära.) > > So habe ich vor Jahren bei meinem HP3478A die Abgleichdaten aus dem > batteriegepufferten RAM ausgelesen, mittels ATmega16 über die RS232 auf > den PC. > > Es gibt beim HP aber auch einen eleganteren Weg über den GPIB, siehe: > https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/ Ja, das ist praktisch. Zumal beim HP den Fotos im Netz nach sämtliche Chips verlötet sind. Damit der GPIB-Trick klappt, mußte aber erstmal jemand die undokumentierten Schreib-/Lesebefehle entdecken. Und vorher mußte sie jemand einbauen. Ein doppelter Glücksfall, den man nicht bei allen Geräten hat. Unpraktischerweise müßte ich aber erstmal mit einem Arduino ein GPIB-Adapter bauen, um mir ein Arduino-RAM-Adapter zu ersparen. :) Zum Glück habe ich vor einiger Zeit meine ersten GPIB-Kabel überhaupt gefunden. Die meisten Leute oder Firmen entsorgen die Geräte immer ohne Kabel. Bei denen darf wohl der Lehrling die Stecker abschneiden und dann gibt's ein paar Mark in die Schwarzgeldkasse. Allerdings will ich dann nicht auch gleich eins zerschneiden, um es an den Arduino zu basteln.
:
Bearbeitet durch User
Ich bewundere Euren Tatendrang, habe jedoch noch etwas Zweifel, dass CMOS-RAMs nach 30 Jahren noch ausreichend durch die Stützbatterien versorgt wurden. Oft sahen Leiterplatten an diesen Stellen nach wenigen Jahren Lagerung recht schlimm aus durch ausgelaufene Batterieflüssigkeit. Ob jetzt noch brauchbare Werte im RAM sind? Gib es Fotos? Ist noch Spannung auf den Akkus?
:
Bearbeitet durch User
Angehängte Dateien:
-
F8111114-01.webp
94 KB
Lu schrieb: > dass CMOS-RAMs nach 30 Jahren noch ausreichend durch die > Stützbatterien versorgt wurden. Es geht hier nicht um PCs mit Stützakku sondern um NVRAM mit eingebauten Lithiumzellen. Die sind oft noch nach 40 Jahren lesbar und auslaufen tun die auch nur sehr selten.
Angehängte Dateien:
-
uPD444.png
20 KB
> R/W - WE zum U8 fehlt Die Verbindung wird über den Jumper J9 hergestellt. Wenn der gezogen ist, kann U8 nicht beschrieben werden. Im Lageplan auf PDF-Seite 59 sitzt der über U16, neben J5 und R3. Im Schaltplan S.60 unten links. Datenblatt zu dem RAM µPD444: https://www.datasheetarchive.com/datasheet?id=1073198b21e4073cc0c21c3b93d95c162a3ed6&type=M&term=upd4441 Hat die Batterie noch genug Spannung? Das ist zum Glück kein NVRAM. So eines habe ich mal aufgefräst und eine externe Batterie angelötet. Das war in einer SMD-Lötstation von Pace.
:
Bearbeitet durch User
> Die sind oft noch nach 40 Jahren lesbar und auslaufen tun > die auch nur sehr selten. DAs haengt im uebrigen sehr von der Temperatur ab. Ich kannte mal eine Anwendung wo die Teile immer so nach 8-10Jahren platt waren. Das waren Geraete die 24/7 an waren und immer so 40-50Grad im Gehaeuse hatten. Dort wurde also die Ladung garnicht gebraucht weil die Teile immer fremdversorgt waren. Wenn aber dann doch mal runtergefahren wurde... Die Servicetechniker hatten nach Weihnachten immer eine Stange davon im Gepaeck. :-D Vanye
Thomas W. schrieb: > Problem ist eventuell auch der dynamische Speicher oder z.B. > Video-Ausgabe. Wo siehst du da dynamischen Speicher oder Videoausgabe? Der RAM besteht aus den beiden statischen 2114 und die Ausgabe erfolgt über die gemultiplexte 7-Segment Anzeige.
Mal ne blöde Frage dazu; wenn das Ram gesockelt ist, dazu ne Batterie an Board hat, dann müsste man es doch einfach herausnehmen können, und in einem (adaptierten) Eprombrenner auslesen können. Wo ist mein Gedankenfehler? Viele Grüsse Ove
> wenn das Ram gesockelt ist, dazu ne Batterie an Board hat, > dann müsste man es doch einfach herausnehmen können, und in einem Jo, kann man tun. Wenn es gesockelt ist! Ich hab vor kurzem mal das Ram bei einem TDS3014 ausgebaut um dem entspannt eine neue Batterie zu verpassen. Das Problem bei solchem Messequipment, wegen den oftmals hohen Frequenzen und den hohen Anschaffungspreisen haben die Hersteller da keine Muehen und kosten bei der Platine gescheut. Multilayer mit x Masselagen kein Problem. Das macht das ausloeten zu einer echten Freude... Vanye
> ne Batterie an Board
Das hat nur Oliver mit seinem NVRAM behauptet. Im Schaltplan sehe ich
eine "Li-Batt" die über Diode und Widerstand am RAM hängt. Die ist nicht
eingebaut. Was steckt denn unwiderbringliches in dem RAM?
Christoph db1uq K. schrieb: > Was steckt denn unwiderbringliches in dem RAM? Die (Korrektur-)Werte des letzten Abgleichs (vulgo: Kalibrierung). Blöd, wenn die verloren gehen und man keine entsprechend genauen Signalquellen zur Verfügung hat. Grüßle, Volker
:
Bearbeitet durch User
Der Z80 hat die Anschlüsse BUSRQ und BUSAK. Damit gibt der Prozessor die Hoheit über den Adress- und Datenbus frei und ermöglicht den direkten Zugriff auf andere Bauteile von extern. Der DMA-IC konnte sowas z. Bsp. nutzen.
Wenn das ROM gesockelt ist könnte man ein ROM mit einem 6502-Programm brennen welches einmal den Adressbereich von dem Batterie-RAM einliest und dann entweder a) die Zugriffe per Logicanalyser abgreifen oder b) den Inhalt an einem GPIO seriell raus schreibt.
Volker B. schrieb: >> Was steckt denn unwiderbringliches in dem RAM? > > Die (Korrektur-)Werte des letzten Abgleichs (vulgo: Kalibrierung). > Blöd, wenn die verloren gehen und man keine entsprechend genauen > Signalquellen zur Verfügung hat. Vermutlich sind die Kalibrierdaten nach 30J Betrieb ohnhin nichts mehr wert. Liegen die nicht deswegen im RAM weil man die Kalibrierung regelmäßig erneuert?
G. K. schrieb: > ROM gesockelt 1. Man könntE notfalls Huckepack einen anderen 128er aufsetzen, mit dem entsprechenden Programm und über CS umschalten ... 2. Ob nach x Jahren die Kalibrienungsdaten noch stimmen ???? 3. Bei anderen Ausleseversuchen sollte man an die langsame HW denken! Eine alte Oma ist kein D-Zug, sagte schon meine Oma. 4. Aufwand > Nutzen/Risiko 5. Jetzt würde ich einen Zettel nehmen und die Daten erst mal mit einem anderen guten Gerät vergleichen. Dann könnte man 0,xxx V hinzurechnen. An jeder besseren Uni sollte man dazu Geräte finden.
Lu schrieb: > Andreas M. schrieb: >> Z80 hat > > Es ist leider kein Z80. Ich hatte mich auf die Thread-Überschrift bezogen. Da wird der Z80 mit genannt. Ob der 6502 auch DMA (Direct Memory Access) kann?
Michael schrieb: > Liegen die nicht deswegen im RAM weil man die Kalibrierung regelmäßig > erneuert? Beachte das Baujahr!
Angehängte Dateien:
Wenn das die komplette µProzessor-Schaltung sein sollte, ist dieses Mini-System relativ überschaubar und das Auslesen sämtlicher Daten (auch der des 27128-EPROMs, bei dem nach 20-30 Jahren und je nach damaligem Programmieralgorithmus vielleicht bald ein Bit kippen könnte) müsste machbar sein, sofern man natürlich die Fähigkeiten (Löten und ein wenig 6502-Wissen) dazu mitbringt. Der Adressraum ist schon schön in acht Blöcke mit dem LS138 (der EPROM braucht davon wegen der Größe gleich zwei) unterteilt – somit ist das Ansprechen der Bausteine in den jeweiligen Bereichen über die Steuerleitungen relativ leicht. Man sollte hier natürlich wissen, welche Leitungen auf welche Pegel gebracht werden müssen und nichts floaten lassen, auch nicht die restlichen, höheren Adressleitungen usw. in der Luft lassen, wenn sonst keine Pull-Up/Pull-Down zu sehen sind; und man sollte auch wirklich nur Lese– und keine Schreibzugriffe vollführen, am besten dann auch nur in dem jeweilgen Adressbereich (SRAM und EPROM) – das dürfte aber demjenigen, der die Daten retten will, eigentlich klar sein. Das Risiko eines eventuellen Schadens – z.B. beim Löten, ESD-Pech oder Datenverlust/Datensalat durch Überschreiben auch nur eines einzigen Bytes – muss dann jeder selbst abwägen, denn passieren kann alles.
:
Bearbeitet durch User
Hi Leute, hier mal schauen und evtl. nachfragen. https://8bit-museum.de/neuer-chiptester-fuer-retro-chips/#more-11467 Mit dem MiniPro TL866 geht es leider nicht. Hatte ich schon mit dem M48Z08-100PCI versucht.
Andreas M. schrieb: > Lu schrieb: >> Andreas M. schrieb: >>> Z80 hat >> >> Es ist leider kein Z80. > > Ob der 6502 auch DMA (Direct Memory Access) kann? Der 6502 (NMOS) treibt die Adressbus immer; wenn Du DMA machen wolltest, musstest Du einen 6512 benutzen. Die 6502 hat einen Zweiphasentakt, Ph1_1 und Phi_2. Die Idee war halt dass man bei Phi_1 die Adressen auf den Bus hat und bei Phi_2 die Daten hatte (das passte auch ganz gut zu den Access-times der Bauteile in 1980). Natuerlich konnte man den Takt auch anhalten und Adress/Daten-Buffer dazwischen schalten (z.B. Phi_1 wird fuer Refresh vom RAM benutzt, die Taktfrequenz war bei der 6502 war ja nur 1MHz). Ein "eingebauter" DMA (wie bei der Z80-Familie) war bei der 65XX nicht vorgesehen. Bei der 65C02 (die CMOS-Version) gab es dann ein BE (Bus Enable)-Pin und damit konnte man die Bus-Treiber extern steuern.
Gregor J. schrieb: > Wenn das die komplette µProzessor-Schaltung sein sollte Scheinbar gab es verschiedene Schaltungen. Der TO sollte den Plan nochmals mit seiner Leiterplatte genauer vergleichen. Differenzen habe ich beim Schaltungsdienst Lange auch öfter erlebt.
Ein anderer Weg wäre, die Eproms herauszunehmen oder zu deaktivieren und stattdessen eine kleine 6502-Routine zu erstellen, die dann das Ram ausliest und es nach aussen schleust. Wenn die Speicherblöcke bekannt sind ist das kein Hexenwerk. Technisch wäre das wohl der kleinste Eingriff. Eprom huckepack…
:
Bearbeitet durch User
Angehängte Dateien:
-
DMM-061.png
29 KB -
DMM-062.png
52 KB -
DMMalt-058.png
34 KB -
DMMalt-059.png
85 KB
Mal die originalen Bilder aus dem Handbuch mit poppler-utils extrahiert. Mehr ist da nicht rauszuholen. Der Rest sind Vorverstärker, "Scanner" und Anzeigeplatine. Sind die Bauteile gesockelt, wenn ja welche? Jetzt habe ich beide Handbuchversionen extrahiert, welche trifft zu? Im ersten gab es kein NVRAM, im zweiten schon.
:
Bearbeitet durch User
Lu schrieb: > Ich bewundere Euren Tatendrang, habe jedoch noch etwas Zweifel, dass > CMOS-RAMs nach 30 Jahren noch ausreichend durch die Stützbatterien > versorgt wurden. Oft sahen Leiterplatten an diesen Stellen nach wenigen > Jahren Lagerung recht schlimm aus durch ausgelaufene > Batterieflüssigkeit. Ob jetzt noch brauchbare Werte im RAM sind? Gib es > Fotos? Ist noch Spannung auf den Akkus? Es tut noch Spannung draufsein, sowohl auf dem Prema 5000 als auch dem HP 3478A. Auch auf dem HP 8116A Funktionsgenerator. Bei dem spielt die Speicherung zwar keine Rolle, weil nur die letzten Benutzereinstellungen drin sind, aber dafür gibt es ein gruseliges Reparaturvideo von einem Gerät, bei dem die ganze Platine quer durch verätzt ist. Dort war es aber ein NiCd-Akku, in meiner Variante ist eine Lithium-Batterie drin, die eher nicht so zum Auslaufen neigen. (Klopf auf Holz) Allgemein ist es nicht unüblich, daß ein Gerät von Mitte der 80er nach jetzt 40 Jahren noch all seine Inhalte hat und die Batteriespannung meßtechnisch "voll" bei 3 oder 3,5V liegt. Allerdings kann die Spannung schon morgen zusammenbrechen. Oliver R. schrieb: > Es geht hier nicht um PCs mit Stützakku sondern um NVRAM mit eingebauten > Lithiumzellen. Die sind oft noch nach 40 Jahren lesbar und auslaufen tun > die auch nur sehr selten. Noch schlimmer, es geht um RAM ohne was davor. Ove M. schrieb: > Mal ne blöde Frage dazu; > wenn das Ram gesockelt ist, dazu ne Batterie an Board hat, > dann müsste man es doch einfach herausnehmen können, und in einem > (adaptierten) Eprombrenner auslesen können. > Wo ist mein Gedankenfehler? Daß das RAM gesockelt ist und die Batterie nicht. :) Sprich, die Batteriespannung kommt aus dem Sockel, aus dem Du gerade das RAM entnehmen willst, weil die Batterie auf der Geräteplatine eingelötet ist. Es gibt die spätere Variante dieser Dallas-RAMs, wo die Batterie huckepack aufgelötet ist und dann noch ne schwarze Kappe drüber damit es hübsch aussieht. An die denkst Du vielleicht gerade. Diese Bausteine kann man zum Auslesen natürlich entnehmen. Wenn ich mich recht entsinne, ist die winzige Knopfzelle dieser 90er-Jahre-Bausteine heute meist leer, während die maiskolbengroßen Li-Batterien auf den Platinen aus den 80er-Geräten immer noch Dampf haben. Lu schrieb: > Scheinbar gab es verschiedene Schaltungen. Der TO sollte den Plan > nochmals mit seiner Leiterplatte genauer vergleichen. Differenzen habe > ich beim Schaltungsdienst Lange auch öfter erlebt. Nicht nur scheinbar, sondern zunächst anscheinend und dann tatsächlich. :) Ich habs auch oben erwähnt, daß es für das konkrete Prema 5000 verschiedene Varianten gibt. Für die allgemeine Diskussion, wie man mit solchen RAMs umgehen soll/kann, ist das aber nicht so wichtig. Rainer W. schrieb: > Thomas W. schrieb: >> Problem ist eventuell auch der dynamische Speicher oder z.B. >> Video-Ausgabe. > > Wo siehst du da dynamischen Speicher oder Videoausgabe? > Der RAM besteht aus den beiden statischen 2114 und die Ausgabe erfolgt > über die gemultiplexte 7-Segment Anzeige. Die hat er vermutlich in anderen Systemen gesehen :), es soll ja eine allgemeine Diskussion sein. In dem konkreten Prema 5000 gäbe es wahrscheinlich keine Probleme, aber trotzdem kann natürlich irgendwas spezielles dranhängen, was aus dem Schaltplan nicht so klar hervorgeht. Gerade in den 80ern hat man ja gerne was neben der Regel gebastelt, um ein paar Bausteine zu sparen oder sonst etwas bestimmtes zu erreichen.
Angehängte Dateien:
-
caphat_snaphat.png
34 KB
> Batterie auf der Geräteplatine eingelötet Das beantwortet indirekt meine Frage, es ist also kein NVRAM, sondern das ältere Handbuch trifft zu, mit einer externen "Li-Batterie", vielleicht eingelötet aber frei zugänglich. > Dallas-RAMs https://de.wikipedia.org/wiki/Dallas-Chip Hier verlinkt eine Anleitung mit Fotos des geöffneten ICs: http://web.archive.org/web/20160927074523/http://reocities.com:80/SiliconValley/peaks/8491/rtc_de.html Ebenfalls verlinkt: http://www.mcamafia.de/mcapage0/dsrework.htm auch hier ein Foto "After the dust cleared". Epoxid-Staub soll ungesund sein, aber ich habe es bisher überlebt. Im oben gezeigten NVRAM 48Z35 von ST ist die "Batterie" fest im IC eingegossen. Das kann man auch nur noch (wie ich es selbst getan habe) auffräsen und mit etwas Glück die Anschlüsse mit einer externen "Batterie" verbinden. Im neueren Schaltplan ist ein 48Z02 gezeichnet, das dürfte ein kleineres NVRAM derselben Art sein. https://www.st.com/resource/en/datasheet/m48z12.pdf ST hatte zwei Markennamen CAPHAT™ M48Z02 (1999-2020) und TIMEKEEPER® M48T02 (2000-2011) https://www.st.com/en/clocks-and-timers/rtc-parallel-interface-timekeepers.html da ist die Batterie trennbar, Videoausgabe und Dynamisches RAM kann ich auch nicht finden, das muss Thomas geträumt haben.
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > die "Batterie" fest im IC eingegossen. Das kann man auch nur noch (wie ich > es selbst getan habe) auffräsen Das würde ich vorsorglich erst mal an Schrott üben wollen, bevor es schiefgeht!
Christoph db1uq K. schrieb: > > Videoausgabe und Dynamisches RAM kann ich auch nicht finden, das muss > Thomas geträumt haben. Oh Mann, besser haette ich das gelassen, dann waere nichts passiert: Im Betreff hiess es (allgemein) Z80/6502 Systeme auslesen. Und bei den Geraeten der 80'er Jahre des letzten Jahrhunderts war es haeufig dass z.B. der Video-Speicher in den Hauptspeicher gemappt wurde (man brauchte kein Terminak, und man konnte Graphik machen. Fuer relativ wenig Geld und Aufwand). Und bei den "Homecomputer" (Apple ][, TRS-80 Model 1/2) wurde der Hauptspeicher mit dynamischen 4116/4164-Chips dargestellt. Refresh war damals ein Problem. Das sind alles Problembereiche wenn man die Maschine anhalten will oder muss. Den Anhang mit dem Prema-5000 habe ich doch noch gar nicht gesehen! Ihr seid aber auch lustig: Der TO will einfach nur die Kalibrierdaten auslesen und speichern, mehr nicht. Ein Geraetumbau (Austausch des Akkus mit was-auch-immer) steht doch gar nicht zur Debatte, der TO hatte so gar im ersten Beitrag hingewiesen, dass die Geraete noch funktionsfaehig sind. Und der Schaltplan zeigt doch, wo der Akku haengt (OK, den Jumper J1 auf der linken Seite habe ich nicht richtig gesehen). Und ja, ich habe damals die Schaltplaene der "Homecomputer" (ich hatte einen TRS-80 zu Hause, in der Schule hatten wir einen Commodore PET [die Gummi-Tastatur hat einen Monat Space-Invader durchgehalten]) analysiert und versucht zu verstehen. Gruesse
Dann geht auch noch das hier: 1k Widerstand in Reihe mit Vier kleinen NiMhs zwei dünne Strippen an die Pins Vcc/Vss gelötet, raus aus der Schaltungen und mittels Eprombrenner ausgelesen.
Thomas W. schrieb: > Ein "eingebauter" DMA (wie bei der Z80-Familie) war bei der 65XX nicht > vorgesehen. Der Z80 war also INTEL-ligenter.
Andreas M. schrieb: > Thomas W. schrieb: >> Ein "eingebauter" DMA (wie bei der Z80-Familie) war bei der 65XX nicht >> vorgesehen. > > Der Z80 war also INTEL-ligenter. Das wird jetzt ein wenig ausarten: die 65XX-Reihe von MOS-Technology war billig designed und gebaut. Das Ding war im wesentlichen als CPU fuer preisguenstige Consumergeraete gedacht, und da war das Ding sehr erfolgreich (denke mal an Commodore [der Pet2001 wurde 1977 fuer US$800 {entspricht 2022 US$3800} verkauft, hatte aber Tastatur, Schirm, Massenspeicher, Basic-Interpreter mit Editor in einem Gehaeuse] oder der Apple ][). Auch das Konzept der Zeropage (256 Bytes sehr einfach und schnell anzusprechen -> eine Art Registerbank) fuehrte dazu, dass die 6502 relativ schnell war (fuer 1MHz). Ein sehr einfacher Befehlssatz, sehr schnelle Ausfuehrung (sehr viele OPCodes brauchen nur 1 - 2 Takte), eine Art Pipeline. Das war 1975 schon innovativ. Die Intel-Loesung zu der Zeit (der 8080) waren technologisch nicht so einfach (in 1974): Die 8080 brauchte drei Spannungen (+/-5V, 12V), brauchte zwei zusaetzliche ICs (Taktgenerator 8224, Bus-Controller 8228) um ein minimales System zu bauen. Das Interrupt-System war auch ausgelagert (8259). Dementsprechend waren die System komplex und teuer (Altair 8800 kostete US$621 in 1975, Kaufkraft waere heute US$3400, aber brauchte ein Terminak und Massenspeicher). Die Z80 (1976 entwickelt) brauchte nur eine Spannung, mehr OpCodes, das Interrupt-System, DMA (oder Bus-Master)-Konstrukt, die zweite Registerbank. Und Kompatibilitaet mit 8080-Code. Das war natuerlich ein grosser Vorteil gegenueber Intel. Ein kleiner "blast from the Past": https://commons.wikimedia.org/wiki/File:Trinity77.jpg Schoen war die Zeit.
Thomas W. schrieb: > Auch das Konzept der Zeropage (256 Bytes sehr einfach und schnell > anzusprechen -> eine Art Registerbank) fuehrte dazu, dass die 6502 > relativ schnell war (fuer 1MHz). Ein sehr einfacher Befehlssatz, sehr > schnelle Ausfuehrung (sehr viele OPCodes brauchen nur 1 - 2 Takte), eine > Art Pipeline. Das war 1975 schon innovativ. In einem Wort: RISC.
G. K. schrieb: > In einem Wort: RISC. Richtig, da fanden diese Philoshopien ihren Anfang. Der 6502 macht einen Buszugriff pro CPU-Takt und hat damit kurze einfache Befehle, allerdings noch ohne die Symmetrie, wie wir sie von heutigen RISC-Architekturen kennen. Der Z80 braucht ein Dutzend Takte für jeden Befehl, weil er innendrin nochmal so eine Art Maschinencode ausführt. So kennen wir das von den heutigen Intel- und AMD-Desktop-Prozessoren, das sind klassische CISC-Architekturen. Als Faustregel kann man rechnen: 1 MHz 6502 sind 5 MHz Z80.
Soul E. schrieb: > G. K. schrieb: >> In einem Wort: RISC. > > Richtig, da fanden diese Philoshopien ihren Anfang. Der 6502 macht einen > Buszugriff pro CPU-Takt und hat damit kurze einfache Befehle, allerdings > noch ohne die Symmetrie, wie wir sie von heutigen RISC-Architekturen > kennen. Der Z80 braucht ein Dutzend Takte für jeden Befehl, weil er Vor allen Dingen war die 6502 nicht mikroprogrammiert: Es gab (auf dem Chip) ein unglaubliches Steuerwerk (fuer 1977!) deswegen kurze Ausfuehrungszeiten. Die Z80 war (fuer einen Mikroprozessor) sehr komplex mikroprogrammiert, deswegen hatte es unglaubliche lange Ausfuehrungszeiten. > innendrin nochmal so eine Art Maschinencode ausführt. So kennen wir das > von den heutigen Intel- und AMD-Desktop-Prozessoren, das sind klassische > CISC-Architekturen. Richtig klassisch ist (Tata:) die Vax-Architektur oder 68000. Da sind Adressierungsarten implementiert die man sich kaum vorstellen kann (z.B. Increment von referenzierten Speicher mit Offset). Da braucht man natuerlich Takte um die Daten hin und herzuschieben.
Der Z80 war intelligenter, weil er durch die Busfreigabe (BUSRQ/BUSAK) andere die Arbeit machen lassen konnte. :D
:
Bearbeitet durch User
Andreas M. schrieb: > Der Z80 war intelligenter, > weil er durch die Busfreigabe (BUSRQ/BUSAK) andere die Arbeit machen > lassen konnte. :D Das konnte die 8080 auch...
Angehängte Dateien:
-
IMG_6014.jpeg
370 KB
@TO Man kann sich mit einem STM32 eine Ersatz Z80-CPU bauen und an Stelle des Z80 in den Sockel stecken. Der Rest ist dann eigentlich nur FW von diesem Teil. Ich habe sowas für ein Retroprojekt, allerdings in der umgekehrten Richtung, also nicht zum Auslesen, sondern zum Programmieren des Speichers. Das Teil kann den Speicherinhalt natürlich auch auslesen
Um mal von der Geschichtstunde zum ursprünglichen Thema (simulierte CPU zu Fehlersuche/Speicher auslesen) zurückzukommen: Man findet Projekte, wo jemand einen Arduino Mega als simulierte Systemumgebung für den Test eines 6502 verwendet hat. So rum geht es also, ist aber mit den neueren CMOS-Versionen einfacher, weil man die komplett anhalten darf. Umgekehrt sehe ich das Problem mit dem Takt: der 6502 läuft mit 1MHz, der Arduino mit 16MHz. Das ist zwar schneller, aber nicht so viel schneller, dass man viel machen könnte. Ob das ein Problem ist, hängt vom konkreten System ab.
Soul E. schrieb: > und hat damit kurze einfache Befehle ADC (xx),Y als einfachen Befehl zu betrachten, ist mutig. Wenn du eine damalige Architektur mit einfachen Befehlen suchst, um unbedingt den Begriff RISC zu verschütten, dann nimm RCAs 1802.
:
Bearbeitet durch User
Beitrag #7615399 wurde vom Autor gelöscht.
Andere Idee: Der FTDI FT2232D hat einen CPU-Modus, in dem er einen 8080 Bus mit AD0-AD7, A8-15, !WR, RD! und ALE bereitstellt, praktisch wie ein AVR mit EBI (Mega 128*/256* z.B.). Zum Demultiplexen braucht man das übliche HC373 Latch. Im Gegensatz zum neueren FT2232H kann der FT2232D auch noch mit 5V IO-Spannung arbeiten. fchk
:
Bearbeitet durch User
Thomas W. schrieb: > Andreas M. schrieb: >> Der Z80 war intelligenter, >> weil er durch die Busfreigabe (BUSRQ/BUSAK) andere die Arbeit machen >> lassen konnte. :D > > Das konnte die 8080 auch... Der ist eben auch von Intel und nicht von MOS.
Jetzt noch mal fuer das Prema-5000 zurueck komme: Gegeben das einfache System, entferne je nach Sockelhaftigkeit die CPU oder den LS138, benutze einen Arduino Mega, klemme die zehn Adressleitungen, die vier Datenleitungen und ein /CE an und gut ist. Beim Nachfolgemodell (der TO hatte das Manual gepostet, schoen das Prema verschiedene Geraete mit gleichen Namen und verschiedenen Innenleben verkauft) ebenso. Nur halt acht Datenleitungen und elf Adressleitungen. Eine allgemeine Loesung gibt es glaube ich nicht: Ich erinnere mich noch an Beitrag "Hilfe bei Z80 Opcodes", eine Reifenwuchtmaschine, Konfigurationsdaten mit I2C-RAM (an Z80-PIO), Akku alle, Maschine sehr eingeschraenkt nutzbar(*). Deswegen verstehe ich den TO: eine alte Kalibrierung ist besser als gar keine. (*) In dem RAM waren eine Information gespeichert welches Options-EPROM eingebaut war. Reine Schikane.
Thomas W. schrieb: > entferne je nach Sockelhaftigkeit die CPU oder den LS138, > benutze einen Arduino Mega, klemme die zehn Adressleitungen, die vier > Datenleitungen und ein /CE an und gut ist Den LS138 zu entfernen mit der dringelassenen CPU (oder auch ohne diese) und es dann so wie beschrieben versuchen auszulesen ist keine so gute Idee.
:
Bearbeitet durch User
Gregor J. schrieb: > Thomas W. schrieb: >> entferne je nach Sockelhaftigkeit die CPU oder den LS138, >> benutze einen Arduino Mega, klemme die zehn Adressleitungen, die vier >> Datenleitungen und ein /CE an und gut ist > > Den LS138 zu entfernen mit der dringelassenen CPU (oder auch ohne diese) > und es dann so wie beschrieben versuchen auszulesen ist keine so gute > Idee. CPU drin lassen ist bloed, sehe ich ein. Aber wenn CPU draussen, LS138 draussen, dann habe ich den /CE am Sockel. Habe ich etwas uebersehen? /WE ist latuernich auf Log.1.
Thomas W. schrieb: > Habe ich etwas uebersehen? /WE ist latuernich auf Log.1. Kann man anhand des Schaltplans erkennen, dass es keine so gute Idee ist – wenn man so etwas selbst nie gebaut hat oder einem die praxisnahe Erfahrung damit fehlt, ist es natürlich deutlich schwieriger, es – oder generell die Zusammenhänge der TTL-Logik des Schaltplans – zu erkennen. Auch die möglichen Folgen bestimmter, selbsterfundener Eingriffe sieht man dann nicht.
:
Bearbeitet durch User
Nun muss ich doch mal fragen, warum der OP eigendlich diesen Aufwand betreiben will, um an die Daten im Ram zu gelangen. Bei Prema findet sich im Downloadbereich das Servicemanual zum Gerät. darin ist beschrieben, wie man eine digitale Justage durchführt. Das ist machbar und bezahlbar. Es gibt einige Kalibrierfirmen, die das mal eben gegen Münzeinwurf machen. Ich behaupte mal, das ist für unter 150€ machbar. Dafür würde ich nicht Gefahr laufen, ds schöne Teil zu schrotten! Viele Grüsse Ove
Angehängte Dateien:
-
IMG_7552.JPG
230 KB -
IMG_7553.JPG
230 KB
Soul E. schrieb: > Ja, das geht. So habe ich z.B. die eingelöteten ROMs meines HP 8116A > gesichert. Du nimmst Dir einen Mikrocontroller mit genügend Pins und > baust den Lesezyklus gemäß Datenblatt nach. Im Anhang ein paar Bilder des Aufbaus. Der 6802 war gesockelt, die EPROMs eingelötet. Kalibriert wird hier mechanisch, das Backup war nur für Didier KO4BB.
Angehängte Dateien:
-
100euro-muenze.jpg
32 KB
Ove M. schrieb: > Es gibt einige Kalibrierfirmen, die das mal eben gegen > Münzeinwurf machen. Ich behaupte mal, das ist für unter 150€ machbar. Der Münzeinwurf muß aber etwas breiter sein, siehe Anhang. Wenn ich jedes gefundene Meßgerät für nur 150 Euro kalibrieren lassen würde, könnte ich mir nicht nur keinen Ferrari, sondern nichtmal keinen Porsche leisten. Ich könnte dann wahrscheinlich nichtmal mehr den Strom zahlen um einige der Geräte in Betrieb zu nehmen. :) Warum wechseln Leute die Reifen an ihren Autos selbst, obwohl es doch Firmen gibt, die das machen? > Dafür würde ich nicht Gefahr laufen, ds schöne Teil zu schrotten! Deshalb wird hier ja lang wie breit überlegt, ob und welche Gefahren dabei bestehen. Mittlerweile sieht es so aus, daß wenn man es richtig macht, die einzige Gefahr wäre, die Kalibrierdaten zu verlieren, ohne daß sonst etwas beschädigt wird. Und das ist auch schon Leuten passiert, die nur die Batterie wechseln wollten. Einer schrieb, daß ihm beim Anlöten einer zusätzlichen Pufferbatterie plötzlich die Spannung der originalen Batterie zusammenbrach und der RAM-Inhalt futsch war. Mutmaßliche Ursache war, daß der Pufferkondensator durch die Löttemperatur niederohmig geworden war. Natürlich könnte auch die Diode hochohmig geworden sein. Diese Gefahr des Datenverlusts dadurch vermeiden zu wollen, daß man das Gerät von vorneherein zum Kalibrierdienst bringt, ist Selbstmord aus Angst vor dem Tod. Ich habe noch eine Geräteklasse mit gepuffertem RAM entdeckt: Waagen. Eine Precisa von ca. 1989 hat einen 80C31 und einen NiCd-Akku, der platt ist. Die Waage hat zwar ein internes Kalibiergewicht, aber dem Servicemanual nach werden auch Einstellungen zur Ecklast/Symmetrie gespeichert, und das geht nur mit mehreren externen Gewichten. Außerdem ist das so ein Superduper-Ding im zig-µg-Bereich, wo man Kalibriergewichte braucht, die man gar nicht mehr anfassen darf. Es könnte sein, daß der RAM-Verlust der Grund ist, warum die Waage sich nicht einschalten läßt. Denn "OFF" erscheint auf dem Display, der Ein-Taster funktioniert elektrisch, und wenn man einen Service-DIP umlegt erscheint "88888" auf dem Display. Also digitalseitig spricht nichts dagegen, daß die Waage anginge. Andererseits würde ich eine Fehlermeldung erwarten, und sei sie auch noch so knapp. Leider gibt es keine Bedienungsanleitung im Netz und das Servicemanual enthält zwar die Schaltpläne, aber sonst trotzdem nicht viel. Diese Waage scheint mir eine Spezialität zu sein, denn bei allen anderen Waagen mit dem Tauchspule-LM399H-AD-Wandler-VFD-Anzeige-Prinzip aus der Zeit die ich kenne wird mit Trimmern kalibriert. Spätere Modelle mit LCD haben dann gleich EEPROMS.
:
Bearbeitet durch User
Wollvieh W. schrieb: > RAM aus einem Prema 5000-Multimeter habe nicht den ganzen Thread gelesen, hoffe aber, dass Du nicht vorhast, dieses edle Gerät zu kannibalisieren wenn es noch funktioniert. Die Dinger werden in der Bucht für 350€ bis 500€ gehandelt.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.