Nicht genügend Erweiterungsspeicher, um Windows zu starten

Spiele, Software, Hardware, etc. zum Thema 16-bit Windows bis 3.x
idspispopd
Norton Commander
Beiträge: 108
Registriert: Fr 8. Mai 2015, 22:28
Wohnort: Hamburg

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

Beitrag 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.
ConiKost
CONFIG.SYS-Autor
Beiträge: 265
Registriert: So 8. Mai 2005, 21:29

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

Beitrag 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 :<
Shuttle HOT-433 | AMD Am5x86 @ 133 MHz | 4x Kingston 64MB EDO-RAM
Matrox G200 + DVI Module | Miro Hiscore 3D | Creative SB AWE64 Gold, Creative 24MB RAM
Toshiba Libretto 110CT | Pentium MMX @ 266 MHz | 96MB RAM| NeoMagic MagicGraph 128XD | Yamaha OPL3SA
idspispopd
Norton Commander
Beiträge: 108
Registriert: Fr 8. Mai 2015, 22:28
Wohnort: Hamburg

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

Beitrag von idspispopd »

Es wird schon noch andere Softsynths für WfW geben, die evtl. sogar besser sind.
ConiKost
CONFIG.SYS-Autor
Beiträge: 265
Registriert: So 8. Mai 2005, 21:29

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

Beitrag 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.
Shuttle HOT-433 | AMD Am5x86 @ 133 MHz | 4x Kingston 64MB EDO-RAM
Matrox G200 + DVI Module | Miro Hiscore 3D | Creative SB AWE64 Gold, Creative 24MB RAM
Toshiba Libretto 110CT | Pentium MMX @ 266 MHz | 96MB RAM| NeoMagic MagicGraph 128XD | Yamaha OPL3SA
go32
Kommandozeilenfetischist
Beiträge: 174
Registriert: Sa 24. Okt 2015, 22:51

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

Beitrag 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?
Benutzeravatar
kpanic
EDLIN-Benutzer
Beiträge: 116
Registriert: Mo 27. Sep 2010, 11:07
Wohnort: Süd-Südbaden
Kontaktdaten:

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

Beitrag 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.
Antworten