Beiträge von R4M

Die Keyboard LED flackern ein wenig, insbesondere die Caps Lock LED. Diese leuchtet nach einer Weile konstant und ab da passiert nichts mehr. Also schwarzer Bildschirm und auch keine Ausgabe auf ttya.

Sorry, hätte ich etwas spezifischer sein sollen. Ich hab' auto-boot? immer aus, bei mir ist die Kiste gebootet, wenn ich am OpenBoot Prompt bin.

Einmal hatte ich auf ttya die Fehlermeldung:

NVRAM Scratch Addr Test

MESSAGE=Data miss compare

addr ffffffff.f1001d00

exp 55555555.55555555

obs ffffffff.ffffffff

Irgendwie scheint er den Chip da nicht mehr richtig ansprechen zu können. Ohne NVRAM bootet die Kiste ja auch... also wird er den Chip zumindest erkennen.

Da ich gerade meine Ultra 10 offen hatte und die sich immer über den niedrigen Batteriestand in NVRAM beklagt, wolle ich den bekannten Hack mit der externen Batterie machen. Das hatte ich bei der Ultra 1 schon erfolgreich gemacht. In der Ultra 10 klappt es nicht. Sobald ich eine externe Batterie (CR2032) anschließe, bootet der Computer nicht mehr.

Also ich habe folgendes versucht... in keinem der Fälle bootet aber der Rechner

• Einen 1M-Ohm Widerstand vor die Batterie geklemmt, für den Fall, dass die Spannung zu hoch wäre.
• Die "-" Verbindung zur internen Batterie durchtrennt, für den Fall, dass das Problem die noch nicht ganz leere alte Batterie wäre
• Zwei verschiedene Chargen von CR2032

Wenn die Batterie nicht angeschlossen ist, bootet der Rechner problemlos, auch wenn wie oben beschrieben, der Minuspol der alten Batterie abgeklemmt ist.

Hatte jemand sowas schon? Liegt das an dem NVRAM Chip oder an der Ultra 10?

GiH ich hab' mal kurz aufgeschrieben, wie man an beinahe beliebige Debian Versionen kommt.

Installation alter Debian Linux Distributionen für verschiedene Systeme

Wollte ich schon länger mal machen und Du hast mir gerade den richtigen Anlass dafür gegeben.

Da doch immer mal wieder jemand ein altes Linux aufsetzten muss oder will, fasse ich hier mal kurz die nötigen Schritte zusammen. Als Beispiel dient m68k und sparc32

Als erstes ist wichtig, welche Hardware man installieren will. Auf der Seite

https://www.debian.org/ports/

findet man alle unterstützten Ports mit der Angabe, in welchen offiziellen Versionen die Plattform unterstützt wird und ein Link auf weitere Infos. Also "in progress" heißt, dass es aktuelle inoffizielle Builds gibt. Die infos sind aber auch nicht immer up to date. Hppa wird als "discontinued" aufgeführt, obwohl es aktuelle Installer gibt. Also im Zweifel auf den unten aufgeführten Seiten nach Installern suchen.

Sparc32 wird z.B. von Debian 2 bis 4 offiziell unterstützt, Sparc64 bis 8 und aktuell als (sehr guter) unofficial Port.

m68k war von 2 bis 3 offiziell drin, und ist aktuell (seit 9) auch ein unofficial Port ("in progress").

Die Zuordnung der Versionsnummern zu den Release Namen findet man auf der Seite

https://www.debian.org/releases/

Am Ende ist noch zu beachten, dass nicht jeder Debian Spiegel alle Versionen bzw. Installations CDs vorhält.

Alle offiziellen CDs gibt z.B. auf

https://cdimage.debian.org/mirror/cdimage/archive

die inoffiziellen ab Debian 7, also z.B. aktuelle sparc64 und m68k auf

https://cdimage.debian.org/cdimage/ports/

Die letzte offizielle sparc32 CD findet man z.B. unter https://cdimage.debian.org/mir…hive/4.0_r9/sparc/iso-cd/

