Discussion:
FAT32 Formatieren unter DR DOS 7.x
(zu alt für eine Antwort)
Benjamin Nehls
2010-04-04 14:50:24 UTC
Permalink
Moin Moin,

Ich bin derzeit auf der Suche nach einer Format.com die auch FAT32 kann
und unter reinem 16-Bit DOS rennt.

Ich hab mit xFdisk ne 5 GB Partition angelegt und möchte die nun
Formatieren.

Kann mir hier einer was empfehlen? oder gibts diese Möglichkeit
garnicht, denn gefunden habe ich für reines 16-bit DOS leider noch nichts.

Mfg. B. Nehls
Dirk Wolfgang Glomp
2010-04-04 15:12:14 UTC
Permalink
Post by Benjamin Nehls
Moin Moin,
Ich bin derzeit auf der Suche nach einer Format.com die auch FAT32 kann
und unter reinem 16-Bit DOS rennt.
Ich hab mit xFdisk ne 5 GB Partition angelegt und möchte die nun
Formatieren.
Kann mir hier einer was empfehlen? oder gibts diese Möglichkeit
garnicht, denn gefunden habe ich für reines 16-bit DOS leider noch nichts.
Mfg. B. Nehls
In Windows98(DOS7) ist so ein Format.com enthalten.
(Mit "DR DOS" kenne ich mich allerdings nicht aus.)

Dirk
Benjamin Nehls
2010-04-05 09:54:15 UTC
Permalink
Post by Dirk Wolfgang Glomp
In Windows98(DOS7) ist so ein Format.com enthalten.
(Mit "DR DOS" kenne ich mich allerdings nicht aus.)
Dirk
Hi Dirk, thx jedoch funktioniert diese Format.com nicht unter DR-DOS

Auch das Spielen mit setver hatte leider in dem falle kein Erfolg gebracht.

Format.com hatte beim Einsatz von setver zwar nicht mehr gemeldet das es
eine MS-DOS 7.x Version benötigt, jedoch macht das Programm keine
Formatierung.

Es gibt zwar alle Meldungen aus als wenn es die Formatierung durchführen
würde, jedoch ist hinterher aber nichts passiert.

Mfg. B. Nehls
Dirk Wolfgang Glomp
2010-04-05 10:23:43 UTC
Permalink
Post by Benjamin Nehls
Post by Dirk Wolfgang Glomp
In Windows98(DOS7) ist so ein Format.com enthalten.
(Mit "DR DOS" kenne ich mich allerdings nicht aus.)
Dirk
Hi Dirk, thx jedoch funktioniert diese Format.com nicht unter DR-DOS
Auch das Spielen mit setver hatte leider in dem falle kein Erfolg gebracht.
Format.com hatte beim Einsatz von setver zwar nicht mehr gemeldet das es
eine MS-DOS 7.x Version benötigt, jedoch macht das Programm keine
Formatierung.
Es gibt zwar alle Meldungen aus als wenn es die Formatierung durchführen
würde, jedoch ist hinterher aber nichts passiert.
Mfg. B. Nehls
Warum verwendest du "DR DOS" und nicht ein anders DOS?

Dirk
Benjamin Nehls
2010-04-05 11:35:00 UTC
Permalink
Post by Dirk Wolfgang Glomp
Warum verwendest du "DR DOS" und nicht ein anders DOS?
Dirk
Weil ich den Enhanced DR-DOS 7.01.08 WIP (23.7.2009) Kernel benutze,
dieser Ermöglicht mir von haus aus z.b. schonmal FAT32 Lesen/Schreiben
welches z.B. bei MS-DOS 6.x ja von haus aus nicht geht.

Auch macht der Panasonic v2.06 ASPI Treiber unter DR. DOS weniger
Probleme als unter MS-DOS

Desweiteren erreiche ich mehr freien Speicher im Unteren Speicher als
unter als unter MS-DOS.

Bliebe noch FreeDOS, naja ich halte von diesem DOS nichts zu einem sind
die noch weit entfernt von 100% DOS Kompatibilität zum anderen rennt
auch Windows 3.x nur im Standard-mode unter FreeDOS

Jedes DOS hat halt seine vor und auch seine nachteile, für mich
persönlich komm ich am besten mit den Vorteilen von DR DOS klar.

