Merkwürdiges ISA-Bus und Arbeitsspeicher Problem

[Dragonsphere]

Liebe DOSianer,
mein Industrie 486er ärgert mich gerade mit einem ganz merkwürdigen Absturzverhalten bei einigen Programmen. Ich hoffe mir kann jemand von euch dabei weiterhelfen.

Mein System
CPU: Intel 80486DX4-S / 100 MHz
Cache: 16 KB L1 im write through, 128 KB L2
Chipsatz: UMC UM8498F
Speicher: 2 x 16 MB Siemens HYM324025s-60 EDO-RAM
Industriesystem mit SBC (SSC-486 H Ver. C) und ISA-Backplane
Soundkarte: Aztech Sound Galaxy (Washington 16?), Platine I38-MMSN850 mit AZT2316-S Chip
Grafikkarte: Targa Win 32K, Tseng ET4000AX Chip und 1 MB Speicher
Bios: AMI WinBIOS
OS: DOS 6.22
In der Galerie ausführlich vorgestellt: http://www.dosforum.de/viewtopic.php?f=29&t=10304

Problembeschreibung
Seit ich den 486er am Laufen habe, wundere ich mich, warum manche Programme nicht vernünftig laufen und dachte mir erstmal, dass es am Industrie-Charakter des Systems (Einplatinenrechner mit passiver Backplane) liegt und da Hardwarezugriffe o.ä. gesperrt werden. Etwa neigen einige alte Demos zum spontanen einfrieren. Vorne weg Second Reality von der Future Crew. Sobald der Landschaftsscroller endet und das Raumschiff erscheint, hängt sich das System auf. Einige alte Cracktros schmieren auch direkt ab und wenn ich im Fasttracker II einen Song höre, funktioniert das maximal 2 Minuten. Dann erhalte ich einen General Protection Fault an Adresse 16B2:22A9 (es ist immer das Segment 16B2, das Offset wechselt liegt aber häufiger bei 22A9). Gerne auch mal das EMM386 Fehler #06 einer Anwendung bei der Speicheradresse 00B8:15DA gefunden hat.

Bisherige Lösungsversuche

Defekter Arbeitsspeicher?
Daraufhin habe ich es erstmal ohne EMM386 probiert, die Intros stürzen immernoch ab. Fasttracker auch mit alternativen Speichermanagern. Natürlich kam mir der Gedanke, dass ein Speicherriegel defekt sein könnte. Also Memtest86 laufen lassen - keine Fehler. Goldmemory findet auch nichts. Im BIOS mal den Hardware Parity Check aktiviert -> Parity Error!
Ich baue wieder den 4MB Riegel ein, mit dem ich den Rechner bekommen habe. Keinerlei Unterschied! Und dann dachte ich nochmal nach: Wenn der Arbeitsspeicher beschädigt wäre, müssten Spiele doch auch abstürzen. Tun sie aber nicht! 2 Stunden History Line 1914-18 gingen problemlos. Auch habe ich ja einen Grafikkartenbenchmark mit übertaktetem ISA-Bus und Doom 1 Benachmark gemacht und die Ergebnisse hier im Forum gepostet, das ging ohne Abstürze.
Also nicht der Arbeitsspeicher...

Bei meinen Benchmarks für die Vorstellung hier im Forum etwas kaputt gemacht?
Das ich dabei etwas beschädigt habe, kann ich auch ausschließen, denn Second Reality lief von Anfang an nicht. Es war mit das erste Programm, was ich ausprobiert habe, selbst als hardwaremäßig noch alles im Urzustand war. Und der Fasttracker 2 kam dazu, sobald die Soundkarte drin war.
Also auch nein, da das Problem vorher schon aufgetreten ist

Spinnt evtl. der Cache?
Was bliebe, wäre evtl. ein Problem mit dem Cache. Also mal L1 und L2 Cache aus, jetzt läuft alles im Schneckentempo aber sonst keine Änderung. Also auch nicht der Cachespeicher -woher kommt nur dieser Parity-Error?

