ROMS (Bios) für Sanyo MBC17plus

  • Nachtrag: Die EPROMs lösche und bespiele ich nicht. Dann wären alle Indizien / Spuren beseitigt.


    Ob die 32kHz Uhr irgend wie einen Einfluss auf den 286 hat? Diesen Oszillator habe ich noch nicht geprüft.


    Bernd

  • Hallo Foristen und Mitfühler,


    eben habe ich die gesockelten dyn. RAMs HYB514256A-70 und die MT1259-10 gezupft. Auch habe ich gleichzeitig den 80287 herausgelöst. Die Sache mit dem Coprozessor wird sowieso immer überbewertet :).


    Alle DIP-Schalter entsprechend gesetzt für no-Co und 512k RAM, anschließend mit den guten 230V den Rechner versorgt - und ...?


    Keine Änderung im Verhalten. Ich habe auch noch einmal alle Karten aus dem sog. Backplane gezogen und die POST card von Nervengift bemüht. Alles verhält sich wie zuvor. Anschließend den Rechner 2 Minuten laufen lassen.


    Schließlich habe ich die Temperatur der eingesteckten RAM gefühlt und festgestellt, dass nichts ungewöhnlich ist, keine höhere Temperatur. Aber komisch ist es schon, dass alle IC etwa Raumtemperatur haben (etwa wie die Tischplatte) und nur der Hauptprozessor 80286 warm ist.


    Mit meinem Messgerät habe ich die Spannungen auch noch einmal nachgemessen: +5V, +12V, -5V und -12V - alle ok. Mich lachten einfach die beiden Elkos auf dem Backplane so an, so dass ich mich motiviert fühlte.


    Dann ist mir beim Resetten am Taster aufgefallen, dass die Led "IRDY" nach dem Reset kurz flackert. Genaues Verhalten: Beim Spannungseinschalten des Gerätes geht die Led kurz an, nach einer halben Sekunde aus. Während Reset gedrückt ist, ist die Led aus, mit dem Loslassen geht sie für etwa 3 Sekunden an, flackert zweimal dunkel und schaltet aus eine kurzen Hellphase von etwa einer halben Sekunde von hell auf dauerhaft dunkel.


    Die Led für Reset folgt genau dem Tastendruck der Reset-Taste, also anschließend dauerhaft dunkel und ohne flackern.


    Jetzt folgt wieder eine Denkpause und lesen von Feedback.


    Gruß


    Bernd

  • Frage an Cartouce:


    Kannst Du bitte irgendwie feststellen, welche Pins am Jumper für den Schlüsselschalter gebrückt oder geschaltet werden? Seit Rückgabe unseres MBC-17 lief er ohne Schalter und ohne angestecktem Kabel, da beides fehlt. Ich habe mir nie Gedanken darüber gemacht, weil es ja lief.


    Jetzt mache ich mir Gedanken, ob nicht vielleicht doch die 3 Pins irgendwie verschaltet sind. Ein Pin ist Masse, mindestens ein anderer zeigt so etwas wie einen kapazitiven Eingang. Der Schalter ist bestimmt nur mechanisch. Aber wissen ist besser als spekulieren.


    Allgemein:


    Dann habe ich heraus gefunden, dass man die PC über das Tastatur-Interface in den Manufacturer Mode setzen kann. Dabei kann man Code laden und Tests durchführen. Hat jemand damit Erfahrung?


    Danke und Gruß


    Bernd

  • Hallo Robert und Cartouce,


    ich habe mir zwischenzeitlich Literatur besorgt und versucht das Wissen zu verbreitern. Hat alle nichts gebracht, da das Sanyo (vielleicht auch Zyrix) BIOS von keinem erwähnt wird. Ich habe vorhin die EPROMs von beiden Systemen über Kreuz getauscht und bin auch nicht weiter gekommen. Euer Board "beept" mit dem alten BIOS, Es gibt so viele Kombinationsmöglichkeiten, die ich leider nicht alle festgehalten habe. Dennoch es bringt mich nicht voran. Mit Eurem BIOS scheint der Prozessor auf Eurer Platine weiter zu laufen, wg. Beep und mit Strg-Alt-Del erfährt er einen Reset. Das macht mein Board nicht, mit keinem BIOS. Ich kann keine Initialisierung der EGA-Grafik-Karte feststellen. DIe Ausgänge der karte scheinen hochohmig zu sein. Auch mit Eurem BIOS läuft kein Signal zur DB9-Buchse, kein Synch, etc.


    Auf meinem Board läuft die Uhr. Das habe ich reverse engineered. Die IC für die jeweiligen Funktionen habe ich mittlerweile identifiziert. Auf dem Board ist sogar noch ein weiterer 8-Bit Prozessor. Ich tippe auf die Tastaturfunktionen, usw.


    Schließlich habe ich das Backplane ausgebaut und durchgeklingelt. Alle Leitungen laufen wir gewünscht. Dann habe ich das Backplane vom Staub befreit und locker/klappernd in das Chassis gesetzt. Ich habe so auf Unterbrechungen durch mechanische Kräfte geprüft. Nix bringts.


    Übrigens ist das Gerät so alt, dass sogar kein "power good"-Draht vorhanden ist.


    Deshalb frage ich nochmal nach, ob Dein Simulator/Emulator etwas zeigt. Wenn ich einen Fehler im EPROM ausschließen könnte ...


    Dann wäre es gut von Euch zu erfahren, wie der Schlüsselschalter funktioniert. Welche Drähte werden gebrückt und ist die Verbindung gleichstrommäßig oder kapazitiv gekoppelt?


    Fragen über Fragen und der Kreis sich zu bewegen wird hier immer enger.


    Gruß


    Bernd

  • Ich habe da noch etwas zu den POST-Karten gefunden:


    http://www.minuszerodegrees.net/misc/post_cards.htm


    Vielleicht hilft das auch noch etwas weiter.


    http://www.minuszerodegrees.net


    Bei Minuszerodegrees dreht sich alles um den IBM PC, XT und AT und auch um ein paar Clones aus dieser Zeit. Vielleicht kann man auf der Seite noch ein paar interessante Dinge finden. Für den XT wird der POST-Prozess zumindest sehr ausführlich beschrieben:


    http://www.minuszerodegrees.ne…0Detailed%20breakdown.htm


    Der Beep an sich ist doch gut und sagt aus, dass das Board an sich erstmal soweit in Ordnung ist? Oder sehe ich das falsch? Das andere Board macht keinen Beep? Also ist an dem Board etwas nicht in Ordnung? Wenn's keine Leiterbahn ist, dann ist es ein Baustein? Nur das dann herausbekommen ... ist doch alles irgendwie Mist. :wand:

  • Dianqi Gongchengshi : Ich konnte die ROMs leider nicht einfach im MAME-Treiber in Betrieb nehmen. Die Ausführung hängt bei beiden Versionen in einer Schleife, wie man hier am MAME-Debugger sehen kann ... ich weiß nicht, auf was die Maschine wartet.



    Bei den ROMs vom Sanyo MBC28 gibt es zumindes das Startbild zu sehen und eine Fehlermeldung, die mitteilt, dass die Busmaus-Schnittstelle nicht gefunden werden kann.


    Der Test in MAME ist also nicht direkt aussagekräftig, zumindest die Sprungbefehle am Ende des Adressraums schauen gültig aus, und dass beide ROMs in der gleichen Schleife landen, lässt auch eher hoffen.


    Gruß

    Robert

    NCR DMV/Olivetti M20/ITT 3030/DEC Rainbow 100/Siemens PC-D/OlyPeople/MFA 8085/TA Alphatronic

  • Dianqi Gongchengshi : Ich konnte die ROMs leider nicht einfach im MAME-Treiber in Betrieb nehmen. Die Ausführung hängt bei beiden Versionen in einer Schleife, wie man hier am MAME-Debugger sehen kann ... ich weiß nicht, auf was die Maschine wartet.

    Der Test in MAME ist also nicht direkt aussagekräftig, zumindest die Sprungbefehle am Ende des Adressraums schauen gültig aus, und dass beide ROMs in der gleichen Schleife landen, lässt auch eher hoffen.


    Gruß

    Robert


    Moin Robert,


    ich behandle beide BIOSe unterschiedlich, da sie eindeutig unterschiedliche Versionen sind. Deine "alte" Version hat im EPROM keine erkennbaren Anzeichen für das Setup-Programm. Bei meiner "neuen" Version findet man diese Zeichen. Dafür habe ich extra die bin-Daten zusätzlich als ASCII-Hex-Dump mit in die zip-Datei gelegt. Jeder x-beliebige Editor kann das lesen. Anhand der gezählten Downloads waren das aber nur sehr wenig Foristen - warum sollten sie auch.


    Ich habe die bin-Datei sowohl im Codeview-Debugger geladen, als auch im normalen Debugger unter DOS. Dann habe ich versucht an der Adresse zu starten, wo die ersten OP-Codes nach dem Power-Up-Reset stehen sollen, d. h. die die CPU als erstes ausführt. Bei mir läuft das Ding ebenfalls los und endet in einer Schleife. Sofern ich das Debuggen direkt auf einem alten PC/AT ausführe, betrachte ich es wie eine Operation am eigen Herzen von mir selbst ausgeführt. Sobald die CPU in den vom Target verwendeten RAM-Bereich schreibt, muss das Target abstürzen. Das ist das Problem. Dann habe ich die bin-Daten in einer DOS-Box verwurstet. Damit stürzt höchsten die Emulation ab. Aber auch hier landet das BIOS in einer Schleife.


    Daher kam meine Frage, ob Du ein lauffähiges BIOS für mich hast. Dann könnte ich meine Untersuchungen mit den unterschiedlichen Debuggern durchführen und prüfen, ob die Vorgehensweise funktioniert und richtig ist. Ich starte den Debugger immer mit dem ersten Byte der letzten Zeile im ASCII-Dump. Also, diese Information enthält die Startadresse. Natürlich lade ich die bin-Datei.


    Kannst Du erkennen, an welcher Stelle im BIOS-Code bei Dir die Schleife hängt? Entweder Du nennst mir die Adresse, die Hex-Byte ziehe ich mir aus dem ASCII-Dump, oder vielleicht kann Deine Entwicklungsumgebung die Anzahl der bis dorthin durchgeführten Codes angeben. Auch wäre ein Dump der Register interessant oder vielleicht auch hilfreich. Bei mir ändern sich die Inhalte nicht mehr in der Schleife.


    Ich glaube fast, bei dieser BIOS-Version werden keine POST-Daten geschrieben. Das Debuggen auf der Target-Leiterplatte war eigentlich auch recht straight forward. Mittlerweile denke ich sogar darüber nach, einen entsprechenden ISA-Stecker zu besorgen und die LP mit 5V zu versorgen und offen auf dem Tisch zu betreiben. Bloß stellt sich die Frage, wie ich binären Daten aus irgend einem Compiler/Assembler an den Prozessor bringe. Immer ein frisches EPROM zu programmieren und einzubauen, wäre echt nervig. Das habe ich vor mehr als 20 Jahren das letzte Mal gemacht, mit dem MSP430 von TI. Ich dachte, diese Vorgehensweise sei mittlerweile obsolet. Alternativ müsste ich mir eine kleine Platine bestücken mit einem elektronischen Umschalter für die Adress- und Datenleitungen. Also wäre das wieder Hardware-Aufwand von mindesten 20 Stunden und Kosten...


    Dass der Prozessor in einer Schleife läuft, habe ich ja oben schon beschrieben, als ich die Anschlüssse am EPROM oszillografiert hatte. Wenn ich so ein BIOS entwickeln sollte, würde ich als erstes die Inhalte des EPROMs anhand einer Methode (z.B. Prüfsumme) verifizieren. Dann erst würde ich mit irgend etwas anderem weiter beginnen, z. B. Speichertest oder Init der Grafikkarte. Auch erst dann würde ich nach außen beepen oder POST-Code schreiben...


    Vielleicht kommen wir doch gemeinsam weiter.


    Gruß


    Bernd

  • Der Beep an sich ist doch gut und sagt aus, dass das Board an sich erstmal soweit in Ordnung ist? Oder sehe ich das falsch? Das andere Board macht keinen Beep? Also ist an dem Board etwas nicht in Ordnung? Wenn's keine Leiterbahn ist, dann ist es ein Baustein? Nur das dann herausbekommen ... ist doch alles irgendwie Mist. :wand:

    Hallo Andreas,


    vielen Dank für Deine Hinweise. Zwischendurch dachte ich, ich würde auf mein Board stoßen - war leider nicht so.


    Das mit den Beeps und dem POST-Code ist ja so eine Sache, wie ich mittlerweile gelernt habe. Einige Rechner schreiben garnicht an Port 80h, sondern vielleicht an 60h, wieder andere Rechner beepen irgendwann für irgendwas.


    Bei mir stellt sich die Sache so dar, dass der Rechner zu Beginn des BIOS irgendwo hängt. Das passiert bevor Peripherie (Grafik, Lautsprecher,...) gefunden und initialisiert werden.


    Was auf dem Board von Cartouce passiert, kann ich nicht nachvollziehen. Die Grafik bleibt ebenfalls aus, ich kann aber über den Affengriff den Rechner resetten. Das spricht für eine Erkennung der Tastatur. Auch gibt es Aktivitäten an den Diskettenlaufwerken. Aber ich weiß z. B. nicht, ob die Leiterplatte mein 5,25 LW erkennt, da ich es Position 2 laufen habe. Ja, ja, könnte ich ....


    Gruß


    Bernd

  • Hi,

    hast Du mal auf das von mir oben gepostete Bild geklickt? Das ist eine animierte GIF, die die Schleife zeigt, in der das ROM hängt.


    Ansonsten hier mal in MAME lauffähige BIOS-Versionen mit der gleichen Dateigröße, wie Deine ROMs und der gleichen Aufteilung in HI/LO bzw. ODD/EVEN ... ob die allerdings auf den Sanyo passen, weiß ich nicht.


    Sie kommen vom Ericsson EWS 286, Kaypro K286i und Commodore PC40. Mit letzterem würde ich an Deiner Stelle mal anfangen, da er als einziger der drei ein integriertes Setup beinhaltet. Das war bei den 286ern noch nicht so gängig.




    Gruß

    Robert

    • Offizieller Beitrag

    Jetzt ist eigentlich der Punkt gekommen mit eine Logicanalysator direkt am Board, Steckkarte zu debuggen. Oder macht ihr das schon und ich habe es überlesen?


    Gruß,

    Peter

  • Hi,

    hast Du mal auf das von mir oben gepostete Bild geklickt? Das ist eine animierte GIF, die die Schleife zeigt, in der das ROM hängt.

    Hallo Robert,


    danke für den Stups! Ich hatte nicht auf das Bild geklickt, da ich nicht wußte...


    Nun werde ich meine Debugger-Kette einmal ausprobieren und dann weiter entscheiden.


    Gruß


    Bernd

  • Jetzt ist eigentlich der Punkt gekommen mit eine Logicanalysator direkt am Board, Steckkarte zu debuggen. Oder macht ihr das schon und ich habe es überlesen?


    Gruß,

    Peter

    Hallo Peter,


    nein, einen Logikanalysator habe ich hier nicht. Ich kann nur mit einfachen Hilfsmitteln arbeiten. Oszi, Multimeter, Hirn, Auge, ... Für HF wäre ich gut ausgerüstet, aber das hier ist pulsierender Gleichstrom.


    Im Filmchen von Robert habe ich die unten stehende Routine mit int(10h) gesehen. Bei meiner Ausführung schätze ich einmal, dass nur das EPROM adressiert werden kann. Aufrufe für int(10h), Dateizugriff und weitere stehen sicher noch weiter hinten an. Soweit kommt mein System wohl noch nicht. Ich müsste noch klären, ob die RAMs adressiert werden. Da ich in der Vergangenheit noch nie dynamische RAMs eingesetzt (verwendet, nicht gesteckt - in diesem Zusammenhang) habe, muss ich auch erst lernen, wie man von der Prozessorseite aus die RAMs anspricht. Sollte eigentlich über ein /wr oder /rd oder /ce laufen. Aber auf der anderern Seite (gedanklich) sind auf dem Board Sanyo-spezifische ICs eingebaut. Diese sind auch so beschriftet. Somit sind für die "Ansteuerbausteine" wahrscheinlich keine Datenblätter im www zu finden. Das sollte nicht ausmachen, sofern ich finde, wie man die dyn. RAMs bedient und dann mit einem Oszi prüfe, ob die Leitungen wackeln. Sollte das nicht so sein, wird entweder dieser Mechanismus fehlerhaft sein oder die ablaufende Software erreicht diesen Punkt nicht.


    Wenn ich es mir so überlege, könnte ein BIOS eines Fremdherstellers vielleicht laufen. Sollte es nicht laufen, gibt es eine Vielzahl von Gründen, warum das nicht so ist. Also wäre ein Scheitern kein konstruktiver Beitrag zur Problemlösung. Klar könnte ich sofort EPROMs oder EEPROMs beschreiben und prüfen, aber ... Und die Lieferzeit über Reichelt beträgt auch etwa eine Woche.


    So folgende Dinge stehen an:

    • bin-Files in meiner Debug-Umgebung prüfen -> Sollte es mir gelingen etwas von einer BIOS-Boot-Sequenz zu lesen, dann funktioniert meine Umgebung zum Debuggen. Dann habe ich das Vorgehen verstanden und kann weitere Schritte planen und das Vorgehen umsetzen. Ich bin mir zur Zeit immer noch nicht sicher, ob ich den Code von der ersten Stelle aus richtig ausführe.
    • Verständnis zur Ansteuerung der dynamischen RAMs erarbeiten. Diese Kenntnis wird zum Oszillografieren benötigt und wahrscheinlich ebenfalls bei einer eigenen Software, die mir meine Debugger/Assembler/Compiler erzeugen (können).
    • Dann schließlich Hardware von Reichelt besorgen.
    • Weitere Schritte aus den vorliegenden Ergebnissen ableiten.


    Ja, da haben wir wieder die wissenschaftliche Vorgehensweise, die einen manchmal auch ausbremst.


    Gruß


    Bernd

    • Offizieller Beitrag

    So, sorry, ich bin leider noch nicht dazu gekommen, mir meinen Sanyo etwas genauer anzuschauen :( Wenn ich aber so sehe, wie tief ihr da inzwischen in dem Thema drinsteckt und was ihr alles schon untersucht habt, bezweifel ich, das ich mit meinem laienhaften Wissen da noch was brauchbares beisteuern kann ...

    Was könnte ich denn noch tun ? Listet doch bitte mal auf ... Von gaaaanz einfach bis einfach ...


    MfG


    Cartouce

  • Ich kann hier nur die Querverbindung zum Test im Emulator beitragen :)

    Hallo Robert,


    ich komme noch einmal durch: Irgendwie habe ich in Erinnerung, dass Ihr zwei von den Sanyos habt. Läuft der andere Sanyo? Könntest du mir bitte von diesem ein Dump des BIOS mit dem Debugger aus DOS erstellen und zusenden?


    Man kann die Ausgabe in eine Textdatei umleiten oder als bin speichern. In meinem Handbuch steht der Speicherbereich für das BIOS im Bereich 0xf8000 bis 0xfffff . Beim Dump in eine Textdatei hätte es den Vorteil, dass ich die genaue Speicherbelegung herauslesen kann. Beim Binär-Dump wird alles nur als Sequenz ohne genauen Speicherbezug geschrieben.


    Für Deine Unterstützung vielen Dank vorab!


    Gruß


    Bernd

  • Hallo Bernd, ich bin wirklich nicht bei den Sanyo-Eigentümern dabei... ich habe nur versucht, testen zu helfen , indem ich die Roms in den Emulator eingebaut habe.


    Gruß Robert

    NCR DMV/Olivetti M20/ITT 3030/DEC Rainbow 100/Siemens PC-D/OlyPeople/MFA 8085/TA Alphatronic

  • Hallo Cartouce,


    wenn Du die Kiste offen hast, bitte sieh Dir einmal den Schlüsselschalter an. Da mir Schalter und Kabel fehlen, würde ich gerne wissen welche Kontakte durch den Schalter gebrückt werden. Mindestens einer der Anschlüsse auf dem Board ist kapazitiv beschaltet. Wenn ich weiß, ob nur Kontakte gebrückt werden (Gleichstrom) und welche, würde ich mir hier einen "Jumper" basteln, statt bei mir dauernd "open" zu lassen. Dies, obwohl es jahrelang auch so ging.


    Auf dem Board von Nervengift übergeben, ist an einem Batterieanschluss ein Kurzschluss-Jumper gesteckt, um die Kontakte zu überbrücken. Nachdem ich das gesehen habe, vermute ich, dass beide Batterien einfach nur hintereinander geschaltet sind. Wenn das so ist, besteht keine Notwendigkeit mehr die 6 Volt Batterie in zwei Teile zu zerlegen. Auch reduziert sich der Lötaufwand. Und es sollte auch fertige Batteriehalter geben.


    Falls Fragen zum Dump bestehen, einfach melden. Wie man die Konsolenausgabe in eine Datei umleitet weißt Du sicher? Bei solchen Sachen arbeite ich gerne mit Batch-Dateien, da man alles nur einmal tippen muss und leicht korrigieren kann.


    Z. B. "dir > vrzchn.dat" leitet die dir-Ausgabe in die Datei. Für die Eingaben ist das "<"-Zeichen zu verwenden.


    Ich hefte hier auch noch einmal die Speicherbelegungsseite aus dem Handbuch an.

    Hallo Bernd, ich bin wirklich nicht bei den Sanyo-Eigentümern dabei... ich habe nur versucht, testen zu helfen , indem ich die Roms in den Emulator eingebaut habe.


    Gruß Robert

    Hallo Robert, das ist schon eine Menge Hilfe!


    Danke an Euch beide für die Unterstützung und Gruß


    Bernd

  • Hallo Robert,


    ich habe alle vorgeschlagenen BIOS-Dateien zusammengefügt und lade sie noch einmal als "Combine" hoch. Vielleicht kann später irgend jemand davon profitieren. Bei mir stürzt die "Entwicklungsumgebung" oder Debug-Umgebung ab. Das liegt vielleicht daran, dass bei "richtiger" Speicherplatzbelegung die Daten sich mit dem eigenen BIOS überlappen. Bei ews286... finde ich übrigens zu Beginn gleich einen Test auf 8086/8088 oder 80286. Da die Codes unterschiedlich verarbeitet werden, liegt der Verdacht nahe, dass der Ersteller des BIOS hier entsprechend der CPU verzweigt. (Mnemonic AAA, falls jemand hier im Thread nachliest und ein ähnliches oder genau dieses Problem lösen will. Aus meiner Sicht ist das Mapping in meiner Umgebung richtig, nur läuft es nicht und stürzt ab.)


    Ich glaube, ich kann diese Art von Debuggen nun abschließen. Interessant wäre jetzt, ob Du von Deinem MBC-17plus das BIOS dumpen kannst, dann hätte ich eine, wenn auch alte Version, die laufen sollte.


    Hat eigentlich die Diskette etwas gebracht, die ich einmal hochgeladen hatte?


    Gruß


    Bernd

  • Bernd, ich habe keinen Sanyo MBC-17plus!


    Das habe ich über mehre Posts jetzt versucht, rüberzubringen.

    Sonst hätte ich doch längst das BIOS ausgelesen und zur Verfügung gestellt, statt dich zappeln zu lassen.

    Ich habe die hier im Thread geposteten zwei BIOS-Varianten auf in den Emulator eingebaut und getestet - leider ohne Erfolg.

    Meine Hoffnung war, dass die von mir gezeigte Schleife auf die Diskette wartet, dem war nicht der Fall.

    Ich werde heute abend nochmal vergleichen, ob die ROMs im Emulator an der richtigen Stelle eingebunden sind, dazu hilft Dein Foto aus dem Handbuch.


    Gruß

    Robert

    NCR DMV/Olivetti M20/ITT 3030/DEC Rainbow 100/Siemens PC-D/OlyPeople/MFA 8085/TA Alphatronic

  • Hallo Robert,


    entschuldige bitte, ich hatte das so verstanden, dass Du und Dein Bruder (?) zwei von den Dingern habt und einer läuft, der andere in Einzelteilen vorhanden ist, von dem ich die Leiterplatte erhalten habe. Es drehte sich doch auch um die Batterie, die noch angeschlossen werden soll.


    Entschuldige bitte, dann ist die Sache mittlerweile ganz einfach.


    Gruß


    Bernd

  • Sag mal Bernd, kann es sein, dass Du bei der Ausgabe Deines selbstgebauten Brenners noch einen "Zahlendreher" bei den Hexziffern hast (most/least significant byte)?

    Ich muss die Dateien "verkehrtherum" (odd/even) laden", damit ich im Debugger Klartext lesen kann ...


    ... noch dümmer gefragt, stecken die Eproms bei Dir richtig herum im Sockel?


    Gruß

    Robert

    NCR DMV/Olivetti M20/ITT 3030/DEC Rainbow 100/Siemens PC-D/OlyPeople/MFA 8085/TA Alphatronic

    • Offizieller Beitrag

    So, bin gerade vor Ort und hab das Gerät mal eingeschaltet / von Diskette gebootet ... :


    - Zum Schlüsselschalter : der steht bei meinem Gerät auf "Offen" - so würde ich das Symbol deuten ... die zwei Adern (rot & schwarz) sind auf dem "CPU-Board" auf den Anschluß CN2 gesteckt - schwarz auf 1, rot auf zwei ...

  • Hast Du eine Möglichkeit, die ROMs auszulesen? Könntest Du bitte ein Foto von der Mainboard/CPU-Karte machen, damit wir wissen, ob die ROMs auf DQ's Mainboard richtig sitzen?


    Danke und Gruß

    Robert

    NCR DMV/Olivetti M20/ITT 3030/DEC Rainbow 100/Siemens PC-D/OlyPeople/MFA 8085/TA Alphatronic