Mfg. B. Nehls
Dirk Wolfgang Glomp
2010-04-06 05:44:59 UTC
Permalink
Post by Benjamin Nehls
Post by Dirk Wolfgang Glomp
Warum verwendest du "DR DOS" und nicht ein anders DOS?
Dirk
Weil ich den Enhanced DR-DOS 7.01.08 WIP (23.7.2009) Kernel benutze,
dieser Ermöglicht mir von haus aus z.b. schonmal FAT32 Lesen/Schreiben
welches z.B. bei MS-DOS 6.x ja von haus aus nicht geht.
Aber MSDOS 7(von W98) und ich denke auch FREEDOS kennt FAT32.
Post by Benjamin Nehls
Auch macht der Panasonic v2.06 ASPI Treiber unter DR. DOS weniger
Probleme als unter MS-DOS
Aha.
Post by Benjamin Nehls
Desweiteren erreiche ich mehr freien Speicher im Unteren Speicher als
unter als unter MS-DOS.
Oh, gut zu wissen.
Post by Benjamin Nehls
Bliebe noch FreeDOS, naja ich halte von diesem DOS nichts zu einem sind
die noch weit entfernt von 100% DOS Kompatibilität zum anderen rennt
auch Windows 3.x nur im Standard-mode unter FreeDOS
Uff, das hätte ich jetzt nicht vermutet. Aber kommt Windows 3.1
(für Workgroups) denn mit FAT32 zurecht?
Post by Benjamin Nehls
Jedes DOS hat halt seine vor und auch seine nachteile, für mich
persönlich komm ich am besten mit den Vorteilen von DR DOS klar.
Ich verwende DOS meistens ohne Emm386 oder ähnlichen Menmmorymanager.
Mir ist es zu umständlich Speicher von emm368 anzufordern und daher
verwalte ich den Speicher bis 4GB lieber selber im Unrealmode.

Dirk
Benjamin Nehls
2010-04-06 18:21:31 UTC
Permalink
Naja, ich nutze halt DR DOS ich versteh auch nicht wieso du mich zu
einer anderen DOS-Version bekeehren möchtest.
Post by Dirk Wolfgang Glomp
Ich verwende DOS meistens ohne Emm386 oder ähnlichen Menmmorymanager.
Mir ist es zu umständlich Speicher von emm368 anzufordern und daher
verwalte ich den Speicher bis 4GB lieber selber im Unrealmode.
Hm, ok interessant und wie sieht deine Konfig dahingehend nun aus um das
so zu ermöglichen? bin gerne für neues offen.

Mfg. B. Nehls
Markus Humm
2010-04-06 20:14:55 UTC
Permalink
Hallo,

wer sagt denn dass du noich Win98 (aka DOS 7.1) von Diskette booten
kast, damit formatieren kannst und dann DR DOS mit der Partition benutzen?

Gruß

Markus
Benjamin Nehls
2010-04-06 20:19:51 UTC
Permalink
Post by Markus Humm
Hallo,
wer sagt denn dass du noich Win98 (aka DOS 7.1) von Diskette booten
kast, damit formatieren kannst und dann DR DOS mit der Partition benutzen?
Gruß
Markus
Hi,

Das ist auch meine bisherige methode, aber da ich im moment noch viel
versuche und die Partitionen noch ab und zu umändere wäre es schöner
wenn das auch aus DR DOS selbst raus geht. Aber ich denke ich muss
warten bis das hauseigene tool ohne Probleme funktioniert oder weiter
wie bisher machen... dachte halt nur hier weiss eventuell jemand was
besseres :)

Mfg. B. Nehls
Dirk Wolfgang Glomp
2010-04-06 21:28:44 UTC
Permalink
Post by Benjamin Nehls
Naja, ich nutze halt DR DOS ich versteh auch nicht wieso du mich zu
einer anderen DOS-Version bekeehren möchtest.
Post by Dirk Wolfgang Glomp
Ich verwende DOS meistens ohne Emm386 oder ähnlichen Menmmorymanager.
Mir ist es zu umständlich Speicher von emm368 anzufordern und daher
verwalte ich den Speicher bis 4GB lieber selber im Unrealmode.
Hm, ok interessant und wie sieht deine Konfig dahingehend nun aus um das
so zu ermöglichen? bin gerne für neues offen.
Ich versuche es mal kurz zusammenzufassen. Wenn du es noch detailierter
wissen möchtest sag bescheid.

