Booting from a USB and BIOS faults
Posted: Thu Jun 17, 2021 8:13 pm
Hi guys,
It has been a while, but I have found a bit of time to come back and participate. I have been following the "Bootloaderis not consistent when booting in real hardware" thread, particularly with the start of BIOS fault conversation.
I can confirm that that particular BIOS, the one that Octocontrabass mentions, does in fact modify your code/data depending on the BPB and/or Partition Table entry it finds.
For example, if you go to my bit of code (which has a 1.44Meg binary file if you don't want to assemble it) will show that offset 0x012F of the returned data is corrupt. After the read, whether I use CHS or Disk Extentions, the word at 0x12F of the returned read buffer is corrupt.
At first I thought it was my code. However, there are a few modifications to the code that will change this.
First Example: (With IS_HARDDRIVE == 0)
Instead of a valid partition entry, clear all sixteen bytes to zero, then run again. The word at 0x12F is no longer corrupt.
Second Example: (With IS_HARDDRIVE == 0)
Keep the partition entry as is, a 1.44m entry, and instead of writing zeros to the remainder of the disk, write 0xFF's. The word at 0x12F is no longer corrupt.
Third Example: (With IS_HARDDRIVE == 1)
Set IS_HARDDRIVE to 1 so that it uses a FAT16 BPB and a "larger" Partition Table entry and the word at 0x12F is no longer corrupt.
This proves to me that the BIOS does in fact look for a valid BPB and/or MBR Partition entry. However, I do not know why it is modifying the word at offset 0x12F of the returned read buffer.
Granted, why would I have a MBR Partition Entry if I was going to try to emulate a 1.44Meg floppy?
I wouldn't, however, the reason for it here, is to prove that indeed, this particular BIOS does check for a BPB and/or Partition Table, and corrupts the data if the data found is not "the normal way of doing it".
I can only speculate here, but I am guessing with the 2nd example above is that the BIOS is checking the actual FAT and/or ROOT of the (non-existent) partition. I am guessing more on the FAT than the ROOT, since a value of 0xFF will be "no more entries". Though this is only speculation.
Anyway, I have spent the past couple of hours modifying the code slightly each time to see what results I got. I checked two different BIOSes, both of the same manufacture, one considerably newer than the other, and both give the exact results.
Also, since I don't have a valid FAT File System on the USB drive, both BIOSes return 0x01CA4000 sectors, which is the whole 16-gig drive, no matter if the IS_HARDDRIVE equate is zero or one.
My conclusion is, at least for this particular BIOS, if you want to emulate a 1.44Meg floppy, you must have a valid BPB, no Partition Table, and a valid FAT, at least the first two entries (0xFFF and 0xFF0). I am not 100% confident that this is the case, but currently I am thinking this. More tests will be in order.
Anyway, I just thought I would share. I am not trying to say that one person is right and the other is wrong, I am just showing proof of a bug in the BIOS. Maybe not a "bug", but an irregularity if the data on the USB disk is not the "normal expected type". Which then means, a lot of newbies might be pulling their hair out asking why their code doesn't work when in fact it is a irregularity in the BIOS emulation, not their code.
Feel free to take my code and modify it to see what results you get. I would be very interested in seeing what you find.
Ben
- http://www.fysnet.net/the_universal_serial_bus.htm
It has been a while, but I have found a bit of time to come back and participate. I have been following the "Bootloaderis not consistent when booting in real hardware" thread, particularly with the start of BIOS fault conversation.
I can confirm that that particular BIOS, the one that Octocontrabass mentions, does in fact modify your code/data depending on the BPB and/or Partition Table entry it finds.
For example, if you go to my bit of code (which has a 1.44Meg binary file if you don't want to assemble it) will show that offset 0x012F of the returned data is corrupt. After the read, whether I use CHS or Disk Extentions, the word at 0x12F of the returned read buffer is corrupt.
At first I thought it was my code. However, there are a few modifications to the code that will change this.
First Example: (With IS_HARDDRIVE == 0)
Instead of a valid partition entry, clear all sixteen bytes to zero, then run again. The word at 0x12F is no longer corrupt.
Code: Select all
; modify existing code as so:
; db 0 ; boot id
; db 0 ; start head
; db 1 ; start sector
; db 0 ; start cyl
; db 1 ; sys id 1 = FAT12
; db 1 ; end head
; db 18 ; end sector
; db 79 ; end cyl
; dd 0 ; start lba
; dd 2880 ; size in sectors
dup 16,0
Keep the partition entry as is, a 1.44m entry, and instead of writing zeros to the remainder of the disk, write 0xFF's. The word at 0x12F is no longer corrupt.
Code: Select all
; modify existing code as so:
; temp_buff dup ((2880 * 512) - $),00h
temp_buff dup ((2880 * 512) - $),0FFh
Set IS_HARDDRIVE to 1 so that it uses a FAT16 BPB and a "larger" Partition Table entry and the word at 0x12F is no longer corrupt.
Code: Select all
; modify existing code as so:
; IS_HARDDRIVE equ 0 ; 0 = use 1.44 floppy emulation, 1 = use hard drive emulation
IS_HARDDRIVE equ 1 ; 0 = use 1.44 floppy emulation, 1 = use hard drive emulation
Granted, why would I have a MBR Partition Entry if I was going to try to emulate a 1.44Meg floppy?
I wouldn't, however, the reason for it here, is to prove that indeed, this particular BIOS does check for a BPB and/or Partition Table, and corrupts the data if the data found is not "the normal way of doing it".
I can only speculate here, but I am guessing with the 2nd example above is that the BIOS is checking the actual FAT and/or ROOT of the (non-existent) partition. I am guessing more on the FAT than the ROOT, since a value of 0xFF will be "no more entries". Though this is only speculation.
Anyway, I have spent the past couple of hours modifying the code slightly each time to see what results I got. I checked two different BIOSes, both of the same manufacture, one considerably newer than the other, and both give the exact results.
Also, since I don't have a valid FAT File System on the USB drive, both BIOSes return 0x01CA4000 sectors, which is the whole 16-gig drive, no matter if the IS_HARDDRIVE equate is zero or one.
My conclusion is, at least for this particular BIOS, if you want to emulate a 1.44Meg floppy, you must have a valid BPB, no Partition Table, and a valid FAT, at least the first two entries (0xFFF and 0xFF0). I am not 100% confident that this is the case, but currently I am thinking this. More tests will be in order.
Anyway, I just thought I would share. I am not trying to say that one person is right and the other is wrong, I am just showing proof of a bug in the BIOS. Maybe not a "bug", but an irregularity if the data on the USB disk is not the "normal expected type". Which then means, a lot of newbies might be pulling their hair out asking why their code doesn't work when in fact it is a irregularity in the BIOS emulation, not their code.
Feel free to take my code and modify it to see what results you get. I would be very interested in seeing what you find.
Ben
- http://www.fysnet.net/the_universal_serial_bus.htm