Bios-Einstellungen?
Im Bios waren bisher die "Optimal" Einstellungen mit nur kleinen Änderungen (floppy drive seek aus, memory tick sound aus usw.) Ich habe dann das Fail-Safe Profil geladen und der Fehler war weg! Kein Parity Error (trotz weiterhin aktiviertem Parity check) und alle Programme die vorher abstürzten, laufen jetzt! Zwar sehr langsam, da ja alles auf langsamsten Einstellungen steht, kein Cache, lahme Timings etc., aber nichts stürzt mehr ab. Auch Second Reality ruckelt zwar enormst, läuft aber durch.. Damit ist auch endgültig ausgeschlossen, dass der SBC da mit irgendwelchen Schutzmaßnahmen mitmischt. Der Hardware Watchdog ist auch per Jumper deaktiviert.

Also taste ich mich nach und nach an meine alten Einstellungen ran und was letztlich den Unterschied macht, ist der ISA-Bustakt! Bei Failsafe wird der ISA-Bus auf 2,75 MHz (PCLK/12) anstelle der normalen 8,25 MHz (PCLK/4) gesetzt. Ich hebe ihn langsam wieder an und teste regelmäßig. Mit 6,6 MHz lauft second reality und ich kann drei Songs im Fasttracker hören. Gehe ich höher, also auf den normalen Wert, der auch vom Bios normalerweise bei der autodetection der Speichereinstellungen gesetzt wird. Ist der Fehler, inklusive Parity-Error plötzlich wieder da. Doom oder auch Duke Nukem 3D kann ich aber selbst bei einem Bustakt von 11 Mhz noch spielen, ohne Abstürze.

Was kann das nur sein? Während ich das hier schrieb kam mir gerade die Soundkarte mehr und mehr in Verdacht, denn sowohl bei den Demos / Cracktros als auch im Fasttracker 2 treten die Abstürze ja auf, während MOD-Dateien, also viele Samples, abgespielt werden. Bei Spielen mit OPL-3 Musik und nur gelegentlichen Samples gibt es keine Probleme. Spinnt also vielleicht einfach der DSP meiner Sound Galaxy und mag keinen hohen Datendurchsatz? Leider habe ich keine andere ISA-Soundkarte zum testen da.

Was meint ihr?

[Martin75]

Evtl die Soundkarte ein paar mal ein und ausbauen, vielleicht ist einer der Pins oxidiert.

Hatte ich bei einer SB16, mit nur 8bit keine probleme, aber mit 16bit nur rauschen und zischen zu hören.

Hab lange mit dem problem gelebt.. bis ich die Karte mal umgesteckt habe weil eine netzwerkkarte dazu kam.. und plötzlich lief auch 16 bit.


Auch wieder im zurückgebauten urzustand.

[matze79]

Sieht mir nach falschen RAM aus.
Sind die 4Mb Riegel EDO oder FPM ?
Welche RAM Timings sind im Bios eingestellt, vieleicht sind WS nötig.

?
Im Bios waren bisher die "Optimal" Einstellungen mit nur kleinen Änderungen (floppy drive seek aus, memory tick sound aus usw.) Ich habe dann das Fail-Safe Profil geladen und der Fehler war weg! Kein Parity Error (trotz weiterhin aktiviertem Parity check) und alle Programme die vorher abstürzten, laufen jetzt! Zwar sehr langsam, da ja alles auf langsamsten Einstellungen steht, kein Cache, lahme Timings etc., aber nichts stürzt mehr ab. Auch Second Reality ruckelt zwar enormst, läuft aber durch.. Damit ist auch endgültig ausgeschlossen, dass der SBC da mit irgendwelchen Schutzmaßnahmen mitmischt. Der Hardware Watchdog ist auch per Jumper deaktiviert.

Ey, was ist wenn du jetzt nur Cache einschaltest ?
Wenn es dann wieder da ist, Cache mal raus und neu sockeln, evtl. sockel reinigen.

[Dragonsphere]

Gestern habe ich den Abend damit verbracht, dem Fehler weiter den Grund zu gehen.
Vielen Dank Martin75 fund matze79 ür eure Ideen und Vorschlägen, denen bin ich direkt nachgegangen.