Platz für Himem.sys, CDRom-Treiber und eine XMS-Ramdisk(64 MB) lasse ich
frei und benutze den Speicher ab dem 65 MB bis ~(bei mir 2,8 GB der Rest
ist belegt). Für den 16-Bit-Unrealmode schalte ich in den PM, erweitere die
Segmentlänge in der GDT und lade dann das DS-Segmentregister mit dem
entsprechenden Selektor(18h). Anschliesend wird in den RM, genauer gesagt
in den Unrealmaode zurückgeschaltet. Nun kann über das DS-Segmentregister
in Kombination mit einem 32Bit-Adressregister auf jede lineare Adresse im
4GB-Adressraum mit einem einzelnen Byte, Word, DWORD, MMX(64Bit), oder
SSE-Register(128Bit) schreibend und lesend zugegriffen werden.
Mit dem linearer Speicherzugriff kann man z.B. Bilddaten in den
Framebuffer(im 4.GB) schreiben und damit Videomodi je nach VBE-BIOS bis zu
1920x1200x32 benutzen. Der unbelegter Speicher ab dem 65 MB (der auch
physikalisch vorhanden ist) kann für beliebige eigene Daten benutzt werden.

Auf danach verwendete DOS- und BIOS-Aufrufe hat es keine Auswirkung und
Probleme konnte ich in DOS hinterher auch noch nicht damit feststellen.
Wird danach aber erneut von einer beliebigen anderen Anwendung in den PM
geschaltet, wird die nun neue GDT und die dort eingetragene Segmentlänge
eingestellt und wahrscheinlich damit der Unrealmode quasi wieder
ausgeschaltet. Emm386.exe und andere Memmorymanager verhindern jedaoch das
Anwendungen selber in den PM schalten. Wenn diese Memmorymanger für EMS
jedoch nicht verwendet werden (ggf. in der config.sys unter Rem setzen)
kann jede Anwendung selber in den PM schalten falls sie mehr Speicher
benötigt als von Himem.sys verwaltet wird.

Dirk
Benjamin Nehls
2010-04-07 05:38:55 UTC
Permalink
Post by Dirk Wolfgang Glomp
Ich versuche es mal kurz zusammenzufassen. Wenn du es noch detailierter
wissen möchtest sag bescheid.
Auf jedenfall, klingt interessant und ich würde so eine Konfiguration
gern mal am real PC austesten.

Ich hab hier noch nen AMD-K6 450 MHz und 256 MB Ram rumstehen der sich
zum Testen eignen würde.

Welche Treiber / Programme sind dafür denn nötig um alles hinter dem 65
MB Speicher zu setzen.

Wenn ich das richtig verstenden habe ist das dann quasie alles nur noch
im Protect Mode und alles spielt sich hinterher dann in dem emulierten
Realmode vom PM ab? ist das richtig bzw. war das doch so, das man vom RM
zwar in den PM schalten kann aber nicht umgekehrt?

Naja wie gesagt ich würde gerne mehr wissen vorallem würde ich mich über
eine kleine Anleitung freuen um das mal an meinem Test-Pc zu testen. :)

Vorallem wie sieht das denn mit 16-Bit Treibern z.B. für die
Netzwerkkarte oder die Soundkarte aus die Funktionieren dann auch noch
einwandfrei?

