du meinst die vorletzte zeile in der confg.sys?
die muss ich kopieren und dann die jeweilen stellen probieren?
wie das überhaupt? hat doch vorher auch geklappt, oder hat das jetzt was mit dem singlespeed laufwerk zu tun?
Ja, es geht um die Zeile, die die SGNOVA16 bestiefelt. Du hast uns immer noch nicht verraten, was EEPROM.SYS eigentlich macht.
Die Zeile muss "verschoben" und nicht "kopiert" werden.
Warum es mit der jetzigen Position dieser Zeile nicht klappt, kann an allem möglichen liegen.
Wenn es mit dieser Zeile an einer anderen Position in der CONFIG.SYS keine Fehlermeldungen mehr dazu gibt, ist die Ausgabe von mem /c unter reinem DOS interessant, um zu sehen, was alles noch im konventionellen Speicher liegt.
so also,
habe alle 3 zeilen ausprobiert und bei der letzten mal screens mit hochgeladen was dann für ne meldung kommt, egal ob 1. 2. oder 3. zeile.
[…]
und vllt. hilft es ja: einen screen noch von der funktionierenden config.sys
Schau Dir mal die entsprechende Zeile in beiden CONFIG.SYS ganz genau an, und nimm dazu die Fehlermeldung, die jetzt kommt. Die muss auch kommen, denn in der neuen CONFIG.SYS hat sich ein typo eingeschlichen. Es muss …\SGNOVA16\DRIVERS\… heißen. Dass die Datei EEPROM.SYS bei einer falschen Pfadangabe nicht gefunden werden kann, ist irgendwie zwingend.
Jetzt kommt die Kür, also das frei schaufeln von möglichst viel konvetionellem Speicher.
Unter MS-DOS ist der Befehl mem /c /p angesagt, da MS-DOS keinen Bildschirmpuffer zum zurück rollen hat. Die zusätzliche Option /p sorgt dafür, dass die Ausgabe seitenweise erfolgt. Interessant ist die erste Seite, die zeigt, welche Programme im konventionellen Speicher residieren und welche im hohen Speicher. Idealerweise residieren im konventionellen Speicher nur die vier unvermeidlichen:
MSDOS
HIMEM
EMM386
COMMAND
Der Rest sollte im hohen Speicher residieren. Auf dieser Kiste ist das so, es sind 627184 Byte ≈ 612 KiB konventioneller Speicher frei.
Also ich lese nur draus, dass der Treiber geladen wurde. Ne Fehlermeldung ist da nicht... Aber wenns nicht geht, dann gehts wohl nicht. Weiß garnicht ob bei falschen Treiber überhaupt nen Laufwerksbuchstabe vorhanden wäre...
Wie gesagt Mitsumi hat mehrere Arten von CD-ROM Laufwerken hergestellt. Propertiäre, die nur mit der/einer Controllerkarte laufen und normale Atapi. Beide haben dabei die dumme angewohnheit 40 polige Kabel zu verwenden. Bei Sony waren die propertären 34 polig oder so. Aber man sollte Sie dadurch auseinanderhalten können das Atapi Modelle stets nen Jumperblock für Master/slave haben. Mein letztes Mitsumi Doublespeed ist inzwischen Jahrzehnte her, ich meine aber, diese Funktion gab es da nicht.
Es sind jetzt zuviele Seiten und Bilder. Aber auf dem Laufwerk sollte ja was stehen. Wenns nen Atapi ist, probier die Treiber von der Win 95 diskette durch (möglicherweise sogar mit der Win 95 Bootdiskette, zu finden in den Winhistory.de downloads). Wenn da einer läuft, wirds wohl auch auf nen normalen DOS so laufen. Dann kann man den Treiber auf dein System kopieren und gegebenfalls anpassen (umbennnen/config.sys umschreiben). Läufts nicht, ist die Chance hoch, das deine Kombi so nicht läuft, oder man nen exotischen Treiber braucht.
das CD ROMlaufwerk geht aber trotzdem immer noch nicht, er hat wohl den treiber geladen, kann aber das laufwerk nicht finden, zumindest lese ich das da raus.
Der Bildschirminhalt zeigt folgendes:
MTMCDE wird geladen, aber MSCDEX nicht.
MOUSE liegt unsinnigerweise im konventionellen Speicher.
Es ist insgesamt wenig hoher Speicher vorhanden.
Benötigt werden:
aktuelle CONFIG.SYS
aktuelle AUTOEXEC.BAT
Bildschirminhalt unmittelbar nach dem Ende des DOS-Starts.
so da haste direkt nach dem DOSstart!
Wo denn? Da sind nur config.sys und autoexec.bat.
ganz am ende steht ja auch noch "datei nicht gefunden"
Existiert die Datei C:\CDDRIVER\MSCDEX.EXE überhaupt?
autoexec.bat:
Stell vor das C:\mouse.com ein LH, damit das nicht mehr im konventionellen Speicher landet.
Wenn im System keine Monochrom-Grafikkarte steckt, kann der dafür reservierte UMB anderen Programmen zur Verfügung gestellt werden. Dazu wird die EMM386-Zeile in der CONFIG.SYS um den Parameter I=B000-B7FF ergänzt. Dadurch steht mehr hoher Speicher zur Verfügung, was hier noch wichtig werden könnte.
DEVICE=C:\WINDOWS\EMM386.EXE RAM HIGHSCAN [b]I=B000-B7FF[/b] /V
und was machen wir jetzt mit diesem "MODE"
Damit wird die von DOS verwendete Codepage festgelegt. Das ist unter anderem wichtig, damit beim Drücken der entsprechenden Taste(nkombination) auch das gewünschte Zeichen ausgegeben wird. Für westeuropäische Sprachen ist die Codepage 850 meist eine gute Wahl. Wer mit DOS natur- oder ingenieurwissenschaftlich unterwegs war (oder noch ist), nahm (oder nimmt) lieber die Codepage 437. Wer ein nichtlateinisches Alphabet (kyrillisch, griechisch, …) braucht(e), nahm (oder nimmt) die entsprechenden Codepages. Würde MODE bei Dir nicht funktionieren, käme als Fehlermeldung "Codeseite nicht vorbereitet". Diese Fehlermeldung bekamst Du, als noch der Fehler in der einen MODE-Zeile steckte.
Damit wird die von DOS verwendete Codepage festgelegt. Das ist unter anderem wichtig, damit beim Drücken der entsprechenden Taste(nkombination) auch das gewünschte Zeichen ausgegeben wird. Für westeuropäische Sprachen ist die Codepage 850 meist eine gute Wahl. Wer mit DOS natur- oder ingenieurwissenschaftlich unterwegs war (oder noch ist), nahm (oder nimmt) lieber die Codepage 437. Wer ein nichtlateinisches Alphabet (kyrillisch, griechisch, …) braucht(e), nahm (oder nimmt) die entsprechenden Codepages. Würde MODE bei Dir nicht funktionieren, käme als Fehlermeldung "Codeseite nicht vorbereitet". Diese Fehlermeldung bekamst Du, als noch der Fehler in der einen MODE-Zeile steckte.
Wenn man sowohl den COUNTRY-Eintrag in der CONFIG.SYS als auch den KEYB-Eintrag mit Codepage 437 benutzt, kann man sich die MODE-Aufrufe schenken und spart wimre auch ein paar kBytes DOS-Speicher. Ein deutsches Tastaturlayout hat man dann trotzdem noch.
Wenn man sowohl den COUNTRY-Eintrag in der CONFIG.SYS als auch den KEYB-Eintrag mit Codepage 437 benutzt, kann man sich die MODE-Aufrufe schenken und spart wimre auch ein paar kBytes DOS-Speicher. Ein deutsches Tastaturlayout hat man dann trotzdem noch.
Verwirr VolvoDriver nicht so. 
Das geht meines Wissens nämlich nur mit der Codepage 437, weil das der Originalzeichensatz des IBM-PC und somit ein fallback ist.
also wie folgt:
hoffe das ist jetzt das bild, was du noch benötigt hast?!
mit dem LH in der 1. zeile mit der mouse habe ich erledigt.
desweiteren DEVICE=C:\WINDOWS\EMM386.EXE RAM HIGHSCAN I=B000-B7FF /V auch eingetragen. (verbaut habe ich eine Tseng Labs ET4000)
die zeile mit dem MODE kann doch dann auch raus, oder nicht, war ja vorher auch nicht da?!
offensichtlich gibt es die datei MSCDEX.EXE gar nicht in dem ordner CDDRIVER, dachte die würde von C:\WINDOWS geladen werden, dort ist ja eine vorhanden und der pfad ist doch von der autoexec.bat doch korrekt, oder nicht?
mir ist dann noch eingefallen, dass ich ein setuprogramm von der org. treiber-diskette gestartet habe und ich glaube der hat dort die MSCDEX.EXE überschrieben, könnte vllt. auch das problem sein. habe auch noch mal ein foto mit angehängt, wo du sehen kannst was alles auf der diskette drauf ist.
eine fehlermeldung kommt jetzt allerdings, die aber dann nach 5 sek. verschwindet und DOS dann weiter gebootet wird 
desweiteren DEVICE=C:\WINDOWS\EMM386.EXE RAM HIGHSCAN I=B000-B7FF /V auch eingetragen. (verbaut habe ich eine Tseng Labs ET4000)
Nein, hast Du nicht! Schau Dir Deinen Eintrag mal ganz genau an! Da fehlt der Bindestrich zwischen B000 und B7FF, was zu der Fehlermeldung "Unzulässiger Parameter angegeben" führt.
Das ist jetzt nicht das erste Mal, dass Du Zeichen einzutragen vergisst …
die zeile mit dem MODE kann doch dann auch raus, oder nicht, war ja vorher auch nicht da?!
Nein! Das gilt nur, wenn Du die Codepage 437 verwenden möchtest. Wenn Du eine andere Codepage (hier: 850) verwendet, müssen die beiden MODE-Zeilen drin bleiben. Wo ist das Problem? MODE arbeitet fehlerfrei.
offensichtlich gibt es die datei MSCDEX.EXE gar nicht in dem ordner CDDRIVER, dachte die würde von C:\WINDOWS geladen werden, dort ist ja eine vorhanden und der pfad ist doch von der autoexec.bat doch korrekt, oder nicht?
Nein, ist falsch!
Du gibst in der AUTOEXEC.BAT den absoluten Pfad C:\CDDRIVER\MSCDEX.EXE an. Wenn dort die Datei nicht liegt, wird auch nicht weiter danach gesucht. Die mit PATH definierten Pfade greifen nur, wenn kein absoluter Pfad angegen wird.
Die MSCDEX.EXE von der LU005-Treiberdiskette muss nach C:\CDDRIVER kopiert werden.
Das ist jetzt nicht das erste Mal, dass Du versuchst eine Datei zu laden, die an der Stelle gar nicht vorhanden ist …
werde ich gleich alles einstellen, nur warum muss das in CDDRIVER sein?
Du kannst die Dateien MTMCDE.SYS und MSCDEX.EXE auch in C:\PUMUCKL oder sonstwo speichern. In CONFIG.SYS und AUTOEXEC.BAT werden die absoluten Pfade angegeben, damit die Dateien gefunden werden, also
DEVICEHIGH C:\PUMUCKL\MTMCDE.SYS …
und
LH C:\PUMUCKL\MSCDEX.EXE …
Beim Laden von Treibern sollte aus Gründen der Übersichtlichkeit auch dann der absolute Pfad angegebn werden, wenn zuvor mit PATH Suchpfade definiert wurden.
der pfad mit windows war ja schon angegeben, oder muss der auch dort zusätzlich da stehen?
s. o.
PATH C:\WINDOWSLH MSCDEX.EXE …
führt dazu, dass C:\WINDOWS\MSCDEX.EXE geladen wird. Übersichtlich ist anders!
PATH C:\WINDOWSLH C:\PUMUCKL\MSCDEX.EXE …
führt dazu, dass C:\PUMUCKL\MSCDEX.EXE geladen wird. Die Angabe des Suchpfades C:\WINDOWS spielt dafür keine Geige. Existiert C:\PUMUCKL\MSCDEX.EXE nicht, kommt die Fehlermeldung "Datei nicht gefunden".
und nen fehler von wegen falscher DOS version wird mir nun auch angezeigt!
Das bedeutet, dass die MSCDEX.EXE von der LU005-Treiberdiskette nicht so ohen weiteres kompatibel zu MS-DOS 6.22 ist.
1. Versuch:
Ändere in der AUTOEXEC.BAT den Eintrag
LH C:\[b]CDDRIVER[/b]\MSCDEX.EXE …
in
LH C:\[b]WINDOWS[/b]\MSCDEX.EXE …
und starte neu.
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!
