just read an article on the psdev.org or actually the os wiki thats found there. there was somthing about the a20 with unreal mode. with the wording there dont know if that needs to be enabled or disabled.
it depends what addresses you want to access with unreal mode. The A20 gate drops the A20 line to 0, so you cannot access the content of physical addresses in the second MB (100000-1FFFFF), but the third MB (200000-2FFFFF) doesn't need A20 to be 1, so it can be accessed with A20 off ... and so on.
But generally it is a good idea to enable A20 for unreal mode.
Here (http://www.answers.com/topic/a20-line?cat=technology) is a good explanation of A20. A couple of interesting points are
Quote
This was accomplished by inserting a logic gate on the A20 line between the processor and system bus, which logically got named Gate-A20. Gate-A20 can be enabled or disabled by software to allow or prevent the address bus from receiving a signal from A20. It is set to non-passing for the execution of older programs which rely on the wrap-around. At boot time, the BIOS first enables Gate-A20 when counting and testing all of the system's memory, and disables it before transferring control to the operating system.
So the A20 address line is the only one that can be switched on/off by code. Also notice that the BIOS (supposedly) disables it again - VMWare/Bochs don't seem to...or my actual computer.
Quote
It should be noted that disconnecting A20 would not wrap all memory accesses above 1 MB, just those in the 1 MB-2 MB, 3 MB-4 MB, 5 MB-6 MB, etc. ranges. Real mode software only cared about the area slightly above 1 MB, so Gate-A20 was enough.
That explains what japeth said about the different memory ranges you can access with the A20 off. Look at the bits (0..31) and see where the A20 sits (bit 21)
In your boot code (roll your own eh?) after setting unreal mode just enable the A20.
ok so with the a20 gate off i can only access every other 1mb block with the a20 on i have access to everything
just to clarify
and also i read that with using unreal mode that the code still has to reside under 1meg. is that true.
yeah im in the process of writing an os. im tired of the microsoft bullshit.
Microsoft Windows is not bullshit.
At this time it is the best available operating system in both design and implementation.
I have a saying: until you have done better than a product you have no right to criticize it.
So first make a better OS than Windows and only then criticize it :D
But first you must understand A20 and much more an only then you will understand how complicated and how much work is involved in creating an OS of Windows magnitude...
the only thing i dont like about windows is they want $300 even with the new release of vista. i have nothing against windows besides that. theres what seems to be a couple memory leeks here and there but nothing is perfect.
> I have a saying: until you have done better than a product you have no right to criticize it.
That's something most vendors would surely love :).
But it case you are serious about that (I don't know your kind of humor): this sentence is what *I* would call bulllshit.
> the only thing i dont like about windows is they want $300 even with the new release of vista.
There are some more things which one could mention: desperately bloated, almost no progress compared to the previous version, WGA, DRM, TCPA. In short: you don't get enough value for your money (the difference is transfered to "Billy").
Quote from: ninjarider on June 29, 2007, 08:39:41 PM
ok so with the a20 gate off i can only access every other 1mb block with the a20 on i have access to everything
Yep. One reason DOS in the HMA works is that every DOS interrupt goes to a stub in conventional memory and the first
thing the stub does is enable the A20, then it jumps to the code in the HMA.
Quote from: ninjarider on June 29, 2007, 08:39:41 PM
and also i read that with using unreal mode that the code still has to reside under 1meg. is that true.
Because it's only 16-bit, only IP is used - not EIP - so a segment:offset won't work avove 1 meg.
using masm with the link16
.186
.model small
.{cant remember what i have here}
.stack 200h
//real mode to protected mode
setup the gdt
temp db 66h
execute a lgdt - executing the lgdt gives an error. something about opcode not valid in current processor mode
think my issue is the .186 needs to be a .386p
Or at least .286P
didn't know there was a .286p
is there a list of all the directives (.186 .286, etc)
Greg posted a reference in CHM format here:
http://www.masm32.com/board/index.php?topic=3592.0
dont know if they would like me opening it here at work. gonna see if i can get it home.
ok. using a .386p
theres a struct for Desc and a struct for table reg
temp_gdt_null_desc is a Desc
temp_gdt_scratch is a table_reg
/dont remember the syntax but disabled interrupts
the following code has a 66h proceding it
mov ebx, offset temp_gdt
mov dword ptr [ebx], 0
mov dword ptr [ebx] + 4, 0
mov dword ptr [ebx] + 8, Linear_Proto_hi //0000ffffh
mov dword ptr [ebx] + 12, linear_proto_lo //000cf9200h
mov temp_gdt_scratch.table_linear, ebx
mov temp_gdt_scratch.table_lim, 15
lgdt temp_gdt_scratch ////// on this line shouldn't i be loading the address of temp_gdt_scratch
mov ebx, cr0 // is not lead by a 66h
or ebx, 1
mov cr0, ebx ///////////// for some reason when it executes this line the computer reboots.
/enable interrupts
took a look at the program through debug and noticed that is either wasn't decoding the instructions correctly or it is assembling wrong. i've tried both the 66h and the 67h and niether overide seems to help.
what should the following assemble to in hex
mov ebx, cr0
or ebx, 1
mov cr0, ebx
lgdt GDT_TABLE
i've tried using a already declared gdt
having the first word of the gdt_table being a declared as df // what exactly does this do.
debug will also not run the lgdt instruction to see if it is assembling correctly
im starting to wonder if i just need to write this portion of my code in hex.
AFAIK lgdt FWORD PTR GDT_TABLE will force MASM to encode the instruction correctly.
Also, japheth has an updated version of DEBUG that I think should be able to handle the privileged instructions correctly:
http://www.masm32.com/board/index.php?topic=5934.0
thnx. i've been reading through the forum to find what i can about switching modes and causes of the continues reboots.
Apparently code using CR0 doesn't need a 66h override
0F20C3 MOV EBX,CR0
6683CB01 OR EBX,00000001
0F22C3 MOV CR0,EBX
Quote
having the first word of the gdt_table being a declared as df // what exactly does this do.
The first word is the limit of the descriptor tables minus 1 - if you're using 2 descriptors (NULL and flat) then the first word will be (8+8)-1 = 0fh.
Quote
mov temp_gdt_scratch.table_linear, ebx
mov temp_gdt_scratch.table_lim, 15
From this little snippet it seems that the linear address might be wrong - you need the address made from seg:offset
sub ebx,ebx
mov bx,ds
shl ebx,4
add ebx,offset temp_gdt
mov temp_gdt_scratch.table_linear, ebx
Quote from: sinsi on June 29, 2007, 10:37:33 AM
So the A20 address line is the only one that can be switched on/off by code. Also notice that the BIOS (supposedly) disables it again - VMWare/Bochs don't seem to...or my actual computer.
VMWare (1.0.2) most certainly does after the virtual "BIOS" transfers control to the boot loader, executing the following from the boot sector shows this clearly (stage 1, or stage 2 if you're not using another boot loader):
mov ax, 2402h
int 15h
jc A20M_Failure
cmp al, 0
jne A20_enabled
; A20 is disabled here -- vmware will definitely jump here before A20# is enabled
A20_enabled:
; enabled here
A20M_failure:
; I haven't tried int 15h, ax = 2402 on Bochs, but VMWare doesn't reach this
...
progress. it no longer continueslly reboots. althou it doesn't display we made it either. all i get is a flashing cursor
.model small
.386p
.stack 200h
.code
org 7c00h
temp_gdt:
dd 0
dd 0
dd 0ffffh
dd 879200h
dd 0ffffh
dd 879a00h
dw 0
df 23
dd 07c42h
xor ax
mov ds, ax
mov es, ax
mov ss, ax
cli
db 66h
lgdt temp_gdt_table
mov ebx, cr0
or ebx, 1
mov cr0, ebx
db 0eah
dd cs:offset Forward
Forward:
mov cx, 8
mov ds, cx
mov es, cx
mov cx, 16
mov cs, cx ; tried with and without this line.
..
some code to display 'yea'
uses si and lodsb with int 10h
..
Are you trying protected mode or flat/unreal mode?
dw 0
df 23
dd 07c42h
If that is temp_gdt_table, it is defined wrong -
dw 23 ;limit of temp_gdt - 1
dd 7c42h ;linear address of gdt
;or use the FWORD
df 7c420017h
When you jump to Forward, you should be jumping to selector:offset - in this case 0010:00007cxx
Don't try to load CS with a value - jumping as above will do it.
INT 10 won't work too well in protected mode either.
Main_Start1:
through digging i have found this in another post
; Load Global Descriptor Table to segment registers.
; To be loaded into selector/segment register. Selector format is:
; SSSS SSSS SSSS STRR where:
; S = selector number/descriptor number.
; T = TI bit. 1 = LDT, 0 = LDT.
; RPL = Requested Privilege Level.
; 0000 0000 0001 0000. Selector 2, GDT, RPL = 00. Load selector
; pattern into segment registers.
mov ax, 10h
mov ds, ax
mov es, ax
mov ss, ax
mov gs, ax
mov fs, ax
i this this is part of were my problem is.
question if i setup the gdt with the first valid entry being a data entry and the second entry being a code entry. would i use mov ax, 8h for the data and jmp 10h: offset for the code discriptors
also i thought that if the code was still 16 bit that i would still be able to use the bios functions. maybe i mis understood.
Here's a fine site about switch from real-mode to protected-mode and back, and also about "unreal-mode" (or "flat real-mode"):
http://my.execpc.com/~geezer/johnfine/segments.htm
That's spooky...I looked at that page about 3 hours ago... :eek
The home page is better - http://my.execpc.com/CE/AC/geezer/johnfine/
found a couple mistakes in my code. didn't notic ethe mov cs, cx instructions. those seemed to lock up the computer completely. would leave a blinking cursor on the screen. pressed the pwr but and the computer would boot up. and the pwr light on the front of the case would go off.
havn't fully tested it. but i believe we are successfully in unreal mode. yes :dance:
now for usb drivers
fully test unreal is up and running. now for comming up with a call or an idt to transfer back and forth from 16 to 32.
What do you mean by "transfer back and forth from 16 to 32"?
in unreal mode dont know what the actual address limit is about 1 meg for the code and only 16-bit is allowed. i can use the 66h overide for it to use 32-bit code but that takes away from any efficiency or performance. pretty much i have to come up with an idt simular to how dos has int 21. wither that or i have to come up with drivers for everything to avoid the int 21h.
hope that makes sense. in short im wanting to be able to have active code reside anywere in the 4 gigs.
You 'can' have code anywhere in the available memory space, but you need to set up the relevant sector selector for it and load it into CS (far jump) BUT you need to be in protected mode to access the upper part of the segment register selector. In short, :dazzled: This is the main problem with unreal mode. Data can go anywhere too, either with a selector or adding a prefix to use 32-bit instructions (which is annoying and slow to say the least.)
> BUT you need to be in protected mode to access the upper part of the segment register selector
What do you want to tell us with this sentence? What's the "upper part" of a segment register selector?
In 16-bit mode the segment registers are made to look like they're only 16-bits. The truth is they're still the 48-bit selectors they are in 32-bit mode, but when you do a register load (e.g. "mov cs,10h") in 16-bit, only the bottom 16-bits are loaded (as you'd expect), thus leaving the top 32 bits as they were.. which is most likely not what you want.
It's a bit of a complicated mess to have them working sensibly in 16-bit mode, and even worse to do anything amusing like running code outside of the bottom 16MB, without having setting up and loading a code selector in 32-bit mode first.
Short version: to set the full value (not just the bottom 16-bits) of a segment register you need to do it in 32-bit mode through a valid gdt.
> In 16-bit mode the segment registers are made to lo
I see, you mean the segment register's "descriptor cache"
A "selector" is a 16-bit value whose "upper part" (bits 3-15) addresses an entry in a descriptor table, and bit 2 selects the type of the table (GDT or LDT), so your wording was confusing ... at least for me.
btw., the FASM DOS version runs fast and stable in "32bit" real-mode (as far as the cpu is not from Cyrix), and it has full access to 4 GB both for code and data.