Mfg. B. Nehls
Dirk Wolfgang Glomp
2010-04-07 13:06:20 UTC
Permalink
Post by Benjamin Nehls
Post by Dirk Wolfgang Glomp
Ich versuche es mal kurz zusammenzufassen. Wenn du es noch detailierter
wissen möchtest sag bescheid.
Auf jedenfall, klingt interessant und ich würde so eine Konfiguration
gern mal am real PC austesten.
Ich hab hier noch nen AMD-K6 450 MHz und 256 MB Ram rumstehen der sich
zum Testen eignen würde.
Welche Treiber / Programme sind dafür denn nötig um alles hinter dem 65
MB Speicher zu setzen.
Es werden dabei nur jene Daten nach oben befördert die eine Anwendung
auch selber dort nach oben hineinschreibt. Ich benutze dafür keinerlei
Treiber, sondern schreibe/lese unmittelbar selber in den dortigen
Speicherbereich.
Post by Benjamin Nehls
Wenn ich das richtig verstenden habe ist das dann quasie alles nur noch
im Protect Mode und alles spielt sich hinterher dann in dem emulierten
Realmode vom PM ab?
Nein, der Unrealmode unterscheidet sich nicht so grundlegend vom RM.
Ich schalte wieder zurück in den nun erweiterten RM der als Un-Realmode,
oder als Big-Realmode bezeichnet wird. Es wird nichts emuliert und auch
kein PM ist dabei mehr aktiv. Lediglich die Segmentlänge der erweiterten
Segmente bleibt dabei auch nach dem zurückschalten in den RM immer noch
erhalten, solange nicht wieder in den PM geschaltet wird.
Post by Benjamin Nehls
ist das richtig bzw. war das doch so, das man vom RM
zwar in den PM schalten kann aber nicht umgekehrt?
Auch für 80286(16Bit) gibt es einen Trick wieder zurück in den RM zu
schalten und ab den 80386er(32Bit) wurde es regulär implementiert.
Post by Benjamin Nehls
Naja wie gesagt ich würde gerne mehr wissen vorallem würde ich mich über
eine kleine Anleitung freuen um das mal an meinem Test-Pc zu testen. :)
Vorallem wie sieht das denn mit 16-Bit Treibern z.B. für die
Netzwerkkarte oder die Soundkarte aus die Funktionieren dann auch noch
einwandfrei?
16-Bit Treiber für den RM verwenden selber nur den unteren Bereich und
benutzen dafür die dort übliche Verwendung der 64KB großen Segmente. Damit
kann ein Adressbereich von 1MB+64KB-1Byte adressiert werden.

....

[--Detailiertere Anleitung für den Unrealmode--]
Um in den Unrealmode zu schalten müssen wir in den PM schalten,
die Segmentlänge erweitern und zurück in den RM schalten.

Für den PM selber brauchen wir keine Interrupts(IRQs) und auch keine
dafür geeingnete IRQ-Tabelle, da wir ja auch nicht im PM bleiben wollen.
Daher sperren wir die IRQs für diesen gesamten Vorgang. Dafür löschen wir
das dafür zuständige Interrupt-Bit im Flagregister und verhindern so das
Interrupts aufgeführt werden. Wir benutzen dafür den cli-Befehl der genau
dieses für uns erledigt.

Der Non-Maskable-Interrupt(NMI) ist davon allerding nicht betroffen und so
müssen wir dieses im dafür zuständigen CMOS-Baustein selber vornehmen.
Über die Portadresse 70h und das dortige oberste Bit kann man den NMI
aus/an schalten. Zum Auschalten des NMIs muss dieses Bit gesetzt sein.
Wir holen uns über den Port 70h das Byte und setzen das oberste Bit und
übertragen danach das veränderte Byte wieder zurück.

Nun können wir in den PM schalten die Segmente erweitern. Danach können wir
den NMI und die IRQs wieder anschalten.

Im folgenden Verlauf benutze ich Assembler-Befehle im MASM-Syntax
(Makro-Assembler von Microsoft) die sich vom AT-Syntax unterscheiden.

Ich habe die nötigen Teile um in den Unrealmode zu schalten in ein
Roh-Gerüst zum assemblieren hineingelegt, so das daraus eine fertige
Anwendung erstellt werden kann, die allerding in diesem Beispiel nicht
anderes macht, als ein 32Bit-Wert aus unseren im Programm deklarierten
Datenbereich zu laden und ihn in das 65.MB zu schreiben. Für eine
sinnvollere Verwendung muss daher noch entsprechender Opcode hinzugefügt
werden.

.MODEL SMALL
.386P
CODE SEGMENT use16 'CODE'
assume cs:CODE,ds:DATEN,ss:STAPEL
;-----------------------------
; -- Start des Programms --
START:
; -- Beispiel Opcodes die vorher ausgeführt werden ---
mov ax,DATEN ; DS auf Daten-Bereich
mov ds,ax
;-- weitere Opcodes ---