Um Oxidation auszuschließen habe ich nochmal alles ausgebaut und die Kontakte aller Karten und die Slots auf der Backplane vorsichtig mit Spiritus gesäubert. Bei der Gelegenheit dann auch gleich mal den CPU-Kühler abgenommen, CPU und Kühler gesäubert und mit neuer Wärmeleitpaste wieder montiert. Alle L2 Cache-chips vorsichtig von ihren Sockeln genommen, Pins gerichtet, Sockel und Pins gesäubert und wieder eingebaut. Ebenso die Kontakte beim Arbeitsspeicher gesäubert.
Anschließend alles wieder zusammengebaut, dabei auch bewusst die Karten in den ISA-Slots getauscht und mehrfach ein- und ausgesteckt.
Unter Verdacht hattte ich ja jetzt die Soundkarte. Also wurde die gar nicht wieder eingebaut.
Gestartet, im Bios das Fail-Safe-Profil geladen und nur den ISA-Bus auf normalen Speed gestellt. L1 und L2 Cache also ausgeschaltet gelassen.
Second Reality ohne Sound gestartet und leider keine Änderung. Sobald nach dem Landschaftsscroller das Raumschiff erscheint friert das Bild ein. Diesesmal hatte ich dabei auch drei Zeilen bunten "Pixelsalat" im oberen Bildschirmbereich. Die Cracktros konnte ich ohne Soundkarte nicht testen. FT2 habe ich eine MOD Datei über den PC Speaker ausgeben lassen (Sehr effektiv um alle anderen Personen im Haushalt in den Wahnsinn zu treiben ). Brauchte ohne Cache eine Ewigkeit zum laden, aber es ließ sich erstmal gut an, nach 1:28 kam dann aber doch wieder der schon gut bekannte general protection fault.

FT2 GPF.jpg (50.44 KiB) 7667 mal betrachtet

Also nicht die Soundkarte. Doch der Arbeitsspeicher?
Zur Sicherheit den originalen 4 MB Riegel wieder eingebaut.

Sieht mir nach falschen RAM aus.
Sind die 4Mb Riegel EDO oder FPM ?

Das dachte ich auch schon. Der 4MB Riegel sind aber auch EDO-RAM, ob Fastpage kann ich aber nicht sagen.
Auf der Rückseite steht B7468B, die Chips sind Fujitsu 8118165B-60
Bei Google fand ich dazu nur einzelnen Angebote, immer als EDO mit 60 ns.

Im BIOS stehen die Einstellungen weiterhin Fail safe. Im Detail:

Code: Alles auswählen

Cache Read Hit Wait state: 3-2-2-2
Cache Write Hit Wait state: 2 W.S.
DRAM Wait State Select: 2 W.S.
DRAM Page Mode: Slow
Alt Bit in Tag SRAM: 7+1 Bits
DRAM Refresh Method: RAS Only
Divider for Refresh: 1/1
Hardware DRAM Parity Check: Disabled
System Memory Remap: Disabled
Shadowing und Caching Einstellungen alle auf Disabled 
IO Recovery Time Select: 12 BCLK
ISA Bus Refresh Disable Bit: Slow
AT Clock Select: PCLK/12  

Ey, was ist wenn du jetzt nur Cache einschaltest ?
Wenn es dann wieder da ist, Cache mal raus und neu sockeln, evtl. sockel reinigen.

Ich habe den ISA-Bus wieder auf die normalen 8,24 MHz eingestellt (AT Clock Select: PCLK/4) und erst mit aktiviertem L1 und deaktviertem L2 getestet -> kein Unterschied. Auch bei deaktiviertem L1 und aktiviertem L2 bleibt der Fehler.
Habe dann den ISA-Bustakt auf PCLK/5, also 6,6 MHz, gesenkt und es läuft wieder alles problemlos. Egal mit welcher Cacheeinstellung.
Die CPU bzw. der L1 Cache scheint übrigens nur WT zu unterstützen, auch wenn ich im Bios auf Write Back einstelle, bleibt er laut sämtlichen tools im Write through.

Ich habe mich dann noch etwas nach weiteren Tools zum Testen des Arbeitsspeichers umgesehen. Memtest86 findet ja keine Fehler, aber CACHECHK zeigt mir zumindest bei den 32 MB etwas an:

CACHECHK Test mit dem 4 MB Riegel:

