DOS Rechner hat Speicherprobleme

[Magic94]

Hallo, mein guter alter DOS-Allrounder macht mir echt Probleme in letzter Zeit.
Erstmal zur Hardware:

CPU: Intel Pentium MMX @ 200MHz
Board: Intel P55T2P4 (Standard AT-Sockel7 Brötchen)
RAM: 64MB EDO RAM (alles die gleichen Riegel)
Festplatten Controller: Tekram DC-390 (SCSI)
Festplatte: IBM Deskstar mit 4,7GB (SCSI)
Netzwerk: Realtek 8139
Grafik 1: S3 Virge
Grafik 2: 3DFX Voodoo 1
Sound: Gravis Ultrasound Classic (Rev. 2.4)

viel Hardware fürn Oldie...

Nun macht der Rechner seit neustem Probleme mit "dem Speicher" (welcher Speicher dabei rumheult ist mir ein Rätsel)
Meistens tritt der Fehler aber auf, wenn ich die original Programme der Gravis Ultrasound nutzen will (wie z.B. PlayMIDI oder SBOS) Der PC bleibt einfach hängen, und wenn ich nach ein paar Minuten mal etwas auf der Tastatur rumdrücke:
"Überlauf des internen Stapelspeichers - System gestoppt"

Meine Lösungsansätze bisher:
1: Der Speicher der GUS ist hinüber. Also mal einen Tracker genommen der noch startet (Impulse Tracker II) eine .mod genommen die ca. 1MB beträgt und somit den RAM der GUS komplett voll macht - lief. Andere Tracker laufen mit der Karte auch noch und die MIDI wiedergabe ist über den Open Cubic Player auch noch drin.
Wäre also schonmal wiederlegt das es der Speicher des GUS ist.

2: erster MB des RAMs voll. Also mal gründlich autoexec und config.sys geleert, eine Demo gestartet die auch nur dann startet wenn ich autoexec und config.sys wirklich gut geleert habe (sonst mecker die Demo es wäre nicht genug speicher zur verfügung).
Demo ist gestartet (Sprich war also genug Speicher da, und die Demo lief auch Fehlerfrei)

3: HIMEM oder EMM386 mal wieder.
Beide also rausgenommen.

4: RAM einfach trotzdem irgendwie Schrott?
Also mal RAM getauscht. Alle 4 Riegel ersetzt. Hatte dann zwar nur noch 32MB, aber das ist DOS ... da ist selbst 32MB schon viel.

Leider haben alle 4 Lösungsansätze keinerlei Änderung gebracht. Die Programme der GUS lassen sich nicht mehr starten (und ich brauche sie leider regelmäßig).

Habt ihr Ideen was es sein könnte?

PS: Ich habe nichts an dem PC geändert.. der Fehler kam wie von selbst.. Zauberei
PPS: Was ich vielleicht noch erwähnen sollte: Der PC erkennt beim starten manchmal nicht den kompletten RAM. Dann muss ich den PC abschalten, einmal wie bei den Nintendomodulen alles rausnehmen, durchpusten und wieder reinsetzen - läuft. MEMTEST meckert ebenfalls nicht

[Dirk]

mit memtest86 kannst du den arbeitsspeicher gut testen, gibt auch ne ältere floppyvariante.

Aber ich denke nicht das der speicher das problem ist. klingt bei dir mehr nach dem programmspeicher, nen stack overflow, ist schlicht nen programmierfehler. tendenziell würde ich denken dass es nen treiber ist.

[Magic94]

(09.02.2013 11:18)Dirk schrieb:  mit memtest86 kannst du den arbeitsspeicher gut testen, gibt auch ne ältere floppyvariante.

Aber ich denke nicht das der speicher das problem ist. klingt bei dir mehr nach dem programmspeicher, nen stack overflow, ist schlicht nen programmierfehler. tendenziell würde ich denken dass es nen treiber ist.

