Beiträge von manawyrm

    Hab mal nen paar neue TMUs besorgt

    Urgh.


    Also:

    Neue TMUs bekommen.

    TMU getauscht -> gleiches Fehlerbild ;(

    alte TMU auf ne andere Voodoo aufgeloetet (aka meine komische alte, verbastelte AT25) -> funktioniert korrekt


    Also ist wirklich entweder der FBI kaputt oder das PCB. *seufz*

    Ich halt' mal die Augen nach ein paar FBI's offen, aber das sieht nicht gut aus.

    Moin!


    Sehr spannendes Vorhaben und willkommen hier im Forum :)

    Mach doch gern mal einen Thread zum Schaetzchen auf und dann findet sich bestimmt ein guter Rat!

    Ich kämpfe mit einem 386er-Board (Neuzugang), das Teil läuft soweit, DOS 6.22 neu installiert - aber: größere Programme (Vermutung >64KB) lassen das Board sich aufhängen. RAM, VGA und Controller, Netzteil etc. habe ich mit anderen Boards verwendet und auch schon durchgetauscht, will nicht - fällt da jemandem was dazu ein?

    Hat das Board Cache? Wenn ja: Bau mal aus (wenn moeglich), oder schalt aus.


    edit: sowas aehnliches hatte ich auch schon mal mit kaputtem ATA-DMA, kannst du ein anderes Speichermedium testen?

    Hab mal nen paar neue TMUs besorgt, kann man ja immer gebrauchen, mal sehne.


    Hat schon mal jemand das Board der Diamond Monster 3D (oder einer anderen Voodoo 1 Karte) reverse engineered?

    Worst case, wenn die Karte gar nicht mehr zu retten ist, koennte die Karte vielleicht zum Vorbild fuer nen Reproduction-PCB werden.

    Evtl ist einfach auch der tmu defekt?

    Leider eine Moeglichkeit. Das PCB ist leider von den vorherigen Reperatur/Nachloetversuchen schon echt mitgenommen, deswegen will ich das eigentlich erst als letztes machen.

    Vor dem Austausch der TMU an sich hab ich wenig Sorge, aber die Pads auf dem PCB waren jetzt schon mehr als wackelig. Manche sind komplett lose. Die werd ich dann vermutlich komplett mit Faedeldraht nachbauen muessen :/


    Unschoen waere auch, falls das Problem im FBI liegt, dafuer hab ich keinen Ersatz mehr da...

    Anhand dem Bild könnte hier ne Verbindung vorliegen,

    Joa, ist leider eher ein Kompressionsartefakt, in echt ist da keine Verbindung.


    Ich habe jetzt bei einer baugleichen Rev E Monster 3D mal im Betrieb den RAM kurzgeschlossen (genauer: 2 der Datenleitungen am ersten FBI DRAM IC) und das verursacht den gleichen 0xDEAD TMU Fehler...

    Habe die FBI, TMU und den kompletten DRAM deshalb mal nachgeloetet, das Board ist leider bereits ziemlich maltraetiert, einige der Pads sind nicht mehr am Board befestigt und bewegen sich.



    Hab in der Schrottkiste doch noch passenden RAM entdeckt und dann auf Verdacht mal den FBI RAM getauscht... Leider (oder zum Glueck?) keinerlei Aenderung. Pads und Traces unter dem RAM sehen auch perfekt aus.

    Daten/Adressleitungen am DRAM sind auch alle nicht kurzgeschlossen, sowie keine Verbindungen zu Nachbarpins. Hmmmmmm...

    Die Tage ist mir von LeChris eine defekte 3DFX Voodoo 1 zugeflogen... *winkt H.EXE *



    Optisch wurde an der Karte schon mal ein Reperaturversuch unternommen, die Pins an TMU und FBI waren voller Flussmittel und deutlich sichtbar reworked.

    Die Arbeit sah aber ganz gut aus -- alle Pins waren auf den ersten Blick fest und verbunden.


    Spannungsschienen einmal auf Kurzschluesse getestet, alle Ferritperlen auf Durchgang getestet -> alles OK. Widerstaende und Widerstandsnetzwerke sind auch alle OK und verloetet.

    Also die Karte mal in den Pentium 1 eingebaut und geschaut:


    MOJO.EXE haengt nach dem sst1InitDacDetectICS()... Der Rechner war an dieser Stelle dann tot, interessant.

    Also am RAMDAC (der gleichzeitig neben DAC auch noch Taktgenerator fuer VGA und DRAM ist) mal den Quarz sowie die beiden CLK0 (VGA Takt) und CLK1 (Speichertakt) gemessen.


    Quarz, CLK0/VGA sahen prima aus, CLK1 hingegen:


    Hupps? Test mit dem Multimeter zeigt: CLK1 ist gegen Masse kurzgeschlossen! Unter dem Mikroskop war dann auch eine winzige Loetbrucke zu GND erkennbar.

    Ohne die Bruecke war dann auch kein Kurzschluss mehr vorhanden, stattdessen Speichertakt:


    Ich nehme mal an, dieser Fehler wurde beim Nachloeten des RAMDACs verursacht, denn jetzt zeigt sich der "eigentliche" Fehler der Karte...


    MOJO.EXE zeigt Probleme mit dem DRAM/bei der Kommunikation mit der TMU.


    Weil die Karte immer noch absolut voller Flussmittel (Gelfoermig, zwischen den IC Pins) war, hab ich der Karte einmal ein Vollbad spendiert:


    Keine wirkliche Aenderung bisher (war auch nicht zu erwarten, aber better safe than sorry):


    Jetzt wirds langsam etwas haarig... Die Fehlermeldung sieht eher nach Probleme mit dem FBI DRAM aus, inbs. weil auch SST_TEXMAP_DISABLE=1 keine Aenderung verursacht.

    Naechster Schritt ist jetzt vermutlich einmal, die DRAM Leitungen zwischen FBI und DRAM durchzuklingeln (sowie auf Kurzschluesse zu pruefen).

    Falls jemand noch nen guten Vorschlag parat hat, immer her damit :)

    Wenn jemand zufaellig noch passenden DRAM liegen hat, waere ich auch interessiert. Die passenden 256Kx16 EDO Chips habe ich leider gerade nicht mehr da.

    Ein Umzug einer System Festplatte in ein anderes System kann nur Probleme geben.

    Ich mach sowas immer mit ner Acronis True Image Boot-CD/USB. Die kann neben Images erzeugen/wiederherstellen auch direkt zwischen 2 Platten kopieren.

    Die alte Platte klemm ich dann gerne per USB an den neuen Rechner, boote Acronis und lasse das Teil auf die interne Platte kopieren.


    Acronis fummelt nach dem Kopiervorgang ein bisschen in der Registry rum, um solche Treibergeschichten (mit AHCI, etc.) zu entschaerfen.

    Bisher hat das fuer alle Systeme (Win 7 und neuer) immer super geklappt, selbst bei Wechsel zwischen Intel und AMD und sogar von SATA -> NVMe.


    Ist halt leider kommerzielle Software...


    ... ich beweg mich mal auf duennes Eis und weise drauf hin, dass ein Blick auf archive.org evtl. hilfreich sein koennte... *hust*

    welche Compact Flash Adapter könnt Ihr mir den empfehlen ?

    die sind passiv, da kannst du also einfach irgendwas kaufen.


    Frueher gabs mal welche, wo die DMA-Leitungen falsch/gar nicht angeschlossen waren, aber das ist eigentlich auch in der Vergangenheit.


    CF ist technisch fast IDE und die Karten koennen quasi alle einfach direkt IDE sprechen, muessen daher nur Mechanisch adaptiert werden :)

    Sollte ich also die Tantalcap auf jeden fall Tauschen ? Sind das die roten auf dem Board ?

    Jo. Sonst sind die haeufig auch so Orange. Die auf der 12V Schiene sind besonders gefaehrdet, weil die Hersteller haeufig nur 16V Kondensatoren verbaut haben. Das ist zu wenig Sicherheitsabstand.


    Ich wuerd sie nicht tauschen, bevor sie Aerger machen. Du laesst so einen Rechner ja nicht unbeaufsichtigt laufen, d.h. entweder riechst du Probleme, siehst den Rauch oder das Netzteil schaltet durch den Kurzschluss direkt ab.


    Ist diese Kombination aus Mainboard, CPU, RAM, Cachechips schon mal (frueher) erfolgreich gelaufen? Sonst muesste man nochmal einen Blick auf die Jumper-Einstellungen werfen.

    Wie verhaelt sich der Rechner ganz ohne die Multi-IO-Karte?


    Da ist ein Flash-Chip drauf, es koennte also sein (und wuerde vom Fehlerbild her passen), dass das Option-ROM der Karte ausgefuehrt wird und dann haengt (wegen irgendeinem Fehler, Fehlkonfiguration, etc.) der Rechner dort.


    Zitat

    daher schreibe ich die beiden erst mal ab.

    Mit anderen Worten die beiden IDE Anschluesse sind aktuell leer? Wenn das Option-ROM schlecht programmiert ist, koennte es sein, dass es dort ewig auf eine Platte bzw. irgendein Geraet wartet.


    - Kondensatoren sind bestellt und werden getauscht.

    Um die Elkos wuerde ich mir bei dem Board erstmal keine Sorgen machen, die sind zu alt fuer die Kondensatorplage und werden hier auch nicht in Schaltwandlern eingesetzt, haben also alle ein ruhiges Leben...

    Die Tantalcaps sind eher ein wenig problematisch, aber die Verursachen keine Probleme/Instabilitaeten sondern explodieren einfach nur / schliessen dein Netzteil kurz. Also entweder OK oder Explosion, aber eigentlich nichts dazwischen...

    Eventuell weiß auch unsere manawyrm Rat …

    Ich hab eine andere TVGA8900C Karte hier, leider nicht baugleich.


    Das Datenblatt fuer den 8900 gibts online: https://www.dosdays.co.uk/medi…er%20VGA%20Controller.pdf

    Ist zwar die D-Version, statt der C-Version, wird aber wohl nah genug dran sein...


    Damit koenntest du mal probieren, die Jumper zu den Pins am Chip auf Durchgang zu pruefen, um zu identifizieren, was/was ist.


    Ganz wilde Idee: Kleb mal den 16bit Teil der Karte mit Tesa oder Kapton-Tape ab. Wenn die Karte dann funktioniert, ist irgendwas mit der 8/16bit Umschaltung komisch.

    Hatte ich bei dieser Karte definitiv schon mal in der Vergangenheit.


    Zum Test wuerde ich (mit einer anderen Grafikkarte natuerlich) im BIOS des Pentium-Rechners auch mal die ISA-Timings recht entspannt einstellen, viele Waitstates, etc.


    Hast du einen EEPROMer? Vielleicht koennte man das BIOS mal auslesen & vergleichen.


    EDIT: auf https://www.pc-schnulli.de/hardw/gkisa/trgkisa.html gibts ne TVGA8900CL, die identisch aussieht:

    https://www.pc-schnulli.de/hardw/gkisa/trbi/trident_tvga8900cl_1.jpg


    Das Foto ist leider Murks, aber mit sehr, sehr viel Zoom und Augen zusammenkneifen koenntest du da evtl. Jumpereinstellungen erkennen?


    EDIT2: ein anderes Foto, etwas besser aber immer noch nicht toll: https://www.picclickimg.com/Gl…-TVGA8900CL-1MB-1993.webp

    passthru und exec machen das gleiche -- fuehren das Kommando aus. Bei passthru() bekommst du allerdings die Ausgabe von dem Kommando im Webbrowser zurueckgegeben.

    Das ist zur Fehlersuche natuerlich super nuetzlich, damit du Fehler auch siehst und die nicht einfach verschwinden.


    Hab dir "drueben" auch mal geantwortet. Dieser "Split" ist zwar nicht ideal, aber ¯\_(ツ)_/¯. Account hatte ich zum Glueck schon :)

    Da muss ich mich wohl in einem raspberry oder Linux Forum anmelden, und dort fragen um weiterzukommen.

    Och, ich glaub das bekommen wir sicher auch hin. Du musst aber wohl das Problem leider noch ein bisschen genauer erklaeren.


    Du moechtest ne HTTP-URL, bei dessen Aufruf auf dem bereits laufenden X-Server dann dieses Programm gestartet wird? Welche Rechte braucht das Programm?


    Ich wuerde mir vermutlich einen Apache2, PHP installieren und dann einfach den kompletten Apache2 auf den User "pi" umstellen (in /etc/apache2/envvars).

    Damit laeuft PHP dann auch als User "pi". Das kannst du mit nem

    PHP
    <?php
    passthru("whoami");

    Skript auch mal testen, legste halt nach /var/www/test.php und rufst die http://RaspiIP/test.php auf.


    Um ein Programm auf dem XServer zu starten, koenntest mehrere Dinge tun, die sauberste Loesung waere vermutlich einen Dienst (als systemd service) dafuer zu konfigurieren und dann das "systemctl start" Kommando mit PHP auszufuehren.

    Alternativ wirds vermutlich auch einfach klappen, "screen" oder "nohup" zu nutzen um das Programm zu starten. Vorher mit "export DISPLAY=:0" noch die Umgebung passend setzen, damit die Programme wissen, welcher Displayserver genutzt werden soll...


    Beispielcode:

    PHP
    <?php
    passthru('export DISPLAY=:0');
    passthru('screen -dm bash -c "/home/pi/meinTollesGUIProgramm.py"');

    Joa, koennte so klappen, alles aus dem Kopf geschrieben/ungetestet... Have fun :)

    Danke für das unerschütterliche vertrauen in nicht vorhandene Fähigkeiten...

    Ueb das vorher ein wenig an Lochraster und ein paar Stiftleisten und lass den Kaffee 2h vorher weg, dann geht's los :)


    Aber das hat jetzt wirklich ein wenig meine Kuriositaet geweckt -- wuerde gerade gerne wissen, ob man die Buszugriffe auf dem ISA-Bus sieht, hab aber leider gerade das Mainboard mit dem Logikanalysator nicht aufgebaut...