;------------------------------------------------------------------------
;-- Ab hier nun die wesentliche Teile für den Unrealmode --
cli ; IRQs sperren
in al,70h ; NMI sperren
or al,80h
out 70,al

call UNREAL ; Sprung zur Subroutine die in den Unrealmode schaltet
; und danach zurückspringt

in al,70h ; NMI wieder einschalten
and al,7Fh
out 70,al
sti ; IRQs wieder einschalten
;------------------------------------------------------------------------

; Lineare Zugriffe auf den gesamten 4GB-Adressraum
; Hier ein Beispiel:

mov ebx, 00100000h * 64 ; Adresse vom 65.MB
xor eax,eax
mov ax,DATEN
mov ds,ax ; DS auf Datenbereich
shl eax,4
sub ebx,eax
mov eax,[WERT] ; 32Bit-Wert aus Datenbereich über DS:16Bit-Adresse holen

mov [ebx],eax ; ...und an den Anfang vom 65.MB über DS:EBX schreiben

; Hierfür wird nun die Segmentadresse(in DS) + die 32Bit-Offsetadresse
; aus dem Adressregister(in EBX) zum adressieren verwendet.

;--------------------------------------------------------------
;--- Programm-Ende und Rücksprung nach DOS ---
mov al,ERRORLEVEL ; muss durch einen Wert(0-255) ersetzt werden
mov ah,4Ch
int 21h
;---------------------------------------------------------------
; --- Subroutinen ---
;-----------------------------
; -- GDT für den Protected Mode (im Code-Breich) --
org START + ((($-START)/32)*32)+32 ; Aligment
;-----------------------------
GDTZEIGER DW ? ; Länge der GDT
DW ? ; Adresse low -Word:SEGMENTE
DW ? ; Adresse high-Word:SEGMENTE
DW 0 ; reserviert

SEGMENTE DW 0 ; Bits: 0-15 Seg.länge(Bit0-15)
DW 0 ; Bits: 0-15 Basis-Adresse Deskriptor-Table
DB 0 ; Bits:16-23 Basis-Adresse Deskriptor-Table
DB 0 ; Bits: 0- 7 Zugriffsrechte
DB 0 ; Bits: 0- 3 Seg.länge(Bit16-19)/Bit7:1=4KByte/0=1Byte
DB 0 ; Bits:24-31 Basis-Adresse Deskriptor-Table
;--------------------------------------------
DW 0FFFFh ; Segmentlänge Bits: 0-15
DW 0 ; Adresse low Bits: 0-15
DB 0 ; Adresse high Bits:16-23
DB 9Ah ; Zugriffsrechte
DB 0 ; Seg.Länge Bits:16-19 im Bit0-3 /Bit7:1=4KByte/0=1Byte
DB 0 ; Seg.Adresse Bits:24-31
;---------------------------------------------------
DW 0FFFFh ; Segmentlänge Bits: 0-15
DW 0 ; Adresse low Bits: 0-15
DB 0 ; Adresse high Bits:16-23
DB 92h ; Zugriffsrechte
DB 0 ; Seg.Länge Bits:16-19 im Bit0-3 /Bit7:1=4KByte/0=1Byte
DB 0 ; Seg.Adresse Bits:24-31
;---------------------------------------------------(Selektor 18h)
DW 0FFFFh ; Segmentlänge Bits: 0-15
DW 0 ; Seg.Adresse Bits: 0-15
DB 0 ; Seg.Adresse Bits:16-23
DB 92h ; Zugriffsrechte
DB 0FFh ; Seg.Länge Bits:16-19 im Bit0-3//Bit7:1=4KByte/0=1Byte
DB 0FFh ; Seg.Adresse Bits:24-31
;---------------------------------------------------
SEGMENTE_END label WORD
Gdt_Groesse equ (OFFSET SEGMENTE_END - SEGMENTE -1)
;---------------------------------------------------
org START + ((($-START)/32)*32)+32 ; Code-Aligment
;---------------------------------------------------
UNREAL:
xor eax,eax
mov ax,cs
mov ds,ax
shl eax,4 ; EAX ist nun physikalische
mov ebx,eax ; Segmentstartadresse
mov WORD PTR[SEGMENTE+0Ah],ax ; in den Deskriptoren
mov WORD PTR[SEGMENTE+12h],ax ; für CS
ror eax, 10h ; und SS in der
mov BYTE PTR[SEGMENTE+0Ch],al ; GDT abspeichern
mov BYTE PTR[SEGMENTE+14h],al
xor eax,eax ; EAX auf null
mov ax,OFFSET SEGMENTE ; 16-Bit-Offset
add ebx,eax ; GDT-Adresse im
mov WORD PTR[GDTZEIGER],Gdt_Groesse ; GDT-Deskriptor
mov DWORD PTR[GDTZEIGER+2],ebx