Die aktuelle inoffizielle m68k CD unter https://cdimage.debian.org/cdimage/ports/10.0/m68k/iso-cd/

Ein Mirror mit allen deb Paketen ist z.B.

https://mirror.eu.oneandone.net/debian-archive/

Ich würde erst die Installation nur mit der Software auf der Installations CD machen und danach den Mirror eintragen. Die im Installer eingetragenen Mirrors haben oft die alten Pakete nicht mehr.

Im Nachgang kann man mit apt-get dist-upgrade die Liste der verfügbaren Pakte holen, das Paket tasksel installieren und dann starten. Das erledigt wie auch im Installer die Grundinstallation, je nach angegebener Aufgabe (Desktop, Server, SSH, Drucker etc).

Wenn man den String "V1 inodes unsupported" googled, bekommt man

http://gparted-forum.surf4.info/viewtopic.php?id=17784

Zitat

You action plan should be:

1) Boot PC using older GParted Live CD, version 0.23.0-1.

(Has xfsprogs 3.2.4, the last version to support XFS with V1 inodes).

2) Use GParted app to identify the the XFS file system.

3) Use GParted app to identify another file system to restore the wanted file too.

(Since your using Windows, I expect it will be either FAT32 or NTFS).

4) Mount the XFS file system.

5) Mount the restore file system.

6) Copy wanted files.

Alles anzeigen

/dev/sdc kann auch nicht funktionieren. Du musst in jedem Fall die Partition, also /dev/sdc1 oder so angeben. Falls er die Partitionen nicht von sich aus findet, kann man mit partprobe nochmal suchen lassen. Evtl. musst Du aber auch erst die entsprechenden Kernelmodule laden.

Kennt fdisk das Plattenlabel?

Eine Sun bootet grundsätzlich von den Sektoren 2-16 (oder so). Da muss FCode drin stehen, der dem Computer dann sagt, was passieren soll. Hat meiner Meinung nach erstmal nicht so viel mit der Partition Table zu tun. Zumindest steht in dem FCode drin, was er mit der Partition Table genau macht und wie er daraus die Bootpartition ermittelt. Vermutlich immer die erste...

Wenn Du von der Platte Solaris booten willst, musst Du daher unbedingt die erste Partition mit "format" unter Solaris anlegen. Wenn (wie bei einem Debian Install) die Daten der ersten Partition schon im dritten Block beginnen und Solaris aber mehr als einen Block FCode zum Booten schreiben will, endet das in einem Datenverlust.

Wenn Du auf der Platte schon etwas drauf hast, musst Du vermutlich

fdisk -w never

benutzen. Wenn fdisk denkt, dass da etwas komisch ist, löscht es gerne Dinge. Wird vorher angekündigt, sollte man unbedingt lesen... und dann eben ggf. die Option "-w never" nutzen.

Wenn die Platte als Device nicht auftaucht kann unter Solaris auch

devfsadm -Cv

helfen. Das erneuert die Einträge in /dev. Siehe https://docs.oracle.com/cd/E23…816-5166/devfsadm-1m.html

Ich würde die Platte vorher mit fdisk bearbeiten. Unter Linux zumindest gibt's in 1.3.0a die Option

create a new empty Sun disklabel

Ich bin wieder etwas weiter. Die Optokoppler sind OK. Die sprechen erst ab ca. 0,6 V auf der Input Seite an. Dann funktioniert zumindest der eine, den ich rausgenommen hatte, wieder ganz normal.

Ich hatte mir so ein billiges Mikroskop für 30 Euro bei Ali gekauft und mir damit eine etwas auffallend dreckige Stelle angesehen

Und auf dem Bild sieht man, was ich auch schon mit dem bloßen Auge vermutet hatte, dass die Dioden da etwas Material gelassen haben.

Da steht quer 17 und dann (wie man im Bild erahnt) senkrecht UA drauf. Hat jemand einen Ahnung, was das für Dioden sind? Gut, vermutlich Schottky, aber spontan kann ich mit 17 UA wenig anfangen. Von den Einheiten her könnte das der Sperrstrom sein, allerdings gibt's bei Mouser keine Schottkys in der Bauform mit um die 17uA Sperrstrom.

