OSDev.org

Hi, I am new to this forum.
I know this kind of problems have been answered many times, but I have read many topics and I can't definitively make my bootloader work.
I read usb floppy disk using int 13h, ah = 2. If I set these parameters : sector = 1, head = 1, cylinder = 0, then I read sector 63 correctly, but if I try sector = 1, head = 2, cylinder = 0, then I get an error (head max number is 1 from get drive parameters call (int 13h, ah = 8 )). And if I try sector = 1, head = 0, cylinder = 1, then I read sector 16065. So wtf? how can I read sector between 126-16065? am I doing something wrong?

ever wrote:I read usb floppy disk using int 13h, ah = 2.

Are you sure you're using a floppy disk drive? I ask this because you'll probably only have 18 sectors on each side of a track. I don't think you should be trying to read sector 63 on the first track (track 0).

If I set these parameters : sector = 1, head = 1, cylinder = 0, then I read sector 63 correctly, but if I try sector = 1, head = 2, cylinder = 0, then I get an error (head max number is 1 from get drive parameters call (int 13h, ah = 8 )).

A floppy disk has two sides using head 0 and head 1, so head 2 is not an option.

And if I try sector = 1, head = 0, cylinder = 1, then I read sector 16065. So wtf? how can I read sector between 126-16065? am I doing something wrong?

When you do that you should be getting sector 37 (decimal). If you aren't, you've got bugs. Have another few goes at fixing it, and if you still can't get anywhere it may be worth posting some of your code here, meaning everything up to the point where it fails.

Are you sure you're using a floppy disk drive?

yes im sure. Int13 ah=8 gets me 18 sectors per track you re right, but a read attempt at sector 1, head 1 gives me sector 64...

A floppy disk has two sides using head 0 and head 1, so head 2 is not an option

Yes but im working with DMDE and it gives me the following geometry : max cylinder: 127, max head: 105, max sector: 63. But it is probably wrong...

Here is the code (nasm): I just tested it, it gives me sector 16066

Hi,

ever wrote:I just tested it, it gives me sector 16066

If the device actually had 63 sectors per track and 255 heads; then asking for "cylinder 1, head 0, sector 2" would get you 1*255*63 + 0*63 + 1 = sector number 16066.

The code to get drive parameters and the code to read sectors looks fine. Therefore either your BIOS is messed up, or your BIOS has been messed up. I suspect the latter.

Specifically, I think this is the problem: This would mean that your stack trashes the BIOS's Interrupt Vector Table (IVT). The first piece of trashed data would be at 0x000001FE, which corresponds to the middle of the vector for interrupt 0x7F. Everything below that (limited only by how much stack space the BIOS and its IRQ handlers use) would be trashed too; including all of the vectors for interrupts 0x70 to 0x78 (which are used for IRQs 8 to 15, typically including IRQs for PCI devices like USB controllers).


Cheers,

Brendan

Brendan wrote:The code to get drive parameters and the code to read sectors looks fine.

Not completely, there's a check on CF missing, and the malformed ORG directive puts the data stored somewhere else than intended - not unlikely modifying the bootloader code itself.

CF missing

Its just a test piece of code. The sector is loaded correctly, its just not the right one.
ORG is right, the code is stored in a FAT boot sector. to preserve FAT structure it start at 0x7C3E.

If the device actually had 63 sectors per track and 255 heads; then asking for "cylinder 1, head 0, sector 2" would get you 1*255*63 + 0*63 + 1 = sector number 16066.

access to head 2 fail, thats why it s strange.

This would mean that your stack trashes the BIOS's Interrupt Vector Table (IVT).

ok :s is there a conventionnal place where to set the stack during bootloading?
I changed for this : anyway it doesnt solved the problem.

Hi,

ever wrote:

This would mean that your stack trashes the BIOS's Interrupt Vector Table (IVT).

ok :s is there a conventionnal place where to set the stack during bootloading?

There's no conventional place - everyone does it differently.

For an example; I normally copy the boot code to 0x0000:0x1000 and set SS:SP to 0x0000:0x1000. This gives me at least 2.5 KiB of stack space (before the BIOS Data Area starts getting in the way), and leaves a nice/unfragmented area of RAM from "end of boot loader" to "start of EBDA".

ever wrote:I changed for this :

Code: Select all

mov ax, 0x9000
mov ss, ax
mov sp, 0x200