Code: Alles auswählen

 CACHECHK V7 11/23/98  Copyright (c) 1995-98 by Ray Van Tassle. (-h for help)
 CMOS reports: conv_mem= 640K, ext_mem= 3,264K, Total RAM= 3,904K
 "GenuineIntel"  486 DX4 Clocked at 99.9 MHz
 Reading from memory.  
 MegaByte#:      --------- Memory Access Block sizes (KB)-----
       1    2    4    8   16   32   64  128  256  512 1024 2048 4096 <-- KB
 0:   11   11   11   11   11   28   28   28   38   38   --   --   --    us/KB
 1:   11   11   11   11   11   28   28   28   38   38   38   38   --    us/KB
 2  3  4  <--- same as above.

 Extra tests----
 Wrt   32   32   33   33   33   33   33   33   33   33   33   33   --<-Writing
 This machine seems to have both L1 and L2 cache. [reading]
    L1 cache is   16KB-- 102.3 MB/s  10.3 ns/byte (355%) (257%)      3.9 clks
    L2 cache is  128KB--  39.8 MB/s  26.3 ns/byte (138%) (100%)     10.0 clks
    Main memory speed --  28.8 MB/s  36.5 ns/byte (100%) [reading]  13.9 clks
    Effective RAM access time (read ) is 146ns (a RAM bank is 4 bytes wide). 
    Effective RAM access time (write) is 124ns (a RAM bank is 4 bytes wide). 
    "GenuineIntel"  486 DX4 Clocked at 99.9 MHz.  Cache ENABLED.
 Options: -t0

Und mit den beiden 16 MB Riegeln:

Code: Alles auswählen

CACHECHK V7 11/23/98  Copyright (c) 1995-98 by Ray Van Tassle. (-h for help)
  CMOS reports: conv_mem= 640K, ext_mem= 31,936K, Total RAM= 32,576K
 "GenuineIntel"  486 DX4 Clocked at 99.9 MHz
 Reading from memory.  
 MegaByte#:      --------- Memory Access Block sizes (KB)-----
       1    2    4    8   16   32   64  128  256  512 1024 2048 4096 <-- KB
 0:   11   11   11   11   11   28   28   28   38   38   --   --   --    us/KB
 1:   11   11   11   11   11   28   28   28   38   38   38   38   38    us/KB
 2:   11   11   11   11   11   28   28   28   38   38   38   38   38    us/KB
 3  4  5  6  7  8  9 10 11 12  <--- same as above.
13:   11   11   11   11   11   28   28   28   38   38   38   38   41    us/KB
14:   11   11   11   11   11   28   28   28   38   38   38   38   43    us/KB
15:   11   11   11   11   11   28   28   28   38   38   38   43   46    us/KB
16:   49   49   49   49   49   49   49   49   49   49   49   49   49    us/KB
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32  <--- same as above.

 Extra tests----
 Wrt   32   33   33   33   33   33   33   33   33   33   33   33   33<-Writing
 This machine seems to have both L1 and L2 cache. [reading]
    L1 cache is   16KB-- 102.3 MB/s  10.2 ns/byte (356%) (257%)      3.9 clks
    L2 cache is  128KB--  39.8 MB/s  26.3 ns/byte (138%) (100%)     10.0 clks
  Hmmm. It looks like megabyte #16 isn't being cached!
  Hmmm. It looks like megabyte #17 isn't being cached!
  Hmmm. It looks like megabyte #18 isn't being cached!
  Hmmm. It looks like megabyte #19 isn't being cached!
  Hmmm. It looks like megabyte #20 isn't being cached!
  Hmmm. It looks like megabyte #21 isn't being cached!
  Hmmm. It looks like megabyte #22 isn't being cached!
  Hmmm. It looks like megabyte #23 isn't being cached!
  Hmmm. It looks like megabyte #24 isn't being cached!
  Hmmm. It looks like megabyte #25 isn't being cached!
  Hmmm. It looks like megabyte #26 isn't being cached!
  Hmmm. It looks like megabyte #27 isn't being cached!
  Hmmm. It looks like megabyte #28 isn't being cached!
  Hmmm. It looks like megabyte #29 isn't being cached!
  Hmmm. It looks like megabyte #30 isn't being cached!
  Hmmm. It looks like megabyte #31 isn't being cached!
  Hmmm. It looks like megabyte #32 isn't being cached!
  Hmmm. It looks like RAM at megabyte #16 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #17 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #18 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #19 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #20 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #21 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #22 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #23 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #24 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #25 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #26 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #27 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #28 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #29 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #30 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #31 is REALLY slow!
  Hmmm. It looks like RAM at megabyte #32 is REALLY slow!
    Main memory speed --  28.7 MB/s  36.5 ns/byte (100%) [reading]  13.9 clks
    Effective RAM access time (read ) is 146ns (a RAM bank is 4 bytes wide). 
    Effective RAM access time (write) is 124ns (a RAM bank is 4 bytes wide). 
    "GenuineIntel"  486 DX4 Clocked at 99.9 MHz.  Cache ENABLED.
 Options: -t0

