DOS Rechner hat Speicherprobleme

[Mr. Vain]

(11.02.2013 00:38)Magic94 schrieb:  Ich könnte die Karte mal in einem Pentium 3 Rechner probieren.
Die haben ja auch noch ISA.

Dieser DOS Rechner hat auch schon ein neues Board.. vorher war ein Abit PR-5 drinne. Ist aber auch schon verreckt.
Das Board was jetzt drin ist hat nen völlig zerstörten IDE Controller. Hängt irgendwas über IDE dran gibt die Kiste nur noch Wirre Zeichen aus (deswegen auch SCSI)

Bei dem PIII musst aber auch die Festplatte mit dem DOS mitnehmen oder ne alte kleine DOS Festplatte reinhaengen. Kann sein, dass sich manche Fehler eben nur unter DOS oder 16Bit Windows zeigen (wegen der speziellen Treiber), aber unter neueren Windows auf einmal alles einwandfrei funktioniert mit den Windows Standardtreibern.

Wenn aber schon Defekte am Board (IDE Bereich) sind, dann kann es schon sein, dass es derart angeknackst ist, dass auch andere Komponenten bereits betroffen sind. Deswegen auf jeden Fall mit nen anderen Board testen.

Bei meinem Soyo Sockel 7 Board modifiziere ich auch nochmal den RTC, mal sehen, obs dann kuriert ist. Aber son ASUS P55T2P4 (mit funktionierendem Dallas RTC) lass ich mir trotzdem noch zukommen demnaechst. Ich dachte, die So. 7 Boards sind noch recht robust...

[Magic94]

(11.02.2013 12:30)Mr. Vain schrieb:  Bei dem PIII musst aber auch die Festplatte mit dem DOS mitnehmen oder ne alte kleine DOS Festplatte reinhaengen.

Ich wollte dann eben ein DOS auf ner kleinen Platte da installieren. Ist ja schnell gemacht

(11.02.2013 12:30)Mr. Vain schrieb:  Kann sein, dass sich manche Fehler eben nur unter DOS oder 16Bit Windows zeigen (wegen der speziellen Treiber), aber unter neueren Windows auf einmal alles einwandfrei funktioniert mit den Windows Standardtreibern.

Nichts für ungut aber die Gravis Ultrasound Classic läuft eh nur unter DOS und 3.11 Windows 95 und 98 ist schon Bastelei. Alles was drüberliegt führt nur noch zu elendem quietschen aus der Soundkarte. Für ne GUS gibts auch keine Windows Standard Treiber. Ist ja afaik auch Kanadischer non-PnP Mist

(11.02.2013 12:30)Mr. Vain schrieb:  Bei meinem Soyo Sockel 7 Board modifiziere ich auch nochmal den RTC, mal sehen, obs dann kuriert ist. Aber son ASUS P55T2P4 (mit funktionierendem Dallas RTC) lass ich mir trotzdem noch zukommen demnaechst. Ich dachte, die So. 7 Boards sind noch recht robust...

Geht.. nicht mehr wirklich. Die lassen ziemlich nach.
Wobei bei meinem tatsächlich die RTC noch tickt (oh Wunder)

[Mr. Vain]

(11.02.2013 12:41)Magic94 schrieb:  Wobei bei meinem tatsächlich die RTC noch tickt (oh Wunder)

Dann haste Glueck, der is naemlich fest verloetet auf dem ASUS. Aber is kein Problem, es gibt ja das hier http://www.amoretro.de/guides-workshops/...difizieren

[Magic94]

(11.02.2013 13:07)Mr. Vain schrieb:  

(11.02.2013 12:41)Magic94 schrieb:  Wobei bei meinem tatsächlich die RTC noch tickt (oh Wunder)

Dann haste Glueck, der is naemlich fest verloetet auf dem ASUS. Aber is kein Problem, es gibt ja das hier http://www.amoretro.de/guides-workshops/...difizieren

Ich weiss ich weiss und die Fausformel ist ja, dass die Dinger nach ca. 10 Jahren den Geist aufgeben.
Meiner hält nun fast schon 20 Jahre

[Coburg-M]

hmm, ich schieb die schuld aber immernoch auf die config.sys und autoexec.bat...

mit LH und Devicehigh kann man da noch etwas rausholen... aber so oder so, die ultrasound-treiber hätt ich nach himem und emm386 mit devicehigh gesetzt.

in der autoexec.bat würd ich die mouse.com und das drunter mit LH auch hochladen.

Lastdrive würd ich auf e oder f setzen, je nach dem, was der letzte laufwerksbuchstabe ist, noch 2 höher gehen. z. B. D ist das letzte physikalische lauferk, dann würd ich in die Config.sys lastdrive=F schreiben

[Mr. Vain]