That's bad too. The BIOS itself probably uses 1 KiB or more of your stack (for both BIOS functions you call, and for its IRQ handlers). This means that your tiny 512-byte stack will probably overflow, causing SP to wrap around from 0x0000 to 0xFFFE. After that happens you'll trash the BIOS's EBDA (starting with the 2 bytes at 0x9000:0xFFFE and working down towards wherever the EBDA starts).

ever wrote:anyway it doesnt solved the problem.

Ok. My next guess would be that the BIOS is using the BPB on the USB flash to figure out what format the emulated "floppy" should use; and that the BPB isn't right.


Cheers,

Brendan

hi brendan, thanks for your fast answers ^^

well, I see there that 0x0500 to 0x7C00 is unused so
I set my stack pointer here.

Ok. My next guess would be that the BIOS is using the BPB on the USB flash to figure out what format the emulated "floppy" should use; and that the BPB isn't right.

hmmmm... I modified the BPB for it to match what Get Drive parameters gives me.
Here is what it looks like :




And.......... still doesnt work -_-"

Hi,

ever wrote:hmmmm... I modified the BPB for it to match what Get Drive parameters gives me.
Here is what it looks like :

Something is still wrong with that.

If there's a total of 2046913 sectors (and each sector is 512 bytes), then the file system is about 999.47 MiB. A floppy is normally 1440 KiB, which is about 700 times smaller.

With 18 sectors per track, 2 heads and 2046913 sectors you'd need a total of 56858.694444 cylinders, which is much higher than the BIOS can handle (and isn't even an integer(!) ). For floppies the BIOS can only handle a maximum of 256 cylinders (for hard disks it goes up to 1024 cylinders, but for hard drives and "hard drive like devices" you'd want to be using "int 0x13 extensions" and LBA addresses anyway).

To me it looks like it was a "hard drive like" device from the beginning, and you've formatted it as a hard drive (possibly using Windows), and then tried to convince the BIOS it's a "floppy like device" when it never was.

The correct way would've been to create a 1440 KiB floppy image (formatted as FAT12 if you like) and then copy that 1440 KiB image to the beginning of the USB flash (and waste 998 MiB of the USB flash). Of course this assumes that the BIOS actually supports "USB flash emulating a floppy" (most BIOSs don't and only support "USB flash emulating a hard disk").

In any case; most BIOSs are dodgy enough without confusing them more with strange things (like 1 GiB floppies) that the BIOS author wouldn't have considered testing. I wouldn't be surprised if your BIOS can't figure out if the device is meant to be a floppy or a hard drive, and ends up in some broken "half way" state (like attempting to do CHS->CHS translation for large hard disks and forgetting that it's a "floppy").


Cheers,

Brendan

ever wrote:

Are you sure you're using a floppy disk drive?

yes im sure.

Except that you aren't using a floppy disk drive, so you sent me down the wrong track: I pictured a USB floppy drive (which would be dead easy to work with as it simply behaves like a normal floppy drive as drive 0 and always using CHS), but it appears that you're actually using a USB flash drive and your BPB contains a lot of values which don't fit with it being a floppy disk at all, leaving lots of room for a BIOS to be confused.

Your code calls "getdriveparameters" but it doesn't then go on to use any of the information it has just obtained - what it should be doing is adapting to the information returned to it by the BIOS in order to work out how to use the drive. If getdriveparameters is really telling you there are two heads for this drive and 18 sectors per track, it should then respond to that properly when you try to read them, so I'm surprised it isn't working if these values are actually being returned, but maybe the BIOS returns different values depending on what it finds in your BPB. How are you actually getting these values out to see what they are? Are you just relying on an early experiment where you may have made mistakes?

The behaviour of the machine (or are you using an emulator) does certainly sound strange though, because if getdriveparameters is really telling you there are 18 sectors per track, you shouldn't be able to read 63 of them, and if it's able to read 63 per tracks and then jumps to sector 16056 on the next track it should clearly be able to read from more than two heads, so I'm guessing that the BIOS may be unreliable when using CHS to read from a disk which it would ordinarily use LBA to access. Maybe you should switch to using LBA whenever the extensions are available and only revert to CHS for drives where LBA isn't available (which will only be very old hard disks and real floppies, all of them now practically obsolete).

ever wrote:well, I see there that 0x0500 to 0x7C00 is unused so
I set my stack pointer here.

Code: Select all

mov ax, 0x0500
mov ss, ax
mov sp, 0x4000