Was soll ich denn jetzt davon halten?
Werde heute Abend nochmal ein bisschen rumprobieren......

[Dragonsphere]

Da die Einstellungen des Cache, Auswechseln des Arbeitsspeichers und alles andere keinen Effekt auf den Fehler zu haben scheint, eine Veränderung des ISA-Bustaktes aber schon, kam ich gerade nochmal auf die ISA-Steckkarten zurück. Die Soundkarte hatte ich ja schon ausgeschlossen, bleibt also nur noch die Grafikkarte.
Das konnte ich zum Glück schnell prüfen und habe die original verbaute Industrie-Grafikkarte MBC-265B anstelle der Targa Win 32k eingebaut. Und...es läuft! Und zwar alles! Second Reality, alle anderen Demos und auch 30 Minuten lang Musik im Fasttracker II laufen damit wunderbar.

Jetzt frage ich mich natürlich, ob die Targa irgendeinen versteckten Defekt hat, oder ob es an der Geschwindigkeit liegt. Die Industrie-Grafikkarte ist absolut nicht für Spiele ausgelegt und hat einen deutlich niedrigeren Datendurchsatz als die Targa mit ET4000AX. Und wenn ich die Targa mit PCLK/5 oder den Fail-Safe Settings von sogar PCLK/12 gedrosselt habe, funktionierte ja auch alles wunderbar.....
Also entweder ist die Targa zu schnell für das restliche System oder sie hat irgendeine Macke, wobei ich ja sonst keine Bildfehler o.ä. damit habe und problemlos Spiele spielen kann.

Habe jetzt testweise mal den Takt wieder auf 11 MHz gesetzt, um der MBC-265B einen ähnlich hohen Datendurchsatz zu verpassen. Es läuft immernoch alles ohne Probleme. Also hat die Targa anscheinend eine Macke oder verträgt sich mit irgendeiner anderen Komponente/Einstellung nicht.
Aber wie wirkt sich die Grafikkarte so auf Fasttracker II bzw. den Arbeitsspeicher aus?!? Und vor allem, warum stürzt das System damit bei diversen Spielen nicht ab, aber beim Abspielen von Musik oder beim Demos gucken?
Ganz merkwürdig ist vor allem, dass Second Reality ursprünglich mit dieser Karte auch nicht lief - jetzt aber schon.....
Also wieder viel ausprobiert und nur noch mehr Fragen aufgeworfen

Diese DOSen haben wirklich ihren ganz eigenen Charakter und meine möchte anscheinend ihre originale Grafikkarte zurück....

[Martin75]

kann es sein dass der ram der grafikkarte und der ram vom hauptspeicher sich überschneiden?

Kann man im bios evtl speicherbereiche sperren?

[Dragonsphere]

kann es sein dass der ram der grafikkarte und der ram vom hauptspeicher sich überschneiden?

Das würde natürlich wirklich einiges erklären, vor allem wäre dann ja der "general protection fault" mehr als berechtigt.
Aber das müsste doch dann beide Grafikkarten gleichermaßen betreffen - oder?

Kann man im bios evtl speicherbereiche sperren?

Nicht das ich wüßte. Habe schon alle shadowing und caching Optionen ausgeschaltet.

[idspispopd]

kann es sein dass der ram der grafikkarte und der ram vom hauptspeicher sich überschneiden?

Kann man im bios evtl speicherbereiche sperren?