Die haben beide (zumindest bei der Spannung des Messgerätes) die selben Werte: 100kOhm in forwärts und 30MOhm rückwärts. Die 100k sind relativ viel, aber da die Dinger für 300V ausgelegt sind, kann das wie gesagt an der niedrigen Spannung des Messgeräts liegen.

Die Dioden sind übrigens nicht die primären Gleichrichter. Es gibt noch eine Diode gleichen Typs wo anders, die noch sauber aussieht. Vielleicht sollte ich die auch mal auslöten und testen, ob die auch die selben Eingenschaften wie die komischen aus dem Bild hat.

Naja, gut, wenn man die Dioden noch bekommt, sollte man die beiden, die schon geleckt haben, vermutlich in jedem Fall austauschen.

Den Siff sieht man von oben erst, wenn's schon sehr spät ist. Etwas früher laufen die Lötpäds an. Ich habe beim Recappen noch keinen Amiga (600/1200) gesehen, wo die Caps noch dicht wären.

Ich wollte auf meiner SS5 Debian4 nach NS3.3 installieren. Das geht interessanterweise nicht, da Debian anscheinend die Partition Table von NS nicht kennt und die Installation dabei praktisch abstürzt. Nur so als Tipp, falls Du parallel etwas anderes installieren willst, solltest Du die NS3.3 Platte vorher abstecken.

Ich hab' jetzt mal etwas weiter gemessen. Auf der Primärseite auf dem Kühlkörper ist neben dem Transistor ein TOKIN Wärmeunterbrecher OHD5R-B (am PCB mit TS101 gekennzeichnet, vermutlich für thermal switch)

https://www.tokin.com/english/product/pdf_dl/sensors.pdf

Der sollte nach Datenblatt ab einer bestimmten (hohen) Temperatur den Stromkreis unterbrechen und darunter einen sehr kleinen Widerstand haben. Das kann man gut in der Schaltung messen... und siehe da, der Widerstand war relativ groß... auslöten... leitet bei Raumtemperatur gar nicht, also vermutlich kaputt. Gut, also für Versuchszwecke eine Drahtbrücke rein... sollte man so nicht wieder in die IPC einbauen, aber zum Testen tut's.

Allerdings hat's nicht viel gebracht. Ich hatte danach mal den Transistor mit dem Oszi gemessen (für Messungen an der Primärseite ist unbedingt ein Trenntrafo erforderlich!). Der Schwingkreis schwingt sich kurz hoch und bleibt dann konstant bei ca. 300V (vorher die Specs des Oszi und der Probes überprüfen!). Das erklärt auch, warum hin und wieder für einen Bruchteil einer Sekunde Strom auf der Sekundärseite ankommt und der Lüfter kurz zuckt.

Kann natürlich jetzt viel sein. Ich hab' mir mal kurz die beiden Optokoppler PC113 (IC103, die andere Bezeichnung ist unter dem zweiten IC) angesehen. Das ist das Regelfeedback von der Sekundärseite zur Primärseite. Hier bin ich mir nicht sicher. Die sollten eigentlich zwischen Pin 1 und 2 eine Photodiode mit V_F (forward voltage) zwischen 1,2 und 1,4 V haben. Beim Messen wird mir allerdings ein unendlich großer Widerstand angezeigt. Hmm... ich hatte noch nie einen Optokoppler nachgemessen, aber das ist zumindest komisch, bei normalen Photodioden hat bekommt man sehr wohl in einer Richtung einen hohen und in der anderen einen niedrigen Widerstand. Wäre allerdings auch seltsam, wenn beide kaputt wären... Die PC113 gibt's auch bei Mouser nicht mehr. Ich werd' mal die TIL113 bei Reichelt ordern... muss da eh mal bald bestellen. Dann kann ich ja zuerst nachmessen, ob die Messwerte der Photodiode normal sind.