Learn to get that kind of math right. You just put the stack at 0x9000.

I can see endless problems dragging this out for some time for the OP, so maybe it would be best to suggest this now rather than waiting.

If you're trying to use a flash drive as if it's a floppy drive for booting a computer, you may be lucky and have a co-operative BIOS that automatically does the right thing with it, or you may be stuck with a BIOS that diverts you for months away from the job of getting on with building your OS by behaving differently on different machines. I'd say that if you aren't using real floppy disks, don't bother trying to copy their layout on a flash drive as it's going to waste most of the space on the drive. What you should do is put an MBR on the flash drive so that the BIOS will treat it as a hard disk. Write a table entry into that MBR for a FAT16/FAT32 partition covering most of the disk. Leave a reasonable gap in front of the partition though - I have some flash drives that came with a 2MB gap in front of the partition which is probably there primarily for wear-leveling purposes, those sectors likely being switched round with heavily used ones in the directory to extend the life of the drive.

Once you've defined the partition in the MBR table, you can then simply format the disk in Windows to create the FAT16/FAT32 directory in the actual partition - Windows will simply respond to the details you've written into the partition table. You don't have to do this, but I also put a second partition of my own type in the MBR's partition table and Windows doesn't interfere with it - it simply formats the partition which has been labelled as FAT32 in the partition table (or FAT16 in your case as you're using a smaller drive). Once you've got the disk set up in this way, you can assume that LBA will be available and you can use it without worrying about sector numbers per track, heads or tracks. You can then set up the MBR to boot the FAT16 partition, or to boot your own partition if you want to create one of your own design, or to load the second sector: you can use the gap between the MBR and the FAT16 partition to hold your own bootloader, or you could even stick your entire OS into it.

If you read a sector beyond the end of a flash drive, you can kill the drive, so be careful to work out the right values for your partition - ask someone here to check them if you're in any doubt and state the number of sectors givern for the drive by a hex editor. I made a few mistakes while adapting my OS to flash drives and did read beyond the end of a drive on a couple of occasions, but the BIOS may actually have prevented it from doing so - it simply froze at the point of the call and did no damage, but it could equally have been the flash drive protecting itself that caused the freeze. Don't assume that your setup will be so kind - get someone to check your numbers.

Read the wiki entry on MBR. You don't have to use anyone else's MBR code - you can simply write your own boot code into the MBR instead, though missing out any BPB that you might be starting your code with with at present. Be careful not to mess up the location of the partition table. Alternatively you can use a standard MBR and label one of the partitions in the table as bootable, and then you can put the VBR (bootsector) of your OS at the start of that partition, complete with BPB if appropriate (i.e. using the one created there by Windows when it formatted the partition for you). If you want your OS to go into a FAT16 partition, you will probably find a gap after the VBR where you can put more load code (or you could even fit a primitive OS into that space). There are many possible ways of doing things. I put my OS in my own special partition after a FAT32 partition and I've written an MBR that can boot either partition if both are labelled as bootable. This setup gives me the flexibility to run my own OS with my own filesystem and to import/export data via the FAT32 partition. I have avoided using the sectors immediately after the MBR, keeping them clear to make it easier to switch to using GPT once it becomes impossible to get flash drives smaller than 4TB.

So, for your early experiments, your best bet is to do one of two things. (1): Write your own MBR code and use it to load the second sector of the disk. You should probably have a partition set out on the disk, but you don't need to use it initially for your OS as there are enough sectors after the MBR to do a lot of experiments with there. Or (2): Use a standard MBR and use it to boot your VBR, while your VBR can then load the following sector(s), again there being enough of them there to do a lot of experiments with. You can then gradually work your way towards having the rest of your OS sit in proper files within the FAT16 partition which your loader can find and load in.

[Minor edit made to correct typos and improve readability.]

hey here,
sorry not to have replied earlier.

Learn to get that kind of math right. You just put the stack at 0x9000.

yes... I don't know what I was doing... I'm new to real mode assembly so don't be so mean...

Woaw ! Thanks for that great explication DavidCooper !! Yes, that was it. I formatted my usb drive as a hdd within windows then used it as a floppy with bochs... :/

If you read a sector beyond the end of a flash drive, you can kill the drive

thanks for this warning

I am now using disk image because it's simpler.
I made my own MBR then made a bootstrap for dual booting. Currently its working fine.

Thanks all for your help !