DOS-Forum

Da muss ich auch mal ein Lob aussprechen: Deine Problembeschreibung ist wirklich vorbildlich und übersichtlich formatiert.
Das fällt mir in Anbetracht der zuletzt hier vermehrt aufgetauchten Schwurbelpostings positiv auf.

Es wäre gut, wenn du eine weitere ET4000 basierte Karte hättest, um testen zu können, ob es wirklich an deiner Karte liegt oder evtl. eine Inkompatibilität schuld an dem Fehler ist.

Viele Grüße
Fabian

Wenn du magst könnte ich dir zu diesen Zweck eine Eizo ET4000 ISA ausborgen.
Müsstest halt die Versandkosten übernehmen.

matze79 hat geschrieben:Hat die Karte Jumper? evtl. ist da was falsch.
Hat dein BIOS zufällig VESA Optionen ?

Mein BIOS hat leider nur die üblichen caching/shadowing Optionen. Sonst nichts für die Grafikkarte.

Aber Matze79, du bist ein Genie!
Denn Jumper gibt es. J1 und J2 in der Mitte der Karte, zwischen Chip und DAC.
Eingestellt war: J1 ist offen, J2 geschlossen.
Hier mal ein Bild:
Ich habe das jetzt einfach mal getauscht. Also J1 geschlossen, J2 offen.
Ergebnis: Die Karte läuft, das Bild ist gut und die vorher abstürzenden Programme laufen auch!

Eine kleine Ernüchterung kam dann aber doch, als ich dann mal den Durchsatz mit VGA-Speed gemessen habe. Die ET4000 ist jetzt deutlich langsamer. Der Durchsatz liegt jetzt bei nur noch 3,8 MB/s. Ich habe ein paar Benchmarks laufen lassen und sie liegt jetzt sogar leicht unter den Werten der Industrie-Karte. Aber immernoch deutlich höher, als mit einer auf 8 Bit reduzierten Anbindung.

Hier die Übersicht, was das Umstecken der Jumper ausmacht: Auch wenn ich beide Jumper offen lasse, komme ich zu diesen Ergebnissen.
Also wieder den Fehler durch ein Ausbremsen der Karte behoben. Diesmal per Jumper.
Aber immerhin habe ich jetzt das gute Bild die Spielekompabilität des ET4000 ohne Abstürze. Das ist schon mal ein riesen Fortschritt.
Wenn ich jetzt noch wüßte, was die beiden Jumper bewirken, wäre die Fehlerquelle schon recht gut eingegrenzt.
Hat da jemand von euch eine Idee?

matze79 hat geschrieben:Wenn du magst könnte ich dir zu diesen Zweck eine Eizo ET4000 ISA ausborgen.
Müsstest halt die Versandkosten übernehmen.

Das würde ich sehr gerne mal testen! Danke!
Ich schreib dir für alles weitere gleich eine PN.

Das ist sehr wahrscheinlich ein Jumper für einen Waitstate. Vielleicht lässt das den Rückschluss zu, dass beim Zero-Wait-State-Betrieb die ET4000 von dir nicht so recht mit deinem ISA-Bus harmonieren möchte, bzw. sehr sensibel darauf reagiert.

matze79 hat geschrieben:@idspispopd:
tatsächlich bei 640x480 steigt Duke mit Fehlern aus.
Eine 15M-16M Hole funktion hat mein BIOS nicht.

Gibts eine Software die das selbe tut ?
Z.b. den Bereich reservieren das er nicht als XMS genutzt werden kann.

Den Bereich zu reservieren reicht nicht, wie gesagt "sieht" die CPU in dem Bereich einfach nur das System-RAM und nicht das Video-RAM. Das Ausblenden geschieht durch den Chipsatz. Wenn Du ein Tool findest was Deinen Chipsatz programmieren kann könntest Du vielleicht damit etwas werden. Oder, falls die Einstellung im BIOS nur versteckt ist, mit einem Tool wie AMIBIOS (ich weiß nicht ob es das für Dein BIOS gibt). Letzteres hat den Charme dass die Einstellung gespeichert bleibt, ansonsten muss man das Setzen nach jedem Systemstart neu durchführen.