Allerdings bin ich mir noch nicht so sicher, ob ich das Netzteil mit den falschen Typen von Optokopplern wieder in den normalen Betrieb nehmen würde. Hoffen wir mal, dass die PC113 nicht kaputt sind. Der Regelkreis sollte schon korrekt funktionieren.

Ach, ja... was noch komisch ist: Auf dem PCB sind die Bezeichnungen der Eingänge der Transistoren abgedruckt... allerdings in allen Fällen, in denen ich das mit den Datenblättern verglichen habe, waren die falsch. Entweder die hatten ganz komische Teilelieferanten oder die wollten, dass die Leute die Finger davon lassen. Naja, also bevor man Transistoren ersetzt, sollte man in jedem Fall genau hinsehen.

Ich bin gerade dabei, den Schaltplan zu rekonstruieren. Gibt auf Hackaday gerade ein gutes Video zum Thema.

https://www.youtube.com/watch?v=dQ9Mh9BbyP0

Die schlechte Nachricht ist schon mal, dass der IC, der den Primärkreis steuert, vermutlich eine Sony Spezialentwickung ist. Jedenfalls ist das kein üblicher IC für PSUs und die aufgrdruckte Bezeichnung findet man in Goole nicht. Wenn der kaputt ist, kann man das Netzteil wahrscheinlich verschrotten.

Hmm... ich hab' mal am Internet gesucht, aber Anleitungen, wie man bei Netzteilen vorgeht, gibt's praktisch nur für alte ATX Netzteile.

https://www.tomshardware.com/reviews/psu-repair,4147.html

Zum Glück habe ich ein semifunktionales von den Dingern daheim. Ich denke, ich werd' mich erstmal mit dem Spielen. Fast alle Anleitungen die ich gefunden habe, Löten einfach nach einem bestimmten Schema Bauteile zum Prüfen aus. Nirgendwo wird beschrieben, wie man die Fehler durch Messung mit einem Oszi einschränken könnte.

Hat jemand eine Quelle für Oszi-Messpunkte? Einen geeigneten Trenntrafo hatte ich zum Glück gleich mit dem Oszi besorgt.

Zitat von escimo

Wie hat du die Ausgaben weggeschrieben? Per Papier + Stift?

Nee... für Papier und Stift wäre das zuviel Arbeit.

Ich hatte die serielle Leitung nicht exklusiv mit gtkterm offen und das kann ein Logfile schreiben. Mit einem Skript hatte ich dann die Befehle direkt an die Console geschickt, also sowas wie echo see $WORD > /dev/ttyUSB0

Zitat von mdx

Um welche Creator handelt es sich denn? Die in meiner Ultra-2 lässt sich einfach per output-device auf verschiedene Auflösungen einstellen.

Das funktioniert tatsächlich! Steht leider nicht im Handbuch zu den Framebuffern.

https://docs.oracle.com/cd/E19…7-0438-10/817-0438-10.pdf

Hab' die Suns erst seit zwei oder drei Monaten... und keinerlei Grundwissen. War aber wie gesagt ein guter Anlass, sich mal näher mit FCode auseinanderzusetzen.

Zitat von escimo

In FFM liegt noch eine Floppy-Halterung nebst Floppydrive. Magst du die - geschenkt - haben? Sonst geht das nächstes Jahr es in den Werkstoffhof. Wäre schade drum, wenn jemand noch das passende Gerät hat.

Die Floppy könnte ich wirklich brauchen. Die in meiner U10 hab' ich bisher noch nicht zum laufen gebracht.

Das ist die Creator FFB2+ aus der Ultra 10. Die Möglichkeit, dass als

setenv output-device screen:r1280x1024x67

zu machen kannte ich nicht. Muss ich mal ausprobieren. Die Values gibt es bei meiner Creator, aber nur, wenn man FCode-debug? einschaltet. Bei der Rage64 auf dem Board sind die Variablen global, verschwinden also unabhängig von der Einstellung nicht.

Im Service Manual der Sparcstation 5 steht übrigens,

Baun: -12 V

Grau: Power off

Wobei Power off leider nicht weiter nicht beschrieben wird. Ich würde mal grob davon ausgehen, dass das in der IPC genauso ist. Garantie gibt's aber natürlich nicht.