Das wäre dann der Fall, wenn man auf einem System mit min. 16MB RAM (passt) eine ISA-Grafikkarte betreibt (passt) und auf dieser dann den linear frame buffer nutzen möchte (keine Ahnung ob das hier der Fall ist). Da ISA nur 24 Adressleitungen hat und somit max. 16MB adressieren kann, liegt der LFB dann typischerweise zwischen 15-16MB. Dafür gibt es dann im BIOS oft eine Option "15-16M memory hole", "LFB memory hole" oder so ähnlich. Damit macht man den LFB für die CPU erst mal zugänglich, im anderen Fall sollte der LFB nicht sichtbar sein, die CPU sieht dort nur System-RAM. Ich weiß aber nicht wie die Software mit dieser Lücke umgeht, möglicherweise muss man das himem.sys/emm386.exe mitteilen.

[matze79]

Intressanterweise hab ich dieses Problem nicht.
Ich betreibe mein ISA System mit 64Mbyte RAM und nutze jetzt die Trident 8900D-CR mit 32bit RAM.
Die ET4000 ist gleich schnell unterstüzt aber nur 256 Farben. Aber die Trident kann Truecolor :)

[eltrash]

Glückwunsch Dragonsphere, dass du dem Fehler auf die Spur gekommen bist. Du hast dich ja auch intensivst damit beschäftigt und den Fehler sehr gut eingegrenzt. Übrigens finde ich deine Fehlerbeschreibung und den gesamt Verlauf des Threads vorbildlich. Genau so kommt man zum Ziel.

[matze79]

Kann ich mir nicht vorstellen das dass sein Problem ist, dann müsste es ja mit 8Mb Ram laufen ;)

Vieleicht hat die Grafikkarte einfach einen defekt.
Ähnliche Symptome hatte ich mal mit einen teildefekten Bustreiber.

[Dragonsphere]

Auch wenn es wirklich eine einleuchtende Erklärung für die Abstürze und auch für die Fehlermeldung ist, macht mich hier einiges stutzig. Leider gibt es im Bios keine "memory hole" Option, um das einfach testen zu können.

Kann ich mir nicht vorstellen das dass sein Problem ist, dann müsste es ja mit 8Mb Ram laufen ;)

Ganz genau, auch mit nur 4 MB tritt das Problem bei Verwendung der ET4000 auf.

Beide Grafikkarten bringen 1 MB eigenen Speicher mit, der müsste ja gleichermaßen adressiert werden. Aber nur bei einer tritt der Fehler auf. Ich habe ja nur die Karten getauscht, nicht aber die Bioseinstellungen verändert oder noch irgend etwas anderes. Ein Adressierungsproblem müsste also schon von der Grafikkarte ausgehen bzw. an etwas liegen, was die beiden Karten fundamental voneinander unterscheidet.

Wenn ein Adressierungsproblem vorläge, wäre doch die Geschwindigkeit der Karte bzw. des Systembus dafür egal. Aber wenn ich den Bustakt runterschraube läuft die Karte ja.
Als ich heute von der Arbeit kam, fiel mir dazu noch etwas ein: Ich habe neulich auf einer Seite ein Bundle mit verschiednen Tools für Karten mit ET4000 Chip entdeckt und mir mal gespeichert. Dabei ist auch ein kleines Programm, mit dem man die Karte zwischen 8 und 16 Bit Anbindung umstellen kann. Jetzt habe ich gerade die Targa eingebaut und mal ausprobiert. Bei 8 Bit, also halber Geschwindigkeit, macht die Karte alles mit, bei 16 Bit die bekannten Fehler und Abstürze. Alles bei einem ganz normalen Bustakt von 8,25 MHz.