Es kann auch sein dass DOS bzw. himem.sys den Speicher über 16MB auch nicht mehr sieht, wenn man das so einstellt.

So schlimm finde ich das jetzt aber nicht, zumindest Spiele laufen mit einer SVGA-Auflösung auf einem 486 nicht unbedingt ganz so flott. Für Windows dürfte das schon mehr ausmachen.

Bin mal gespannt obs mit der Diamond Speedstar 24 von wollev45 klappt (ET4000, 1Mb 60ns RAM).

So, hier geht es jetzt auch weiter. Nachdem sich die merkwürdigen Fehler durch aufwändiges Rumprobieren ja eindeutig auf die Grafikkarte zurückführen ließen (Abstürze mit meiner Targa Win 32K, mit einer Industrie-Karte (HM86508IQ Chip) läuft alles bestens), steht nun der Test weiterer Grafikkarten an.

Aber erstmal zu einer zufällig bemerkten Zwischenlösung und neuen Möglichkeit für etwas mehr Durchsatz:

FGB hat ja den Jumper als Einstellmöglichkeit für einen Waitstate identifiziert. Das bracht mich am letzten Wochenende auf die Idee, nochmal im Bios alle Waitstate-Einstellungsmöglichkieten auszuprobieren. Einstellungen des "Local Ready Delay" für den ISA Bus oder des "IO Recovery Time" beeindruckten die Karte gar nicht. Aber dann fand ich doch eine Einstellung, der ich bisher keine Aufmerksamkeit geschenkt habe, auf die meine Grafikkarte aber sehr sensibel reagiert: "Signal LDEV# Sample Time" Einstellmöglichkeiten von T2 bis T4. Ich habe ja nun schon einige Jährchen Erfahrung mit Bioseinstellungen, aber diese Option sagt mir gar nichts. Sie steht bei mir im Bios auch ganz unten bei den Chipset Einstellungen und nicht bei den Einstellungen für den ISA-Bus - kann mich hier jemand aufklären?
Auf jeden Fall scheint es eine sehr interessante Einstellungen zu sein, um seiner Karte mehr Durchsatz zu verpassen.
Setze ich hier den Wert von T3 runter auf T2, hat meine Targa im 0 Waitstate Modus und bei standart ISA-Takt (PCLK/4 = 8,25 MHz) einen sagenhaften Durchsatz von 5,3 MB/s, anstelle der zuvor gemessenen 4,9 MB/s. Aber natürlich mit dem bekannten Fehlerbild.
Also habe ich mal folgendes probiert: ISA-Bustakt auf 6,6, MHz reduziert, denn dann funktionierte die Grafikkarte ja immer ganz wunderbar. Und auch den anderen, über 20 Jahre alten, Steckkarten kann ein wenig Ruhe ja nicht schaden Dafür dann aber im Bios die Signal LDEV# Sample Time auf kleinstem Wert gelassen. Ergebnis: 4,6 MB/s. Also schneller als die Industrie-Karte und einer ET4000 ansatzweise würdig. Alle Programme laufen stabil, Framerate geht auch in Ordnung, also eine akzeptable Zwischenlösung.

FGB hat geschrieben:Es wäre gut, wenn du eine weitere ET4000 basierte Karte hättest, um testen zu können, ob es wirklich an deiner Karte liegt oder evtl. eine Inkompatibilität schuld an dem Fehler ist.

Genau das kann ich jetzt machen, denn matze79 hat mir seine EIZO ET4000 geliehen. Nochmal ganz lieben Dank dafür!
Die Karte ist inzwischen bei mir angekommen und gerade fand ich dann auch etwas Zeit zum testen.