Memtest-86 v3.4 läuft grade drüber.

Programmfehler? Treiber? .. aber wie? Er lief ja schonmal. Nur seit neustem gehen die Programme der GUS nicht mehr. Am Treiber selber hab ich nichts geändert. Muss also irgendwas von ausserhalb sein schätze ich mal

[Igor Todeshure]

Die Fehlermeldung hat nur indirekt etwas mit dem Speicher zutun, vielmehr mit von DOS bei der Interruptverarbeitung eingerichteten "stacks", die im deutschen DOS "Stapelspeicher" heißen. In der CONFIG.SYS befindet sich nach einer Standardinstallation eine Zeile
STACKS=9,256
oder so ähnlich. Einem Praxistip einer alten c't zufolge sollte man das besser in "STACKS=0,0" ändern, da diese Stapelspeicherverwaltung in DOS fehlerhaft implementiert ist.

[Mr. Vain]

kann man dann den STACKS Befehl nicht einfach gleich weglassen? Bei meiner DOS 6.22 Installation stand die Zeile mit den Stacks auch nicht standardmaessig drin, fuegt erst ne Treiberinstallation (welche? wahrscheinlich Creative) nachher hinzu.

[Igor Todeshure]

Wenn man die Zeile gar nicht drinstehen hat, werden irgendwelche default-Werte verwendet. Nur bei "STACKS=0,0" ist der Rotz definitiv deaktiviert.

[Magic94]

Gab leider keine Änderungen.
Deswegen hab ich hier jetzt mal die Autoexec.bat und die Config.sys für euch. vielleicht seht ihr ja was.

Autoexec.bat:

Zitat:SET ULTRASND=240,1,1,12,7
SET BLASTER=A240 I7 D1 T1
SET ULTRADIR=C:\ULTRASND
SET GUSMOD=C:\ULTRASND\MOD
C:\ULTRASND\ULTRINIT.EXE -ej
REM C:\WINDOWS\net start
@ECHO OFF
PROMPT $P$G
PATH C:\;C:\DOS;D:\;D:\TERM;C:\TERM;;C:\ULTRASND;C:\PROGS\CCS64;
PATH=C:\DELPHI\QIBLOCAL\BIN;%PATH%;C:\ULTRASND
SET TEMP=C:\tmp
SET TERMPCX=E:\TERM
SET TERMDIR=C:\TERM
rem SET DRIVE=D
set dircmd=/p/ogn
LH /L:1,6512 c:\dos\doskey
copy aperture.txt con
REM LH /L:1,27952 MSCDEX.EXE /D:banana /L:R
C:\MOUSE\MOUSE.COM
C:\TCP\RTSPKT.COM 0x60
set MTCPCFG=C:\TCP\SAMPLE.CFG
DHCP -retries 2
DOSSHELL

Config.sys:

Zitat:DEVICE=C:\ULTRASND\ULTRINIT.SYS ULTRASND=240,1,1,12,7
DEVICE=C:\DOS\HIMEM.SYS /testmem:off
DEVICE=C:\DOS\EMM386.EXE RAM
STACK=0,0sd
BUFFERS=15,0
FILES=50
DOS=UMB
LASTDRIVE=Z
FCBS=4,0
DOS=HIGH
REM COUNTRY=049,437,C:\DOS\COUNTRY.SYS
REM DEVICEHIGH /L:1,33760 =C:\DOS\CD1.SYS /D:BANANA
DEVICE=C:\MOUSE\MOUSE.SYS

[Dirk]

wieviel speicher hast du noch?

Code:

mem

[Mr. Vain]

Ich nehm bei mir immer DOS=HIGH,UMB

Wozu brauchst du den EMS Speicher? Geht es nicht mit XMS?

[ChrisKuhli]

Der STACKS hat ein "leicht" semantisches "sd" Problem hinter der zweiten Null!!!

Meine: NICHT Stack=0,0sd

STACKS=0,0

Oder ?