Bootstrap (FAT)
Bootstrap (FAT)
I have a FAT bootstrap, but it only works under Bochs. The problem isn?t as it were in my last, the mem move, because he doesn?t get to the mem move!? Maybe you have time and could have a look at this code.
[attachment deleted by admin]
[attachment deleted by admin]
Re:Bootstrap (FAT)
hi
change (becuase you are setting ds=0 and not ds=0x07c0)
xor ax,ax
mov ds,ax
to
push cs
pop ds ; ds=cs therefore strings will be accessed properly
or use
mov ax,0x07c0
mov ds,ax ; gives same result as above
also to be on the safe side change
???jmp 0x08:$+5
[BITS 32]
???mov ax,10h
???mov ds,ax
???mov es,ax
to
???jmp 0x08:protected_mode
[BITS 32]
protected_mode:
???mov ax,10h
???mov ds,ax
???mov es,ax
......
.......
try that and see if it works.
change (becuase you are setting ds=0 and not ds=0x07c0)
xor ax,ax
mov ds,ax
to
push cs
pop ds ; ds=cs therefore strings will be accessed properly
or use
mov ax,0x07c0
mov ds,ax ; gives same result as above
also to be on the safe side change
???jmp 0x08:$+5
[BITS 32]
???mov ax,10h
???mov ds,ax
???mov es,ax
to
???jmp 0x08:protected_mode
[BITS 32]
protected_mode:
???mov ax,10h
???mov ds,ax
???mov es,ax
......
.......
try that and see if it works.
Re:Bootstrap (FAT)
What I dont undertsand about implementing FAT...why use proccessor time and more importantly diskspace calculating constants at run time... why not just precalculate them at compile time.....
Re:Bootstrap (FAT)
If you're talking about the BPB constants then it's because if you don't have them there (And correct ) then windows/linux/whatever won't recognise it as a fat12 formatted disk. Being able to just copy files on to the disk whilst still in your normal OS without writing a application to do it is quite worthwhile.Mr_Spam wrote: What I dont undertsand about implementing FAT...why use proccessor time and more importantly diskspace calculating constants at run time... why not just precalculate them at compile time.....
Of course if you're talking about the root directory location etc then yeah I'd agree that the calculation is kinda pointless, but only as long as you know for certain this bootsector will only ever be used on media of a specific size. Remember fat12 doesn't just have to be used on floppies (Although if you're considering using it on a harddisk then reconsider ).
As for processor time any minor saving is going to be swamped by the IO delay for the floppy anyhow (That's not even including using a BIOS interrupt). Timewise you wouldn't even notice the slightest difference in human terms.
For space, maybe, but consider how much functionality you throw away for the sake of 30 or so bytes. If you're that desperate for space in your bootsector then you're trying to do too much anyhow and there will be other places to space optimise by shifting the code out into a second stage or your kernel startup routines.
Re:Bootstrap (FAT)
These are no problems, its working, because my other bootstraps make it the same way and they are working. I changed my bootstrap a little bit to see if he gets into PMode. But he doesn?t get into PMode. There is a failure before the PMode jump.
Re:Bootstrap (FAT)
A few points, not related to the specific problem at hand but relevant to the project as a whole:
- It would be advisable to change
to a short jump. The reason for this is not speed or size, but compatibility: it will work even if the BIOS doesn't initialize the CS to 0000 (see the next list point). Also, at some point in it's history (I don't know just when), MS-DOS began checking the first byte of the boot sector, and refusing to read them if they weren't that particular op-code (no reason given, but it was noted that MS-DOS would no longer read disks formatted under the then-current version DR DOS). AFAIK, it is still true today.Code: Select all
jmp START
- Not all BIOSes actually have the CS set to 0000 when the boot loader is run. It would be advisable to have a second jump - a FAR jump - following immediately after the jump to START:, to ensure that the code segment is where you expect it to be regardless of the machine in question.
- What are you putting into your FAT tables by default? You will want to be sure that the tables are validly initialized when you begin, and that the BPB data points to them correctly. You may want to run a few tests to make sure that existing implementations of FAT12 will read from and write to your disks.
- You may want to consult a Spanish language dictionary for the word 'anos', and perhaps reconsider your naming scheme (unless, of course, you already know what it means and intend it as a joke, in which case, more power to you).
Re:Bootstrap (FAT)
I?ve looked after anos on spanish! It?s not important ;D The problem is somewhere in the fat loading code, because he doesn?t get through!
Re:Bootstrap (FAT)
Ok I?ve taken the same code, but I changed it not that way I changed it the last time. Now Bochs gives me the error "write_virtual_checks(): write beyond limit, r/w", when I jump into PMode.
[attachment deleted by admin]
[attachment deleted by admin]
Re:Bootstrap (FAT)
I see you set the GDTR to be at absolute address 0x1000, size 0x18... but I don't see where you set up the GDT properly. I think you must define a GDT like so at your address 0x1000:
gdt:
; Null descriptor
dw 0 ; limit 15:0
dw 0 ; base 15:0
db 0 ; base 23:16
db 0 ; access byte (descriptor type)
db 0 ; limit 19:16, flags
db 0 ; base 31:24
CODE_SEL equ $-gdt ; 0x08
dw 0xFFFF ; Limit/Length
dw 0 ; Base 15:0
db 0 ; Base 23:16
db 0x9E ; P=1, DPL=0, DT=0, ?, Code: conforming, exec/read (1,0,0,1,1110)
db 0xCF ; G=1, D=1, 0, AVL=0, 1111=F: Limit/Length (1,1,0,0,1111)
db 0 ; Base 31:24
DATA_SEL equ $-gdt ; 0x10
dw 0xFFFF ; Limit/Length
dw 0 ; Base 15:0
db 0 ; Base 23:16
db 0x92 ; present, ring 0, data, expand-up, writable
db 0xCF ; page-granular, 32-bit
db 0 ; Base 31:24
gdt:
; Null descriptor
dw 0 ; limit 15:0
dw 0 ; base 15:0
db 0 ; base 23:16
db 0 ; access byte (descriptor type)
db 0 ; limit 19:16, flags
db 0 ; base 31:24
CODE_SEL equ $-gdt ; 0x08
dw 0xFFFF ; Limit/Length
dw 0 ; Base 15:0
db 0 ; Base 23:16
db 0x9E ; P=1, DPL=0, DT=0, ?, Code: conforming, exec/read (1,0,0,1,1110)
db 0xCF ; G=1, D=1, 0, AVL=0, 1111=F: Limit/Length (1,1,0,0,1111)
db 0 ; Base 31:24
DATA_SEL equ $-gdt ; 0x10
dw 0xFFFF ; Limit/Length
dw 0 ; Base 15:0
db 0 ; Base 23:16
db 0x92 ; present, ring 0, data, expand-up, writable
db 0xCF ; page-granular, 32-bit
db 0 ; Base 31:24
Re:Bootstrap (FAT)
The first 18h bytes of my kernel are the GDT! And I load my kernel at 0100h:0000.
Re:Bootstrap (FAT)
Sorry CS, but FlashBurn had it right in the first place. His code assumes that the CS==0000, and sets the code origin - that is, the initial value for the IP, as well as the value to begin counting label address calculations from - to 7C00. In that case, it would be correct to use DS == CS, which as we already established, is 0000.Code Slasher wrote:change (becuase you are setting ds=0 and not ds=0x07c0)
xor ax,ax
mov ds,ax
to
push cs
pop ds ; ds=cs therefore strings will be accessed properly
or use
mov ax,0x07c0
mov ds,ax ; gives same result as above
Your first solution would solve the problem in either case, though, and is probably a suitable approach overall, assuming that there is a valid stack. I use
Code: Select all
mov ax, cs
mov ds, ax
in my own code, but only after I do a jmp far to ensure that the CS and IP are set as they ought to be.