pushf ; Flags retten
lgdt FWORD PTR[GDTZEIGER] ; GDT laden
mov dx,ss ; SS retten
mov eax,cr0 ; Steuerwort 0 nach EAX
or al,1 ; Protected Mode ein
mov cr0,eax ; im Steuerwort
; Prefetch-Puffer löschen
DB 0EAh ; die folgenden Zeilen
DW (OFFSET PMODE) ; erzeugen:
DW 8 ; JMP FAR CS:PMODE
;-----------------------------------
org START + ((($-START)/32)*32)+32 ; Code-Aligment
;-----------------------------------
PMODE:
mov ax,10h ; SS-Selektor auf 64
mov ss,ax ; KByte begrenzen
mov ax,18h
mov ds,ax ; DS-Selektor mit erweiterter Segmentlänge laden

mov eax,cr0 ; Steuerwort 0 nach EAX
and eax,not 1 ; Protected Mode aus
mov cr0,eax ; im Steuerwort
; Prefetch-Puffer löschen
DB 0EAh ; Die folgenden Zeilen er-
DW (OFFSET RMODE) ; zeugen das Kommando
AKTSEG DW (SEG RMODE) ; JMP FAR CS:RMODE
;-----------------------------------
org START + ((($-START)/32)*32)+32 ; Code-Aligment
;-----------------------------------
RMODE:
mov ss,dx ; SS zurueck
popf ; Flags holen
;------------------------------
; Das 21.Adreßbit einschalten
;------------------------------
BIT_FREI:
call W_8042 ; Warte auf 8042
jnz BACK
mov al,0D1h ; Kommando schreiben
out 64h,al
call W_8042 ; fertig zum Emnpfang?
jnz BACK
mov al,0DFh ; ja, Leitung 20 freischalten
out 60h,al
;-----------------------------------
; Wartet bis der 8042 bereit ist.
;-----------------------------------
W_8042:
xor cx,cx ; CX=0
STATUS:
in al,64h ; Status lesen
and al,2 ; Puffer voll?
loopnz STATUS ; bis nein oder Timeout
BACK:
ret
;------------------- unser Datenbereich -------------------------------
DATEN SEGMENT use32 'DATA'
WERT DD 12345678h
DATEN ends
;------ unser Stack ---------------------------------------------------
STAPEL SEGMENT use16 STACK 'STACK'
DB 100h dup (0)
STAPEL ends
;-----
end

Zum Assemblieren dieses Quellcodes kann man MASM5 unter DOS, oder auch
MASM6 für Windows verwenden um daraus eine *.obj-Datei zu erhalten.
Damit wir aber eine 16Bit-Anwendung bekommen müssen wir einen
16Bit-Linker dafür verwenden, der bei MASM5 mitgeliefert wurde.
So eine Unrealmode-Anwendung kann allerdings nur unter puren DOS
ausgeführt werden. Auch darf vorher kein Memmorymanager wie emm386
vorher gestartet worden sein.

MASM5:
MASM /Z 4GB.asm,4GB.obj,4GB.lst,4GB.crf
LINK /CP:1 4GB.obj,4GB.exe,4GB.map,,

MASM6(mit link.exe von MASM5):
ML /c /Zm 4GB.asm
LINK /CP:1 4GB.obj,4GB.exe,,,

MASM6 beherrscht schon MMX, SSE und 3DNow-Befehle die MASM5 noch nicht
kennt. Wer also unter puren DOS mit MASM5 arbeitet wird solche Befehle
daher von Hand kodieren und als Bytes selber in den Opcode einfügen müssen.
Beispiel: DB 0Fh,6Fh,4 ; movq mm0,[si]

Dirk

Lesen Sie weiter auf narkive:
Loading...