Damit ist jetzt aber auch definitiv klar, meine schöne Targa hat ein Problem, denn die Eizo von Matze läuft ganz wunderbar mit klarem Bild und macht keinerlei Zicken in meinem System. Interessanter Weise haben beide ET4000-Karten exakt den gleichen Durchsatz und schneiden bei allen Benchmarks vollkommen identisch ab - bis auf einen frame genau! Es ist aber nicht so, dass es sich hier um identische Karten handelt, die unter jeweils anderem Label vermaktet wurden. Das Deisgn der Karten ist völlig unterschiedlich, bis auf den ET4000AX sind vollkommen andere ICs verbaut.
Der größte Unterschied ist der verwendete RAMDAC, denn die Targa Win 32K besitzt, wie die "32K" im Namen erahnen lassen, einen MUSIC MU9C4870-80PC Hi-Color DAC. Außerdem ein Vesa Bios welches VBE 1.2 bereitstellt. Wie Matze79 oben schon geschrieben hatte, begnügt sich die Eizo mit 256 Farben. Für den Vergleich der SVGA-Benchmarks habe ich hier Tseng Labs eigenes TLVESA TSR genommen, welches ebenfalls VBE 1.2 bereitstellt und womit die Karte dann auch bei PCPBench in 640x400 identische Ergebnisse wie die Targa abliefert.

Interessanter Weise funktioniert mit Matzes Karte auch 1024x768 auf meinem TFT, bei der Targa schaltet der Monitor dann ab. Eventuell also keine zu hohe Bildwiederholrate, wie ich bisher dachte, sondern ein anderes Problem?

Kurzum: Es ist keine Inkompatibilität meines Systems zum ET4000, sondern meine schöne Targa hat irgendeine kleine Macke, die sich so fatal auswirkt. Wirklich Schade, denn die Karte hat ein tolles Bild und dadurch, das sie Hi-Color und Vesa-support besitzt, ist sie eigentlich wirklich universell einsetzbar. Aber sie verträgt nur einen langsamen ISA-Bus Takt - vielleicht fordert sie nach 24 Jahren einfach Altersteilzeit ;)

matze79 hat geschrieben:tatsächlich bei 640x480 steigt Duke mit Fehlern aus.

Habe das auch mal getestet und bei mir funktioniert Duke 3D Atomic Edition mit 640x480 bei beiden Karten (mit TLVESA bei deiner Eizo) problemlos. Obwohl das Setup mir die Warnung gibt, dass ich eine Vesa 2.0 kompatible Karte benötige, wird der Modus auch mit VBE 1.2 korrekt gesetzt. Bei 640x480 ist es aber schon eine recht "zähe" Angelegenheit, mit dem Duke zu zielen. Habe 320x400, auch einen Vesa 2.0 Modus, gesetzt.

Super, bei mir gehts jetzt auch, lag an der CF Karte.
Duke 3D nutzt wohl extra Zugriffe und die blöde CF Karte macht keine 32bit Transfers mit.

Die Ursache des Problems ist gefunden.

Kurzfassung:
All der in diesem Thread beschriebene Ärger lag an einem beschädigten Kondensator auf der Targa-Grafikkarte.
Für alle Bastler interessant: Dieser Kondensator scheint maßgeblich über die Geschwindigkeit der Karte zu bestimmen.


So, jetzt zur ausführlichen Version:
Es begann damit, dass ich eine weitere ET4000-Grafikkarte ergattern konnte, die mich auf die richtige Spur brachte. Auf den unterschiedlichsten Seiten guckte ich immer mal wieder nach Karten mit ET4000 Chip, da ich hoffte, nochmal so günstig an eine zweite Targa Win 32K zu kommen (bei Ebay gab es zwischendurch eine, aber die war mir zu teuer).
Was ich dann aber fand, ist eine Diamond Speedstar Plus, die laut Vorbesitzer aber wohl defekt ist. Ich nahm sie trotzdem. Irgendwie habe ich ein Herz für beschädigte Grafikkarten. Beim ersten Test freute ich mich schon, denn im Textmodus war das Bild scharf und alles stimmt. Doch schon beim ersten getesteten Spiel, Lotus III, wurde offensichtlch, dass hier etwas nicht stimmt: Roter Himmel, Pinke Autos mit roten und grünen Details und eine grell blaue Fahrbahn? Hält sich die Karte plötzlich für eine CGA oder was ist hier los?!? Da das Bild sonst gut ist, keine Streifen und scharf, können falsche Farben ja nur an der Palette, also am DAC liegen.... Der ist zum Glück gesockelt und ich habe hier noch eine S3-Karte, die einen im gleichen Format besitzt, also wird mal flott getauscht und siehe da, die Speedstar läuft mit dem 24 Bit AT&T DAC ganz wunderbar.

