China DOS Union

Important discovery, in pure DOS, without operating CR0, without loading descriptors, directly addressing 4G, welcome to verify

romdizhi equ 0fffffff0h
mov esi,romdizhi
huancun equ 80000h
qushu:
xor ax,ax
mov ds,ax
mov es,ax
mov edi,huancun
mov ecx,10h/4
db 67h ; this sentence is very critical
rep movsd
mov ax,huancun/10h
mov ds,ax
mov es,ax

[ Last edited by cxdzxc on 2010-6-14 at 10:09 ]

http://topic.csdn.net/u/20100613/14/513861a8-fce6-476e-ab6e-d279ba5dd47f.html?56205


hpsmouse

() mouse ()

Grade:

#15 Post: Score: 0 Posted: 2010-06-14 09:50:54 Verification successful, but this 0x67 seems only useful for movs, not for general mov.

cnzdgs
(Full Star\nTechnical questions, please do not private message)
Level:
2
More badges
#40樓 Score: 0 Posted on: 2010-06-15 01:54:48
Adding the prefix 67H to a 16-bit code means using 32-bit addressing. In real mode, 32-bit addressing can also be used, but it requires that the relevant segment registers have been loaded with appropriate descriptors, and it seems that the current value of the segment register must be 0 (this has not been verified).
In Windows' virtual DOS environment, 32-bit addressing is not allowed; in a virtual machine, it depends on the specific implementation of "virtualization", and it is unknown whether it can run. In some physical machine pure DOS environments, it can run because the BIOS program entered protected mode during startup, and loaded 32-bit segment descriptors into ds and es, and did not clear them when switching back to real mode, so 32-bit addressing can still be used in real mode. You can do a simple verification: write a short program yourself, enter protected mode, load ds and es with empty descriptors, then switch back to real mode, and then running this program will have problems.

Level:
#42nd floor Score: 0 Posted on: 2010-06-15 09:30:51
After experimentation, what Teacher Wang and DelphiGuy said is correct. It should be my BIOS---I loaded 32-bit segment descriptors in ds and es, but did not clear them when switching back to real mode, so they can still be used in real mode

The experimental code is posted below:
org 100h
cli

xor eax,eax
mov ax,cs
shl eax,4
add [gdtzhizhen+2],eax
lgdt [gdtzhizhen]
mov eax,cr0
or al,1
mov cr0,eax
mov bx,gdt1-gdt0
mov ds,bx
mov es,bx
and al,0feh
mov cr0,eax

mov ah,4ch
int 21h

gdt0 dd 0,0
gdt1 db 0ffh,0ffh,0,0,0,92h,0fh,0
gdtzhizhen dw $-gdt0,gdt0,0

----------------------------
Compile it into a COM file with NASM, run this file under DOS first, then load the previous experimental code with DEBUG, and run it with the G command will crash

To access 4G under DOS, you need to enable A20 first; otherwise, there will be issues when accessing even addresses.

Originally posted by netwinxp at 2010-6-17 08:50 PM:
To access 4G under DOS, you need to enable A20 first, otherwise, issues will occur when accessing even addresses.

Right, you need to enable the A20 address line

Originally posted by AlexZhang at 2010-6-17 10:22 PM:

Exactly, need to enable the A20 address line

According to Brother Jack Ellis, the A20 control was originally quite 'non-standard'...

1) Port 92h logic
2) keyboard-port logic

Also need to lock and unlock from time to time, troublesome!

KBC is a standard after 286. The 92 port is not standard (it is a standard for the MAC bus, many machines cannot use it, and you need to turn on A20 Fast in BIOS SETUP (if this option exists) to support it). The KBC method is universal for x86, but switching is slow, and sometimes it conflicts with USB keyboards and mice (when writing to the KBC A20 bit, you need to first prohibit writing to the KBC data buffer, and then remove the prohibition after writing, otherwise the USB keyboard and mouse may incorrectly write to the KBC command buffer and cause the USB keyboard and mouse to fail).

The first time I saw the use of FS and GS to access 4G under DOS was the article "Directly Accessing 4GB Memory in Real Mode of DOS" written by Liang Zhaoxin (that super stuttering developer) in 199x. Now the "experts" are so plagiaristic, all of them have become "original".

The biggest problem in accessing 4G in real mode is - there is no management for memory above FFFF:FFFF, so it is still safe to use INT 15, XMS, EMS, DPMI.

[ Last edited by netwinxp on 2010-6-20 at 14:14 ]

[ Last edited by gssxd on 2010-6-21 at 22:42 ]

Originally posted by netwinxp at 2010-6-20 13:59:
KBC is the standard after 286. The 92-pin port is non-standard (it is the standard of the MAC bus. Many machines cannot use it. You need to turn on A20 Fast in BIOS SETUP (if this option is available) to support it). The KBC method is universal for x86, but cutting ...

Regarding A20 Disable and Enable, it still depends on the implementation in the BIOS. Under DOS, it is all by calling INT15, the interface provided by the BIOS, which belongs to Runtime. The BIOS will disable A20 before booting the OS.

In the CMOS, A20 Fast Enable/Disable refers to whether to provide the 92H port to quickly switch the state of A20. If it is disabled, the 92H port is not provided, and only the slow KBC can be used to switch. It is not the same as A20 Enable/Disable. In fact, INT 15H also operates through the KBC or 92H port. As for the so-called FireWare Runtime, it is just packaging bus operations, I/O operations, and required data in the ASL (format required by Microsoft) to facilitate Windows ACPI to operate hardware. Essentially, it is similar to the previous APM. The difference is that APM is called through INT 15H and needs to switch to real mode (such as shutting down in win98). Windows can operate hardware in protected mode through ACPI according to the ASL definition. ASL is a standard and tool provided by Microsoft. To put it simply, it forms a de facto monopoly. Just look at how many detours Linux has taken in implementing ACPI to understand it! In fact, if the script inside is not "deliberately compiled", it is not difficult for other operating systems to implement it.

[ Last edited by netwinxp on 2010-6-22 at 18:52 ]