Posts by lost-bit

zur Not bietet sich auch eine serielle Schnittstelle an. Das kann man dann auch als eine Art token-ring konzipieren, sodass ein com-port pro PC langt

Moin!

ja, das ist aber schon lange her In den 90ern habe ich mit Modula-2 Kontakt gehabt, auf dem PC(DOS) mit dem Topspeed, auf dem Atari ST (das war ein freier Compiler (ETH Zürich/TU München) nicht der bekannte Megamax), Linux mit mocka.

Muss ich heute abend direkt mal nachsehen, das müsste alles noch da sein

Moin,

Du meinst wohl eher Fujitsu, oder? Das Logo "F mit dem Balken drüber und drunter" ist nicht Fairchild.

Wenn ich so in das Datenblatt schaue, sieht mir das aber schon nach Standardbelegung aus.

Eventuell ist das in der Verwendung (also im Layout) anders genutzt bzw. angesteuert worden.

Das kann man dann nur nach dem Auslesen wieder in die richtige Reihenfolge schütteln.

viele Grüsse,

uli

Moin,

Grossartig! Da sag' ich doch mal zu

viele Grüsse,

uli

Moin!

cool, das ist ja nah bei

Aus dem Sun-Lager habe ich nur 2 Sparcstation-20, eine Sparcstation-2 Clone mehr oder weniger in Betrieb. Ausserdem einige Ersatzteile, bzw. Beifang

viele Grüsse,

uli

In Deinem readout vom runtergelötetem Flash war der Bootloader drin. Den habe ich mir mit einem Disassembler etwas genauer angesehen

In dem letzten File (rom2.zip) ist der Loader auch wieder mit integriert.

Hallo,

ja, über das exe-Tool. Nachdem ich wusste wie der Bootloader funktioniert und ich ihm eine Antwort entlocken konnte, war klar, dass eine Menge funktioniert. Die Antwort war auch kein XModem-init, sodass ich einen Versuch mit dem exe-Tool gestartet habe.

Moin,

so, nach etlichen Irrwegen tut das Modem von echo wieder.

ILAH : am Ende war es nochmal ein Flashen mit dem Original-Tool, das dauert eine ganze Weile (bei mir hier etwa 15min) hat aber Fortschrittsanzeigen.

Switche nur 1+2 on, Rest off. Die pdf-Dokus sind ziemlicher Quatsch, an den mittleren Schaltern ist keine Leiterbahn(!)

So konnte ich eine X75 Verbindung aufbauen.

Wenn es noch Probleme gibt, gerne PM

ich könnte noch anbieten, das bei uns auf der Schicht zu löten

Die Daten sind schon ziemlich kaputt. Es gibt keinerlei Strukturen mehr (da hilft dann auch kein Fotorescue).

Es ist nicht einmal sicher, das beide Dateien den gleichen Stand hatten oder wieviel Fehler beim Image lesen noch passiert sind. Ganze Sektoren fehlen jedenfalls in beiden Versionen (s.o.)

Wenn man das sektorweise (bzw. cluster-) betrachtet, fallen schon Unterschiede auf die nicht zusammenpassen. Das kann natürlich auch daran liegen, dass das abgespeicherte Ergebnis (marginal) unterschiedlich zw. ST und IBM war.

So kann man jetzt nur versuchen die Gesamtdatei sektorweise zu rekonstruieren. Da würde ein Ausdruck (o.ä.) des Textes auf jeden Fall helfen.

Die IBM-Fassung hat etwa 1.5x soviel Daten wie die ST Version

Hallo,

ich denke, da muss nichts umgestellt werden. Das Auslesen hat ja genauso funktioniert und die Inhalte passen auch zueinander.

Quote from echo

Bedeutet das, ich soll das rom1.zip in den Flash schreiben und diesen wieder auflöten und testen?

Ein zweiten Inhalt für den anderen Flash sehe ich in deinem Anhang leider nicht.

es muss nur die zweite Hälfte, also alles ab 0x80000 in das Flash. Die erste Häfte ist hoffnungsweise schon in dem Baustein, der nach auf der Platine hockt.

Ich habe es nchmal geteilt, also rom1-2.bin in das Flash schreiben und wieder auflöten...

rom1-geteilt.zip

Moin moin,

ich habe mir die Daten nun auch einmal angesehen

Wie es aussieht habe ich nun auch das passende bin-File (aus 030002.nac) erzeugt.

Allerdings langt doch nicht der einzelne Baustein. Du hast jetzt den höheren Adressbereich ausgelesen. Der Rest liegt wohl noch in dem anderen Flash.