Sobald man die Flut der Videodaten bremst, ist also alles gut. Hohe Datenraten, z.B. bei komplexeren Effekten werden ihr zu viel. Bei den Cracktros, die auch immer Abstürzen, sind es auch vor allem Effekte die auf schnelle Wechsel mehrere Speicherseiten setzen (komplexere Scrolleffekte, Transparenzeffekte u.ä.). Man könnte also meinen, hier ist einfach ein Speichermodul auf der Karte altersschwach geworden. Merkwürdig ist dann doch aber, dass ich sonst keine Grafikfehler o.ä. mit der Karte habe. Ich kann sie sogar übertakten und PCBench, 3DBench etc. laufen ohne Fehler. Ich habe auch schon über eine Stunde lang Tyrian damit gespielt und auch Doom oder sogar Duke Nukem 3D machen keine Probleme. Keine Grafikfehler, keine Abstürze.
Und wie passt hier der Fasttracker II ins Bild? Das Durchlaufen der Pattern ist wohl kaum Höchstleistung für die Grafikkarte. Aber hier kann ich ein bis eineinhalb Minuten lang eine Datei abspielen, bevor er abstürzt und auch bei Second reality treten die Probleme nicht bei den komplexesten Effekten auf, sondern eher nach einer gewissen Zeit. Starte ich das Demo von Anfang an, stürzt es nach dem Scrollen der Landschaft ab, genau dann, wenn das Raumschiff erscheint. Starte ich es an einem späteren Punkt, bei meinem Test mit "Second.exe 3", laufen die ersten Parts und bei den Plasma-Effekten schmiert er dann ab.
Aber es liegt ja definitiv an der Grafikkarte. Ganz seltsam... Könnte es auch ein IRQ-Konflikt o.ä.sein? Wäre mir persönlich bei Grafikkarten allerdings neu und die Belegung wäre ja auch bei geringerem Bustakt oder einer auf nur 8 Bit ISA eingestellten Karte anders. Also wohl irgendein kleiner Fehler auf der Grafikkarte, der aber das ganze Speichermanagement durcheinanderbringt.....

Leider habe ich keinen anderen PC mit ISA-Bus zur Hand, um die Karte mal woanders zu testen.

[Dragonsphere]

Glückwunsch Dragonsphere, dass du dem Fehler auf die Spur gekommen bist. Du hast dich ja auch intensivst damit beschäftigt und den Fehler sehr gut eingegrenzt. Übrigens finde ich deine Fehlerbeschreibung und den gesamt Verlauf des Threads vorbildlich. Genau so kommt man zum Ziel.

Danke! Ich versuche immer alle relevanten Infos zu geben und nachvollziehbar zu beschreiben, was ich schon probiert habe, denn so kann mir geholfen werden und andere haben auch was von dem Thread.
Auch wenn dieser Fehler langsam wirklich zeitintensiv und anstrengend wird, generell begebe ich mich gerne auf Fehlersuche. Erst recht, wenn ich hier dann berichten und mich mit anderen darüber austauschen kann. Dieses nette Forum ist da wirklich sehr motivierend - das muss auch mal gesagt werden :)

[idspispopd]

Ich schließe mich dem Lob an, die Analyse und die Beschreibung des Verhaltens sind wirklich vorbildlich, Dragonsphere!
OK, wenn das Problem auch mit wenig RAM auftritt liegt es nicht am LFB. @matze79: Normalerweise dürfte man das Problem auch erst bekommen, wenn man tatsächlich auf den LFB zugreift. Das könntest Du z.B. mit Duke3D testen, dann muss VESA 2.0 Support vorhanden sein (ggf. per TSR) und vermutlich eine höhere Auflösung als 320x200 gewählt werden. Erkennen sollte er das dann automatisch.

Dein letzter Post mit der Umschaltung auf 8 bit etc. ist aber sehr interessant. Für 8-bit-Portzugriffe gilt eine andere (normalerweise höhere) IO Recovery Time als für 16-bit-Zugriffe. In einem früheren Post hast Du geschrieben dass die auf 12 Takte eingestellt ist, ich weiß nicht ob das dann für 8 und 16 bit gilt. Jedenfalls würde es passen dass das Problem damit zu tun hat, weil es ja funktioniert einfach jede Menge Bilddaten zur Karte zu schicken (Tyrian, Doom, Duke3D), während es bei Programmen die vermutlich viele Portzugriffe nacheinander machen Probleme gibt (z.B. Scrollen). Was Fasttracker genau macht weiß ich leider nicht.
Leider hätte ich keine Idee was man machen kann wenn das das Problem ist. Eine Umstellung auf 8 bit ist keine Lösung, damit bremst man die Karte massiv aus, eine Absenkung des Bustakts stört weniger. Und im BIOS hast Du ja schon den Maximalwert eingestellt.
Vielleicht gibt ein Tool das den Chipsatz unterstützt und mit dem man gucken kann, auf welche Werte die 8- und 16-bit IO Recovery Time tatsächlich gestellt sind und diese evtl. noch hochdrehen kann? Es gab solche Tools, mir fällt aber leider gerade keines ein. Für die Performance sollte das jedenfalls nicht viel ausmachen.

[matze79]

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

@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.