Die Soundtreiber lassen sich meistens nicht in den hohen Speicher laden bzw. funktionieren dann nicht. Die muessen dann in den konventionellen Speicher geladen werden. Aber alles andere kann man versuchen, in den hohen Speicher zu laden. Der Maustreiber is der Standard Microsoft Ding? Probier mal den CTMOUSE.EXE von der c't, der is nur 1K gross und laedt sich automatisch in den Hohen Speicher. Tastaturtreiber hab ich auch mal keyb2.sys und dazu keyb2.com probiert, geht auch in den Hohen Speicher und verbraucht da etwa 4K.

Bei der CONFIG.SYS hab ich als erste Eintraege auch immer stehen:

device=[pfad]himem.sys
device=[pfad]emm386.exe noems (bei dir muss es dann ram sein, wenns mit XMS nich funktioniert)
DOS=HIGH,UMB
STACKS=
BUFFERS=
FILES=
...dann alles andere, und am besten auch etwas sortiert

In der AUTOEXEC.BAT fang ich immer so an:

@ECHO OFF
PROMPT $P$G
...die ganzen SET Commands und PATH
...die EXEs und COMs usw

Bei loadhigh bzw. LH geb ich immer keine weiteren Parameter wie /L x:xxx und sowas an, dann sucht sich das schon von allein nen Platz im Hohen Speicher.

[Igor Todeshure]

(11.02.2013 15:48)Mr. Vain schrieb:  In der AUTOEXEC.BAT fang ich immer so an:

@ECHO OFF
PROMPT $P$G
...die ganzen SET Commands und PATH
...die EXEs und COMs usw

Bei loadhigh bzw. LH geb ich immer keine weiteren Parameter wie /L x:xxx und sowas an, dann sucht sich das schon von allein nen Platz im Hohen Speicher.

Wer wirklich maximalen freien RAM haben will, setzt die ganzen "SET"-Einträge ganz zum Schluß. Die liegen nämlich im sog. Environment, welches jedem residenten Kommando als Kopie beigegeben wird und RAM belegt, selbst wenn die residenten Programme die nie auswerten.

[Magic94]

so, nachdem ich jetzt die beiden Systemdateien jetzt mal nach allen regeln der Kunst aufgeräumt hab, hat sich etwas geändert!
SBOS verreckt nicht mehr am Stapelüberlauf - startet aber auch nicht... bleibt einfach stehen
PLAYMIDI exakt das selbe.

EDIT: Hab was gefunden... verstehen tu ichs noch nicht, aber da könnt ihr mir sicher helfen

Habe grade den GUS-Setup nochmal ausgeführt und ihn den Ressourcencheck machen lassen.

"Testing SoundBlaster selections ... Failed"
"Multiple SBOS IRQ's generated"

Werde jetzt also mal ein bisschen an den IRQs rumdrehen.
(PS: Kann es sein das der neue SCSI Controller schuld ist?)

EDIT2: der SCSI Controller mietet sich IRQ 10. kommt sich also schonmal nicht in die quere.
Habe der GUS jetzt mal für MIDI und Soundblaster-sachen IRQ 3 und DMA 1 gesichert im BIOS. Dennoch, wenn ich die neue einstellung teste kommt:

Zitat:I/O Channel Check - Checking for Segment...
Offending Segment:
0000
Preiss F1 to disable NMI, F2 to reboot

F1 ändert nix.. F2 .. ja

EDIT3: IRQ 7 und 12 gesichert im BIOS
und schon klappt wieder mit dem Nachbarn...

Danke an alle

[Mr. Vain]

funktionierts jetz also alles wieder?

Es kann auch passieren, dass die Treiberdateien beschaedigt werden oder irgendwie kaputt gehen koennen. Ich hatte das mal bei CTCM.EXE von meiner AWE64 Gold gehabt, keine Ahnung wie sowas passieren kann, aber als ich die Datei von der CD wieder neu auf die Platte kopiert habe, oh wunder es lief wieder

[Magic94]

(11.02.2013 23:44)Mr. Vain schrieb:  funktionierts jetz also alles wieder?

Es kann auch passieren, dass die Treiberdateien beschaedigt werden oder irgendwie kaputt gehen koennen. Ich hatte das mal bei CTCM.EXE von meiner AWE64 Gold gehabt, keine Ahnung wie sowas passieren kann, aber als ich die Datei von der CD wieder neu auf die Platte kopiert habe, oh wunder es lief wieder

hab mich mit ein paar MIDI Files gehabt. gingen auch flöten.
Aber dafür zieh ich von der Kiste monatlich eine Sicherung.

Naja jetzt muss ich nur noch den Adlib Tracker II dazu treten sich die GUS zu nehmen und dann kann es wieder losgehen