Dein readout passt jedenfalls zu dem angehängten File ab Adresse 0x80000. Es gibt aktuell ein Gemisch zwischen der alten Version und dem abgebrochenen Flashvorgang. Der erste Teil passt schon zum 030002, dann leere Pages und dann noch der alte Inhalt.

Um das wieder zum Laufen zu kriegen wirst Du wohl auch den zweiten Chip runterlöten müssen

Eventuell ist es glücklich verlaufen und wenn Du den High-Bereich neu schreibst und auflötest, geht schon wieder alles, da der Abbruch erst "spät" passiert ist.

VG, uli

rom1.zip

Hallo,

leider kann man nicht die ganze Beschriftung lesen: nicht dass das der reverse-Typ ist. Es sieht zwar nach der Pin-1 Markierung nicht danach aus, aber ....

AM29F400AT-90?C

steht da ein "E" oder ein "F"?

Ansonsten kann ich nur den Test bei mir auf einem Elnec anbieten: da soll xxxxAT in normal und reverse möglich sein. Der Adapter ist auch vorhanden und schon mehrfach erfolgreich benutzt worden.

hier habe ich jedenfalls noch files gefunden

USR :: Product

Hallo,

die, die man direkt bei US Robotics (noch) erbeuten kann, drängen sich nicht so direkt als offensichtliches Image auf

noch ein Nachtrag....

die Bausteine können im 8 oder 16 Bit Modus betrieben werden. Eventuell langt schon U30 herunterzulöten. Mit viiiiiel Glück ist in U31 ein Flashprogramm bzw. Minimal-Bootloader und man könnte mit einem leeren (U30-)Baustein neu starten. Dazu müsste man mal die nBYTE Leitung der Bausteine checken (8/16 bit Betrieb)

Also zuerst nur U30 runterlöten., auslesen....

Moin,

Quote from echo

das runter löten und später wieder drauf, dürfte keine Herausforderung für mich sein und war für mich sowieso klar.

wenn Du die runter hast, würde ich Dir die Dinger auslesen und im Zweifelsfall auch wieder neu flashen. Ich habe den ZIF-Sockeladapter hier.

Die Frage, ob das Image noch zu bearbeiten ist muss natürlich geklärt werden.

Alternativ könnte auch bei einem weiteren Modem die Chips runtergelötet werden und davon ein Image gezogen werden. (Ich habe dieses Modem aber nicht)

Wenn der Flashvorgang schon gestartet hat bevor der Strom ausfiel kann man eventuell sehen was schon im Flash steht und eine Idee kriegen, obe es noch Konvertierungen nötig hat

Moin,

ich würde da eher auf eine defekte Leiterbahn tippen.

Wahrscheinlich gibt es ausserdem irgendwo noch eine Diode, die Batterie- und Netzteilspannung "verodert".

noch ein Nachtrag:

ich habe die EPROM-Dumps noch einmal genauer beguckt. Es sind in beiden sowohl "even" als auch "odd" abgelegt, nur hintereinander angeordnet. Daher

sind auch beide gleich. Der EPROM-Inhalt lag damals nicht so im Fokus und ich hab mich von der Beschriftung irritieren lassen

Wenn die EPROMs beide gleichen Inhalt haben, sollte es nicht am BIOS liegen, da es im 8bit Modus offensichtlich ok ist.

Ansonsten gilt (wie von 6502 schon geschrieben) Sichtung nach anderen HW-Fehlern.

Ein Board-fremdes BIOS halte ich auch für gewagt (s. 1ST1). Auf diesem Board werden z.B. die verschiedenen Clocks aus einem PLL-Baustein erzeugt.

so...

Ich habe noch einmal meine Notizen durchgesehen.

Ich hatte eine Rev.C Variante hier und auch die EEPROMs ausgelesen. Dort war die Version v1.01 drin.

Das BIOS ist etwas seltsam verteilt: in dem Custom-chip (Rev.E IC15) ist das gesamte BIOS enthalten. Wird die Karte nun im 16 Bit Modus betrieben, hilft

eins der EEPROMs aus und liefert den even-Anteil, damit auch BIOS 16 Bit Zugriffe möglich sind.

Warum nun beide(!) EEPROMs (IC16+IC17) exakt den gleichen Inhalt haben ist mir nicht ganz klar. Das konnte ich hier aber verifizieren. Auch die Original-Labelaufrucke bestätigen das.

Also kannst Du nun folgende Tests machen:

a) haben IC16+IC17 den exakt gleichen Inhalt?

b) im 8-Bit-Modus das BIOS von DOS aus auf Disk dumpen und den even-Teil heraussplitten und ebenfalls mit dem EEPROM-Inhalt vergleichen.

Hallo,

ich muss mal nachschauen was ich von dieser Baustelle abgelegt habe..

Hallo nochmal,

