Seite 2 von 2

Re: Nicht genügend Erweiterungsspeicher, um Windows zu start

Verfasst: Fr 22. Jan 2016, 15:03
von idspispopd
Spannend, das hätte ich jetzt gar nicht erwartet.
Vielleicht ist die Datei wirklich ein SoftSynth? Das würde ja dazu passen dass sie nicht mehr vermisst wird wenn man DelSoftSynth=1 einstellt.
Was für eine Midi-Ausgabe bekommst Du denn jetzt? Einfach OPL2 oder OPL3? (Also Synthi-mäßig.) Der Mapper müsste das eigentlich auch anzeigen.
Die Treiber für den OPL3-SAx enthalten einen Softsynth. Vermutlich hast Du eine Software-Wavetable-Lösung wenn Du den Treiber drinlässt und er funktioniert. Wenn Du Lust hast kannst Du den Treiber ja nochmal reinnehmen, Windows ohne Netzwerk starten und testen wie sich Midi-Dateien damit anhören.

Re: Nicht genügend Erweiterungsspeicher, um Windows zu start

Verfasst: Fr 22. Jan 2016, 15:32
von ConiKost
idspispopd hat geschrieben:Spannend, das hätte ich jetzt gar nicht erwartet.
Vielleicht ist die Datei wirklich ein SoftSynth? Das würde ja dazu passen dass sie nicht mehr vermisst wird wenn man DelSoftSynth=1 einstellt.
Was für eine Midi-Ausgabe bekommst Du denn jetzt? Einfach OPL2 oder OPL3? (Also Synthi-mäßig.) Der Mapper müsste das eigentlich auch anzeigen.
Die Treiber für den OPL3-SAx enthalten einen Softsynth. Vermutlich hast Du eine Software-Wavetable-Lösung wenn Du den Treiber drinlässt und er funktioniert. Wenn Du Lust hast kannst Du den Treiber ja nochmal reinnehmen, Windows ohne Netzwerk starten und testen wie sich Midi-Dateien damit anhören.
Also im Midi-Mapper ist eingetragen "OPL3-SA FM MIDI". Dieser ist aber auch eingetragen, wenn die VSGM.386 läuft.

Aber du hast recht. Im Midi-Mapper gibt es auch noch eine weitere Auswahl "OPL3-SA YSYNTH". Das ist offenbar der SoftSynth. Ohne geladene VSGM.386 funktioniert dieser nicht. Mit aktiver VSGM.386 läufts und klingt deutlich anders (besser)

Schade, dass das Ding aber den Bug hat und sich nicht laden lässt :<

Re: Nicht genügend Erweiterungsspeicher, um Windows zu start

Verfasst: Fr 22. Jan 2016, 16:36
von idspispopd
Es wird schon noch andere Softsynths für WfW geben, die evtl. sogar besser sind.

Re: Nicht genügend Erweiterungsspeicher, um Windows zu start

Verfasst: Fr 22. Jan 2016, 16:38
von ConiKost
idspispopd hat geschrieben:Es wird schon noch andere Softsynths für WfW geben, die evtl. sogar besser sind.
Ist nicht so tragisch ;) 9x/ME sind auch noch parallel drauf und da läuft ja der Soft Synth.

Re: Nicht genügend Erweiterungsspeicher, um Windows zu start

Verfasst: Sa 30. Jan 2016, 10:39
von go32
Da muss ich mal eine Verständnisfrage los werden:

Da ja mit FreeDOS dieses gute alte Betriebssystem neu aufgelegt wird, hätte man da nicht die Frickelei mit dem Speicherzugriff anders lösen können?

Laufen die alten DOS Programme wirklich nur dann, wenn sie den Speicher in 640Kilobyte konverntionellen Speicher, UMB und den Bereich oberhalb 1 MByte aufgeteilt vorfinden?

Warum nicht einen bis zur 16 Bit Maximalgrenze durchaddressierbaren Speicher, in dem dann das Programm die Speicherbereiche nutzt wie gehabt.

Mein Verständnis für das Laden und den Ablauf eines Programmes sieht etwa so aus:

- Programm laden (.com an Adresse 100Hex, 256Dezimal, .exe variabel)
- Dabei Speicher belegen, das Programm könnte bei durchaddressierbarem Speicher die benötigten Adressen ebenso belegen, wie wenn der UMB vorher reserviert wurde.

- Dann könnte doch der Speichermanager entfallen, der Speicher wäre durchgehend gemäß Wortbreite und damit gegebener Obergrenze adressierbar.


Habe ich irgendeinen Aspekt übersehen, der diese frickelige Speicheraufteilung halt doch zwingend erforderlich macht?

Re: Nicht genügend Erweiterungsspeicher, um Windows zu start

Verfasst: Sa 30. Jan 2016, 11:19
von kpanic
Also, fangen wir mal an.
Ein normales DOS-Programm nutzt normalerweise weder UMB noch XMS.
Ein normales DOS-Programm erwartet das Speicherlayout genau so, wie IBM es mit dem Ur-PC und Intel mit dem 8086 vorgegeben hat.
Der 8086/8088 kann mit seinen 20 Adressleitungen maximal 1MB RAM adressieren.
Da die CPU 16bit-Register verwendet um auf den Speicher zuzugreifen, wird der Speicher segmentiert. Der Zugriff erfolgt immer mit Segment:Offset. Sowohl die Segment- als auch die Offsetadresse sind 16bittig. Ein Speichersegment ist daher immer 64k groß.
So gesehen ist der Speicher unter DOS bis zur 16bit-Maximalgrenze durchadressierbar. Und das mehrmals.

Ein normales DOS-Programm läuft daher immer im konventionellen Speicher.
Für seine Daten kann es zwar über von Speichermanagern bereitgestellte Schnittstellen auf XMS oder EMS zugreifen, das eigentliche Programm läuft aber immer noch im Real Mode.
Ausnahmen sind Protected-Mode-Programme, die über einen DOS-Extender gestartet werden.
Dort wird der Prozessor dann von einem kurzen Real-Mode-Programm in den Protected Mode versetzt, in dem dann der volle Speicher zusammenhängend genutzt werden kann. Dafür sind dort dann alle BIOS- und DOS-Funktionen nicht mehr verfügbar, auf denen normale Programme aufbauen.
Du siehst also:
Natürlich könnte man den Speicher heutzutage einfach immer am Stück adressieren.
Allerdings wäre das nicht mehr kompatibel zu auch nur einem einzigen DOS-Programm.
Das ging damals schon mit UNIX (z.B. XENIX), später mit Windows 95, Linux usw...
Das was du meinst, ist eigentlich genau das, was Windows im erweiterten 386 Modus tut. Ein DOS-Programm im virtuellen Real Mode starten.