Bootloader made to kill

[df]

but if you virtually map memory it... wheres the clash?
to me, i thought all you do is keep a copy of the int table, map some pages as 0-1mb etc. copy in the int table, map in the bios rom space... ?

[Tim]

Of course (I overlooked that)

The only thing you've got to be careful of is not overwriting the bottom 4KB, or the EBDA (just under 640KB, if present). You can identity map the bottom 4KB, then use virtual memory for the rest.

[Tux]

Day 3, and still no luck. ??? I have been fiddling with some of the code, but still no luck, It may be the 17*512 to 18*512 switch in the loader. Or it may be the heads. I am still looking... ;D

[mr. xsism]

ok first of all, you guys are just wasting space with this "can Rmode support over 1MB? :'( " YES!! it can! you see, Rmode can address up to 0xFFFF:0xFFFF which is about 64KB over 0x100000(1MB).
-
-
-
Also, this is my bootloader that tux is using. He's used it and helped debug it, my kernel laods into 1MB fine. My kernel is about 22KB ATM and i plan to have the core be less than ^$KB, which is not hard to code; so don't act surprised about it's smallness
-
-
-
You guys aren't really thinking about his question. He asked if there was anything wrong with the BIOS int 0x13 floppy loading code. Like he said, it works up to a certain point, why? Can you guys look at the code again so we can figure it out??
-
-
-
Thnaks for reading this.

Regards,
Mr. xsism
irc. wyldryde.net @ #osdev

[Tim]

OK. If I debug your code, could you debug my code for me?

[Tux]

Ok, here is how you debug. You take a repetitive kernel. For example:

int main()
{
printf("Stage 1");
//insert an 8 kb variable here
printf("Stage 2");
//insert an 8 kb variable here
//...And so on till you find which part is messing up.
//But I still don't know what is wrong with xsism's
}

[_mark]

Don't some floppy drives have 4 heads?

_mark()

[_mark]

I looked around - I'm probably wrong about 4 heads - I have no clue where I read that.
Anyway...
I checked the math above in the code. All the track,head values look good. The memory destination values look OK also. The only thing I can think of is to check for an error after every read. If your getting a read error it would be missed by the code presented above.

There might be a status you can get from the floppy drive also to determin if it is in a funky state before you issue the read interrupt. Anyone know what that might be???

_mark()

[distantvoices]

I just can give an example of my bootloader experience:

first, int 13 has limited capabilities. When I have arrived at the point where my kernel exceeded the 36 kb mark, i could not load it anymore with the int 13h command in one tight loop. I would have built in some file system support if this hadn't been such a messy thing and if i had more time and nerves for that.

to get this running smooth, you should first read in the root directory, search the entry of your kernel image and read the fat entry for that. then you load each of the sectors indicated in that cluster into memory.512 bytes after 512 bytes. given that you have a fat12 disk.

Till that, I used to pass the values dd told me after write of the file to disk to int 13. It went ok till 36 sectors, then it crapped out. this was time for me to switch to grub.

concerning the code: It looks ok. mmurtl bootloader uses a method that reminds me of this. But are you sure the kernel image is on disk where you expect it? How do you write it to disk? How do you jump t the kernel? questions over questions... hmmm? Often the most obvious bugzes are overseen by an eye blinded by selfconfidence. Keep this in mind pals and this also: coding is not the hard work. Finding the bugz is the hard work.

mr. xsism, why not discussing about it? this is free space and everyone has the right to say what he thinks. see human rights or similar. *gg*

[Perica]

..

[Tux]

The bootloader and the kernel are attached by inserting the kernel at the end of the bootloader. So it is mostly loaded "raw". I also tried adding jc's. Still, the error happens. I too think that it might be the heads, but I kept changing them to see if they load...Nope. I was starting to believe that it was the kernel, but the thing is I tried different kernels. The ones under 9 kb worked, the others didn't.

[distantvoices]

it has to do with this 0xffff:0x0010 thingy i am sure:

look, your kernels below 9 kb till 9 kb work. this is the span from 0x10000 - 0x1021ff. Are you sure you adress it the right way?

[_mark]

it has to do with this 0xffff:0x0010 thingy i am sure:

look, your kernels below 9 kb till 9 kb work. this is the span from 0x10000 - 0x1021ff. Are you sure you adress it the right way?

I'm not so sure - the first read he issues is for 17 sectors - or 8.5K. He said kernels under 9K work fine. So the problem would seem to be in the second read of 18 sectors. But the memory address looks good, and as far as I can tell he has the correct value for head & track.

I had a bug a couple weeks ago almost identical to what he is describing. It turned out I had the wrong head value. One interesting thing I came accross is that CH is not the whole number for the track. The top 2 bits of CL are used to expand the track to 10 bits.

In my case though I just had DH wrong. The behavior though was what he described. It would read along just fine (in my case for 17 sectors), and then it would get real sluggish but not return an error.

_mark()

[Tux]

The kernel is 9 kb, butt Windows rounds it. It is actually 8.2 when I remove the end of the kernel code.

[Chris Giese]

Is A20 on? (Are you sure? Remember, there is no one way to control A20 that works on all PCs.) If A20 is off, the first call to INT 13h AH=02h will wipe out the interrupt table, and the next INT 13h will probably freeze the computer. Will this code successfully load the kernel to conventional memory?

Code: Select all

mov al,17         ; Total sectors to read

For multi-sector reads, you may need to patch the sectors-per-track value in the diskette parameter table, like the Win95 boot sector does -- see [url=http://www.nondot.org/sabre/os/files/Booting/win95.asm]http://www.nondot.org/sabre/os/files/Booting/win95.asm
[/url]

The floppy uses ISA DMA. No DMA transfer can cross a 64K boundary. INT 13h will return error code 9 if this happens. If you load only one 512-byte sector at a time, and load only to memory aligned on a 512-byte boundary, DMA overrun is not possible. (Also, if you use single sector reads, you don't need to patch the floppy parameter table either.)

It's possible that INT 13h AH=02h just won't read to extended memory on some BIOSes. Again, try loading the kernel into conventional memory.

In my experience, INT 13h AH=00h does not reset the floppy drive unless the motor is turning. In some cases, reading from sector 0 does a better job of resetting the drive than INT 13h AH=00h does.