der Uhrenchip speichert das Jahr nur mit 2 Bit, also 0..3, das ist vermutlich dem Zählwerk für das Schaltjahr geschuldet (auch wenn das nicht die ganze Wahrheit ist) Damit ist recht spannend wie das Jahr gesetzt wird, 2024 scheint recht logisch, da wir ein Schaltjahr haben und dies 0b00 im Chip entspricht.

Ansonsten würde ich doch mal das 1 Hz-Signal am Chip messen (s.o. #11), das würde immerhin den Oszillator verifizieren.

Quote from fritzwalter

wenn ich die Uhr gestellt habe läuft diese solange der Rechner an bleibt.

Schalte ich ihn aus ist die Aktuelle Uhrzeit weg.

Es gibt genug OS, die nur einmal beim booten die HW-Uhr auslesen und im weiteren Verlauf eine SW-Uhr pflegen. Von daher ist nicht sicher, ob der Chip wirklich seinen Quarztakt hat. Gibt es eine Funktion um direkt die HW-Register auszulesen?

Angeblich soll nach Powerup an Pin 7 ein 1 Hz Signal anliegen. Das sollte gerade noch mit einem Multimeter zu sehen sein Somit könnte zumindest der Oszillator geprüft werden.

Viele Grüsse,

uli

Quote from Betreuung

Das wird eher schwierig, ich lebe in Spanien und habe den ganzen Kram hier.

Oh

das kann ja keiner ahnen...

Alternativ kann das Laufwerk vielleicht an einem Linux-PC mit SCSI-Controller betrieben werden. Damit ist es vermutlich leichter an die (Roh-)Daten heranzukommen.

Quote from Betreuung

Inzwischen ist es mir auch egal, ob auf der Disk noch etwas drauf ist.

wenn es um die Daten geht, kann ich versuchen hier ein Image von der Disk zu erzeugen.. Also das Medium einmal hin- und herschicken

Hallo,

ich habe heute zum Test ein 5,25" MO-Laufwerk an einen PowerMac 6100 angeschlossen. Auf dem SCSI-Bus wurde es sofort erkannt, aber das Treiber-Problem hatte ich auch

Ich habe den o.g. MO DISK MASTER probiert => leider nicht

Auch mit dem MDF-Treiber (https://macintoshgarden.org/ap…ch-magneto-optical-drives) hat es nicht funktioniert.

Erfolgreich war ich am Ende mit Disk Drive Tundeup (https://macintoshgarden.org/apps/disk-drive-tuneup-314) in der Version 3.14.

Damit ließ sich ein (1.3GB) Medium sofort lesen, initialisieren und beschreiben. Ein 650er Medium habe ich leider nicht, sollte aber auch gehen, da das dann eher eine Sache des Laufwerks selbst ist.

Moin,

oder anders herum: Das Medium in einem anderen MO-Laufwerk entweder auch am Mac oder einem anderen System prüfen.

Hallo,

der PC ist ein K6-2 500 MHz auf einem MVP3 Board.

Der Conner hängt mit einer 3.5" und einer 5.25" Floppy auf einem Strang am Onboard FDC.

Linux Distro ist eine alte Slackware 7.0 mit Kernel 2.2.13.

Moin!

ich weiss nicht, ob das Thema noch relevant ist.

Ich habe hier ein (altes) Linux-System mit einem Floppy-Tape noch in Funktion.

Lesen/Schreiben funktioniert mit dem ftape/zftape-Treiber. Das habe ich gerade noch einmal probiert

Das Laufwerk ist ein Conner CTM420 und könnte mit viiiiel Glück das Irwin125-Band lesen. Das Irwin-Gehäuse ist gleich, aber die Bänder selbst sind schmaler (kein 1/4"). Da müsste man einen Versuch wagen (aber natürlich nicht mit dem kostbaren Band, wenn denn leere oder unwichtige Tapes noch vorhanden sind. Bei mir allerdings nicht)

Tapeimages kann ich damit auch erzeugen. Ich habe auch gerade ein paar QIC-tapes (allerdings DC6xxx Typen) auf diese Weise gerettet

Was man nicht unterschätzen sollte ist die Sache mit dem Altern des Mediums. Die Antriebsriemen sind gerne mit der Zeit dahin. Auch ein Ausbacken der

Bänder selbst ist von Vorteil. Ich habe diesen Parcours in den letzten Tagen durchgespielt und würde auch Hilfestellung anbieten bzw. einen Dump

mit meiner Hardware versuchen. Alternativ könnte ich auch ein Laufwerk von dir anbauen und es damit versuchen. Damit sollte zumindest das Kompatibilitätsproblem umschifft werden können

viele Grüsse,

uli