Ich hatte heute nun die Kondensatoren des Netzteils meiner IPC ausgewechselt... hat nicht viel gebracht. Hat jemand einen Schaltplan oder zumindest die Belegung des Mainboardsteckers?

Anhand der Molex Buchse für die 5.25" Platte kann man sehen, dass

Schwarz GND

Blau +12V

Rot +5V

ist.

Zusätzlich hat es noch ein braunes und ein graues Kabel. Zwischen den beiden ist auch eine Spannung. Die Frage ist nun, ob das Netzteil da ein bestimmtest Signal braucht um hochzufahren, also ob das Ding zwingend ins Mainboard gestöpselt werden muss, oder ob das Ding auch so hoch kommen müsste. Könnte ja auch sein, dass das Mainboard ein Problem hat.

Weis das jemand, oder könnte jemand das mal bei Gelegenheit ausprobieren, ob ein IPC/IPX Netzteil auch anspringt (Festplatte/Lüfter), wenn der Mainboardstecker nicht eingesteckt ist?

Ja, ich hab mir per serieller Verbindung mit words alle Methoden ausgeben lassen und dann ein Skript geschrieben, das für jedes einzeln see ... aufruft. Wenn man da die Ausgabe mitschreibt, hat man praktisch ein komplettes Listing des Treibers. Darin musste dann eine Funktion sein, die die EDID und SenseID infos in Auflösungen übersetzt. Die sieht man da sofort, ist eine lange Liste mit case Anweisungen.

Ich hab' nur etwas gebraucht um zu merken, dass man Funktionen nach dem Tokenizer nicht mehr global ersetzen kann, da der die Adressen der Funktionen fix in den Bytecode schreibt. Zuerst wollte ich die Funktion rd_monitor_id einfach neu definieren, aber das interessiert den bereits übersetzten Code nicht. Insofern muss man sich eine geeignete Stelle suchen, an der man mit patch weiter kommt. Das überschreibt dann einfach den Code in einer bestehenden Funktion.

Hat so grob 'nen halben Tag gedauert. War aber auch meine erste halbwegs ernste Auseinandersetzung mit FCode. Das nächste Mal wär's deutlich schneller. Zumindest in einem ähnlichen Fall, wo klar ist, nach welcher Struktur im Code man sucht.

Ah... das mit dem select-dev wusste ich nicht. Vielleicht solle man die Dokumentation wirklich mal lesen. Ich denke, das braucht man aber nur, wenn man Methoden aufruft, die auf den Speicher zugreifen. Vermutlich muss da die MMU erst in den richtige Modus versetzt werden. Also als Alternative dazu, für jede Anweisung " /SUNW,ffb@1e,0" " <Anweisung>" execue-device-method eintippen zu müssen, wie ich das oben gemacht habe.

Für patch genügt es, wenn man an der korrekten Stelle im DeviceTree ist. Das ändert ja nur im normalen Speicher den Bytecode.

Für die Console ist 1152x900 schon OK. Aber ich hatte es nicht geschafft, die Auflösung in Xorg zu ändern. Und in X sind dann alle feinen Linien unscharf, wenn die Auflösung nur knapp nicht gleich der physikalischen des TFTs ist und das Ding interpoliert. Nur einen Teil eines 19" 4:3 TFTs zu nutzen ist auch keine zufriedenstellende Lösung.

Wenn man nur Solaris laufen lassen will, braucht man das ja auch nicht. Da gibt's eine Configdatei, die für X mittels ffbconfig die gewünschte Auflösung einstellt.

Man muss dazu

setenv fcode-debug? true

eingeschalten haben, da sonst die nötigen Labels den Fcode Tokenizer nicht überleben. Könnte man sicherlich auch ohne direkt in den Speicher schreiben, wäre aber nochmal Aufwand, die Adresse zu bestimmen. Zudem könnte die stärker von der Version der Grafikkarte abhängen.