Mal ein paar Bechmarks gemacht und die Karte ist noch eine ganze Ecke flotter als die Targa oder die EIZO von matze79.

Ohne Waitstate (Jumper und Bios) und bei normalem ISA-Takt: Jetzt interessiert mich natürlich, was die Speedstar so viel schneller als die Targa macht. Zumal mit der Speedstar auch alle Demos, Cracktros und auch FT2 super funktionieren, die mit der Targa ohne Waitsate oder langsamerer Taktung Probleme machen.
Die Speedstar hat schnelleren Speicher verbaut, 60ns gegnüber 80ns bei der Targa. Und sie hat zwei BIOS-EPROMS, aber die hat die EIZO von matze79 auch, 16 Bit Zugriff aufs Bios kann hier nicht ausschlaggebend sein, sonst hätten shadowing Optionen im Bios ja einen klaren Geschwindigkeitsgewinn bei bei der Targa bringen müssen. Also liegt es nur am schnelleren Speicher? Oder auch dem DAC? Leider haben beide Karten da unterschiedliche Formate / Sockel, da kann ich also nicht mal eben tauschen. Aber als ich das Layout beider Karten so vergleiche, da fällt mir noch ein auffälliges Bauteil ins Auge, (ich hielt es erst für einen Widerstand, aber wolfig_sys hat mich netter Weise aufgeklärt ) der bei der Targa vorhanden ist und bei der Speedstar nicht. Dieser verbindet auf der Rückseite der Karte die hinteren beiden ISA-Kontakte.

Und damit fand ich dann, ganz durch Zufall, die Ursache für den merkwürdigen Fehler, zu dem ich diesen Thread eröffnet habe.
Denn als ich mir den Kondensator jetzt nochmal genauer ansehe, da bemerke ich, dass ein Beinchen gebrochen ist und keinen Kontakt hat! Eine Ersatzkarte habe ich jetzt ja, also schreite ich gleich zur Reparatur. Mit meiner dünnsten Lötkolbenspitze, Geduld und einer möglichst ruhigen Hand platziere ich ein kleines Tröpchen Lötzinn und schaffe wieder eine Verbindung.

Ergebnis:
Nicht ganz das erhoffte, denn die Targa ist deutlich langsamer! Ohne Waitstate (Jumper und Bios) und bei normalem ISA-Takt erreicht sie jetzt 4,4 MB/s (mit defektem Widerstand waren es 4,9 MB/s). So gebremst läuft alles natürlich alles bestens, wie vorher durch den untertakteten ISA-Bustakt. Auch reagiert die Karte jetzt nicht mehr ganz so sensibel auf Waitstates.

Ganz klar ist mir zwar nicht, wieso die beschädigte Karte bei 90 Prozent aller Programme (und Spiele!) bestens funktionierte, in Einzelfällen aber Speicherzugriffsfehler, Schutzverletzungen und Abstürze verursacht. Ich vermute aber mal, da wird irgendwie für einen Ausgleich zwischen Busgeschwindigkeit und dem Speicher der Grafikkarte gesorgt.
Vielleicht kann ja jemand aus dem Forum zur Aufklärung beitragen.

Beschriftet ist er mit 10-16, jetzt wäre ja mal interessant, was bei einem Kondensator mit anderen Werten passieren würde..... Aber ich bin erstmal froh, dass der Fehler gefunden ist. Unnötig an einer Karte wild verschiedene Teile ein- und auslöten, muss ja nun auch nicht sein ;)

Das ist (sieht so aus) kein Widerstand, sondern ein Kondensator. Nur so zur Info

wolfig_sys hat geschrieben:Das ist (sieht so aus) kein Widerstand, sondern ein Kondensator.

Wieder was dazugelernt! Und direkt mit kindlicher Handschrift verbessert

10 16 heißt:
10µF 16V und wahrscheinlich ein Tantal der Bauform nach. Könntest du wahrscheinlich mit einem low ESR Elko 100µF/ 16V tauschen. Denke aber nicht, dass es notwendig sein wird. Die Tantals schließen sich zwar gelegentlich kurz, laufen aber dafür auch nicht aus oder werden "taub".