ANOS files

[FlashBurn]

[attachment deleted by admin]

[FlashBurn]

[attachment deleted by admin]

[Pype.Clicker]

Well, i think you should take the time to give us a little more informations about how your filesystem is organized and where is the code that managed it...

How are sectors organized on your disk ? where is the "read file xyz" code located, etc...

[FlashBurn]

It?s not realy a real filesys . Filesys.asm is the sectormap and in boottest.asm and ansoldr.asm is code read the "filesystem" .

[crazybuddha]

Are you planning to implement protected-mode at some point?? If you do, you will find that much of this will not be accessible (without some workarounds). You will end up re-writing any shell routines, and while the kernel is empty now, you might do well not to add any more real mode code, if you are going to go pmode.

The code is pretty clean and mostly self-documenting. You might want to include some comments to clarify what different sections are doing or if there is anything tricky going on which you don't want to have to figure out again if you come back to this code a year later.
It doesn't matter if they are "auf Deutsch".

[FlashBurn]

Yes , I would like to have PMode , but I don?t understand the tutorials . I know that I have to rewrite some code wehn I have PMode . Maybe you can me show how I can get in PMode ??

[crazybuddha]

To get into pmode, change the last bit in the control register cr0 without messing up any other bits:

mov eax, cr0
inc ax
mov cr0, eax

That's it. You are now in protected mode.

The trouble is that now the segment registers (CS, DS, etc) no longer are segments (as in segment:offset addressing used in real mode, where the segment value is shifted left by 4 then the offset is added to it).

The value in the segment registers (usually called a selector) contains various information. The bottom three bits will confuse you, so just make sure for now they are 0's. The remaining 13 bits (remember that a segment register is 16 bits) are an index into a table (which you create) of "descriptors". A descriptor is a record of various information needed by the CPU to access memory in pmode.

I gave a detailed look at descriptors here:
http://www.mega-tokyo.com/forum/index.p ... readid=741


Here is what the descriptor table might look like:

gdtinfo:
   dw gdt_end - gdt - 1   ;last byte in table
   dd gdt         ;start of table

gdt dd 0,0    ; first descriptor is null
rm_data   db 0xff, 0xff, 0, 0, 0, 10010010b, 11001111b, 0
pm_code   db 0xff, 0xff, 0, 0, 0, 10011010b, 11001111b, 0
pm_data   db 0xff, 0xff, 0, 0, 0, 10010010b, 11001111b, 0
gdt_end:

This is formatted to match my review of the descriptors, so it should be easy to follow.

In order for the CPU to know about the table, you have to use a special instruction to tell it the location in memory and how big it is.

lgdt [gdtinfo]   ; load gdt register


Finally, you have to jump to the protected mode code. This is done by specifying the code descriptor (using the selector) and the offset in memory where the new code is located.

jmp 0x10:0x0600   ; go to setup code


This matches the table given above since 0x10 = 10000b. Now strip off the bottom three bits and you get 10b, which is 2d. Look at the table and you will see that pm_code is entry #2.

0x0600 just happens to be where I put the 32-bit protected mode code.

You can see all this in action at my web page (such as it is).