Da der Opensourcetreiber die Auflösung nicht verstellen kann und die Karte ohne einen Sun Monitor die Auflösung auf (für TFTs unscharfe) 1152x900 einstellt , habe ich mich mal etwas durch das PROM der Grafikkarte gewühlt.

Für die älteren Grafikkarten ist dies Dokumentiert

https://docs.oracle.com/cd/E19…9-05/6jdmq4ikq/index.html

aber für die Creator 3D gibt es unter Solaris ein Tool (ffbconfig) zum Umschalten und daher ist das bei der Karte nicht vorgesehen. Auch auf dem Web hab' ich nichts gefunden. Da die Programme für OpenBoot alle in Forth geschrieben sind und man die original Funktions- und Variablennamen anzeigen lassen kann, ist es nicht besonders schwer, den Treiber zu hacken. Eine Schande, dass es OpenBoot praktisch nicht mehr gibt.

Die einfachste Möglichkeit ist, die Routine, die die "Sense" Leitungen des 13W3 Monitorkabels abfragt, durch die gewünschte Zahl zu ersetzen.

https://en.wikipedia.org/wiki/DB13W3

http://www.sunhelp.org/faq/FrameBuffer.html

Für 1280x1024x67 (SenseID 4) erstellt man folgendes Skript mit nvedit:

probe-all
dev /SUNW,ffb@1e,0
patch 4 rd_monitor_id set_rt_id
device-end
install-console
banner

Die Kommandos probe-all, install-console und banner dienen dazu, dass das Skript an der richtigen Stelle im Bootvorgang ausgeführt wird ( siehe OpenBoot 3.x Command Reference Manual, Seite 37). Zeite 2 selektiert die Creator Karte im DeviceTree und Zeile 3 ersetzt in der Funtion "set_rt_id" die Funktion "rd_monitor_id" durch den gewünschten SenseID Wert 4.

Nach dem Booten kann man im Wesentlichen das selbe mit folgenden zwei Kommandos im PROM erreichen:

400 500 400 0 0 80 40 " /SUNW,ffb@1e,0" " ffb_change_scrn_params" execute-device-method 
4 " /SUNW,ffb@1e,0" " restart" execute-device-method

Die Methoden kann man nicht direkt aufrufen, da jeder Hardwarezugriff sonst in einem MMU-Fehler endet. Hat etwas gedauert, bis ich auf den oben beschriebenen Umweg gestoßen war.

Ähnlich könnte man auch Auflösungen einstellen, die die Grafikkarte aus den EDID Infos eines Sun Monitors auslesen würde. Da für mich aber SenseID 4 genügt, hab' ich die vermutlich etwas einfachere Route gewählt.

Die Blade 1000 würde mich interessieren. Ohne Covid wäre ich nächstes WE auch in Berlin... wenn Du das Ding nächsten Herbst noch hast, komme ich vorbei.

Die Idee ist im Prinzip gut. Ich halte das 3000er Gehäuse auch für eines der schönsten Desktopgehäuse. Allerdings denke ich, dass die Front das Wiedererkennungsmerkmal ist. Wenn da ein Pi oder ein FPGA-Board rein soll, würde ich zumindest auf die Zorro Erweiterungsöffnungen hinten verzichten... vermutlich auch auf die Floppies vorne.

Ich glaube der Typ, der die Checkmate Gehäuse gemacht hat, wollte auch kleine Varianten rausbringen. Hab' aber keine Ahnung, wo das Projekt gerade steht.

Richtig retro wär's aber nur mit vierstelliger Postleitzahl...

Zitat von Diddl

Aber, für die Amiga EPROMS brauchst du noch eine 2€ Adapter Platine

Die Platine bekommt man für 2 Euro, aber dann fehlt noch der Nullkraftsockel, ein Umschalter für die Bank und ein wenig Elektronik. Insgesamt kommt das schon eher auf 12 bis 20€, je nach gewähltem Sockel.

Ebay müsste günstiger sein. Ich hab' mit allen Adaptern gut 60 Euro mit Versand aus D bezahlt.

Für Amiga brauchst Du zum TL866 noch einen Adapter. Da hätte ich noch PCBs dafür rumliegen.