Re: Public domain boot sector released, compatible with MS-DOS 6.00 & 6.22
Benjamin David Lunt
"Rod Pemberton" <do_no...@noavailemail.cmm> wrote in message
news:iuqvr3$dsp$1...@speranza.aioe.org...
> "Benjamin David Lunt" <zf...@fysnet.net> wrote in message
> news:lX5Qp.49320$F25....@newsfe04.iad...
Hi Rod,
>> don't really know what $$ means
>
> It's the "beginning of the current section" address, i.e., ORG in this
> case.
> $ is the current address. E.g., $-$$ returns the offset from the start of
> the section (ORG) to the current address.
>> One thing that I have always had a problem with is booting from one
>> volume, scanning for all other volumes across multiple disks, then
>> knowing which one of those found volumes was the volume we booted
>> from. For example, when we boot, we know that the BIOS gave us
>> a value of 0x81 in DL, but there are three volumes on that disk.
>> Which one of those three volumes did we boot?
>
> Huh? Do you mean the "volume" that has the partition marked bootable?
> Doesn't the value in DL correspond to the _device_ booted? And, the
> _volume_ booted is base on the bootable flag in the partition table, yes?
> How do you select another volume to boot without a boot manager? Without
> user interaction, e.g., BIOS BBS pop-up boot selection window, the
> bootable
> partition on the lowest ranked bootable device is going to be booted by
> BIOS, yes?
>
>> Yes, we know that
>> we booted from LBA 10,000, but how do you connect the volume
>> at physical LBA 10,000 with DL = 0x81 and the volume you booted
>> from? Something to think about, huh?
>
> I know you're very well versed in this, but I'm more than a bit confused
> by
> your description of what happens... That's not what I understood to
> happen.
> Could you explain?
You are absolutely right. However, and sorry for the confusion, after
reading it again, I didn't express myself very well, sorry.
Anyway, let's look at the following few scenarios.
1. Let's say that we booted from a floppy disk. DL will be < 80h.
However, how do you know that DL=00h means that the BIOS used
the floppy at port 03F0h, or how do you know that DL=01h was the
floppy at port 0370h. If you have two floppy drives, how do you
know which floppy drive you booted from. The CMOS might be
a little help, but not always. I think there is a BIOS call that
you can call to see what port number that drive is using. This
scenario is not to important, but what about the following:
2. Let's say that the drive at 80h has 3 partitions with the 2nd partition
marked active. We would know that the second partition is most
likely the partition we booted from, as you state in your comments
above.
However, the machine also has another drive at 81h which also has
multiple partitions with one of those partitions marked active/bootable.
My question is, how do you know which of those two active partitions
was the booted-from partition? Let's say that both drives are
standard hard drives on the same IDE controller, one being the
master and one being the slave. With the BIOS/CMOS using 80h
and 81h as the drive numbers, how do you associate 80h with one
drive and 81h with the other? It is not always absolute that
80h will be the master and 81h will be the slave.
3. How about this one, using the same setup as above:
What if we booted from a USB flash drive. The BIOS emulates it
as a standard IDE hard drive giving it a DL value 82h*. As we
go through the drive enumeration process, now no longer using the
BIOS, we don't find the drive it had as 82h because we only found
drives 80h and 81h. Later when we enumerate the USB, we find the
flash drive. However, how do we know we booted from that flash
drive?
There really isn't much of a reason to find out which drive we booted
from other than two things.
1. When we have finished enumerating all of the hardware and are
now ready to display the prompt, what drive do we set as the
current (default) drive. We would like to set it to the
one we booted from. However, the big question here is, how
do we associate the name (maybe C:, D:, E: or what ever) with
the actual, physical booted from volume.
2. When we update the registry, or system files, or whatever
other system files we would need to update after boot, how do
we know to update the system files on the booted from volume,
and not another volume with a similar setup? For example,
let's say that we have the two drives mentioned above, with
three partitions each. Each active partition has the same
operating system on it. Yes, why would we do that, but for
the sake of this example, which of the two OS's system files do
we know to update after boot? The first drive's partition or
the second drive's? If we booted from the flash drive in
scenario 3 above, which has the same OS on it as one of the
partitions on the IDE drives, how do we know to update the
system files on the flash drive and not the partition on the
physical IDE drive?
Does that make it more clear? Hope so. Let me know if I need to
explain it more. Sometimes I confuse myself, and the other times
I am already confused :-)
Ben
P.S. I CC'd alt.os.development too.
[*] For those that don't know how I think (smile), these are all
theoretical numbered drives. Don't take these numbers as
literal. :-) They maybe 80h, 81h, E1h, etc. I am just using
these numbers to denote 80h as the first, 81h as the second,
and 82h as the third.
wolfgang kern
Benjamin David Lunt wrote:
[... about determination of the boot-drive ...]
Me too have this problem on my workstation where I use several HDs
with almost equal contents, to always keep one working version :)
The BIOS isn't of help here because it reports the current boot-drv
as the first. So I scan all HDs and volumes on boot-up myself and I
have marks in the MBRs and dont need to scan for matches to see which
HD/partition is the actual, and I store all LBA-info in MBR as well.
A problem could be booting from external drives that haven't got this
hardware scan as part of the OS ...
__
wolfgang
Benjamin David Lunt
[I forgot to cc this group too]
----- Original Message -----
From: "Benjamin David Lunt" <zf...@fysnet.net>
Newsgroups: alt.lang.asm
Sent: Tuesday, July 05, 2011 5:41 PM
Subject: Re: Public domain boot sector released, compatible with MS-DOS 6.00
& 6.22
>
> Sorry for the delay in my reply. It got busy around here.
>
> Also, sorry for the top post. For some reason, and I haven't
> taken the time to find out, some times OE won't add the '>'
> to the quoted text.
>
> Anyway,
>
> I do understand that
> mov bx,[bp+xx]
> is a byte smaller than
> mov bx,[xxxx]
>
> However, have you noticed that once you get to around 80h
> away from '$$' that no longer applies? In other words,
> mov bx,[bp+0081h]
> is no longer one byte less than
> mov bx,[xxxx]
>
> 0B2C:0100 8B4600 MOV AX,[BP+00]
> 0B2C:0103 8B467F MOV AX,[BP+7F]
> 0B2C:0106 8B868000 MOV AX,[BP+0080]
> 0B2C:010A 8B868100 MOV AX,[BP+0081]
> 0B2C:010E A11111 MOV AX,[1111]
> 0B2C:0111 8B5E00 MOV BX,[BP+00]
> 0B2C:0114 8B5E7F MOV BX,[BP+7F]
> 0B2C:0117 8B9E8000 MOV BX,[BP+0080]
> 0B2C:011B 8B9E8100 MOV BX,[BP+0081]
> 0B2C:011F 8B1E1111 MOV BX,[1111]
>
> I was just stating that how many do you have before offset
> 80h compared to after offset 80h? Is it worth the trouble?
>
> I think you could easily find a few bytes before 80h to
> shave off and still use the standard
>
> add al,[xxxx]
>
> instead of the "ugly" ( sorry :-) )
>
> add al,[bp+xx-$$]
>
> Remember, I once new a group that could shave many
> bytes off of a program that it would amaze you what
> they could do in 100 bytes compared to the 256 that
> was expected. That group was called Hugi or something
> like that :-)
>
> Anyway, good luck in your work. After all, and I have
> always said this, if you can't enjoy it, why do it.
>
> Thanks,
> Ben
>
> "Willow" <wrsch...@gmail.com> wrote in message
> news:e9168db3-589b-4b17...@z7g2000prh.googlegroups.com...
> Hi Ben,
> Thanks for the feedback! It's great to hear from a fellow filesystem
> enthusiast, even if my code is the "ugliest" you have seen in a while!
>
> On Jul 3, 3:21 pm, "Benjamin David Lunt" <zf...@fysnet.net> wrote:
> [snip]
>> As anyone here knows, I like filesystems, even if it is the FAT
>> filesystem (smile). Therefore, I looked through your code.
>> Don't take any of my comments as criticism. I mean no harm, just
>> feedback. However, I have to admit that this is the ugliest
>> code I have seen in a while :-). I am not a NASM user, so I
>> don't really know what $$ means, but it makes me think that you
>> could have used it once and been done.
>>
>> Also, why do you not indent?
>
> So with NASM $$ is a label that means "the start of the current
> section." I used it here out of habit, because I was used to 32-bit or
> 64-bit OS development. Basically if I have some label X then X-$$ is a
> number, i.e. the distance between X and the start of the current
> section. I could have done X-0x7c00 here, since we are producing raw
> binary files.
>
> Believe it or not, if you read the Intel manuals you will see that an
> instruction like ADD AL,[Label] requires 3 bytes for its modr/m (the
> [Label] part), whereas ADD AL,[BP+Label-0x7c00] or the equivalent code
> I used, ADD AL,[BP+Label-$$] which means the same thing, requires only
> 2 bytes: one for the modr/m itself and one for the 8-bit signed offset
> "Label-0x7c00". Here is a disassembly from DEBUG just to prove the
> point:
>
> 17B8:0100 0206227C ADD AL,[7C22]
> 17B8:0104 024622 ADD AL,[BP+22]
>
> You can see that I save a byte each time I use [BP+xx] in stead of
> [yyyy]. This really makes a difference, the code had to fit in 512
> bytes !!
>
> As far as indenting and the volume label goes, how did you read my
> code? Did you view it in a web browser or what? I make use of TABs,
> for best results use a tab size of 4 bytes (if I recall correctly, it
> has been a day since I wrote this!) My volume label was supposed to be
> eleven spaces. Perhaps your web browser shortened it to one space and
> removed the nice indentation I put in there?
>
> You should be able to download the file at this direct link:
> http://reverse.googlecode.com/svn/trunk/archive/generic_dos_boot_sector/boot1216.asm
>
> If you use a web browser to view it, try viewing the source or saving
> the file as a text file to your hard disk, then view it with a tab
> size of 4 spaces. It should look good and you should count eleven
> spaces in the volume id. There is no typo here, I actually booted MS-
> DOS 6.00 & also MS-DOS 6.22 with this boot sector, off a 1.44 mb
> floppy image.
>
> You can build it with this command:
> nasm boot1216
>
>> (Again, no harm intended with my comments, just some feedback)
> No offence is taken. I'm just happy someone out there read my code!
> Any suggestions on making it less ugly? $$ just means 0x7c00 in this
> case.
>
> [snip]
>> >cli ; This should be first instruction after jmp short
>> > ; (some OSes check for it)
>>
>> What are your sources? I have never seen any reference to
>> an OS checking for 'cli' after the BPB.
>> I understand that it is the obvious next move. In otherwords,
>
> I relied on my memory, which admittedly is not as good as it once was!
> I think it was the ReactOS boot sector or MBR that had a comment in
> there claiming Windows NT 4 "blows up" if the first instruction is not
> CLI. This is not a very good reason to put CLI as the first
> instruction in my DOS 6.00/6.22 compatible boot sector, though; I
> could save a byte taking it out, but better safe than sorry right?
> Maybe it was just the MBR whose first instruction was supposed to be
> CLI and not the boot sector. I think the idea was NT4 might only trust
> MBRs that begin with CLI..... but I could be wrong here. It's only a
> byte for CLI in any case!
>
> [snip]
>> Also, does DOS assume a 386+ machine? i.e.: you use 32-bit
>> instructions but don't check for a 32-bit machine. I know that
>> now days 32-bits is the norm, but you are talking about DOS here...
>
> No, DOS works on an 8086. It's scary that way. I feel justified in
> using 386 instructions though, since my target was a PC emulator that
> I developed (see my post on CRUDASM5/SimplePC for details) which is
> known to support 386 real mode instructions, at least the ones I use
> here! In any case, you can get a decent system on a board which
> supports at least 486+ instructions for say $5-$15, so there is no
> real justification for making a DOS that runs on an 8086. (Maybe NASA
> has some peripherals that have an 8086 on it, but it probably doesn't
> run DOS).
>
> I want to point out that I used IBM/MS INT 13 disk extensions to read
> from disk. It would be hard to do that using only 8086 instructions, I
> needed good accuracy for LBA calculations.
>
> [snip]
>> One thing you *must* remember though, is that you can not have any
>> code after the first sector that is used before you load the remaining
>> sectors. I think what frustrates most new boot code writers is that
>> they have perfectly written boot code that uses two or more sectors
>> and can't figure out why their code crashes when they call the
>> read_sectors
>> function, which by the way is in the second sector of their code. :-)
>
> My goal here was to be 100% compatible with MS-DOS 6.00 & 6.22, while
> still letting me develop my own OS.
> Thus my boot sector reads the first 3 sectors of IO.SYS. For "true" MS-
> DOS volumes, the first 3 sectors of IO.SYS must be contiguous, i.e.
> you generally prepare a system DOS disk by ensuring the first 2
> directory entries are IO.SYS & MSDOS.SYS respectively, then you copy
> those files over, ensuring the first 3 sectors of IO.SYS are
> contiguous on disk. This is what MS-DOS itself does.
>
> For my own OS loader (a work in progress), I still read the first 3
> sectors of IO.SYS from disk, but I no longer demand they be
> contiguous. Only the first sector of IO.SYS is trusted (since the next
> 2 sectors are just whatever followed that sector on disk and might not
> really belong to IO.SYS--hopefully the first sector won't be the last
> sector on disk!); then that first sector copies itself to 0x7e00 and
> works with the first part of the boot sector to walk through the FAT
> chain and re-read IO.SYS even if it is not wholly contiguous. (The
> actual plan is to read the first 4 sectors of IO.SYS in a slow way, so
> we now have more space to write code to do a fast read of the whole
> IO.SYS).
>
> My intent is to put some kernel files in IO.SYS, i.e. it can be larger
> than 64KB, sort of like an archive containing multiple files, only
> without compression.
>
> My PC emulator makes a log file for each instruction that executes. I
> can then examine this log file to produce an intelligent disassembly
> of every file that has executed, the disassembly shows only lines of
> code that really executed -- everything else is DB'd. The cool thing I
> discovered is that if you look up the file and offset within the file
> corresponding to disk reads, and move metadata when MOVS is used, you
> can easily track which instruction is running. This works only when no
> compression is used, i.e. it works on MS-DOS 6.00 & 6.22 but not on
> FreeDOS. So given a byte of memory, I have metadata that tells me
> where that byte came from: which file and offset within the file; or,
> if it has been overwritten (other than due to a MOVS), I will know
> that as well.
>
> A while back I discovered obfuscated code in Windows 3.1, which in my
> opinion was designed to detect rival DOSes, using this technique.
>
> Trivia: did you know that if MS-DOS boot fails at just the right time
> [ex.: eject the floppy disk you're booting from after control has been
> transfered from the boot sector], it will print out garbage on the
> screen instead of an error message? Then it waits for a keypress and
> reboots. I think it was fixed in Windows 98. They got the data segment
> wrong here.
> Also, did you know Windows 95 looks for JO.SYS and only if it is not
> found does it look for IO.SYS? Talk about a big back door! Also, did
> you know BIOS floppy disk reads can fail if you try to cross a 64KB
> boundary? I discovered that the hard way, it's because they use DMA.
> MS-DOS will intercept interrupt 0x13 (but it does it buggy by leaving
> interrupts disabled, meaning you want to do STC / INT 13h / STI if you
> rely on MS-DOS) and read to a buffer known to not cross a 64KB
> boundary, then move that data up to the requested location. This is
> slow because it has to read 1 sector at a time when it does that, but
> it only happens when the BIOS int 13h returns a DMA boundary error.
>
> The BPB does report its boot drive number, which I rely on rather than
> trusting the input DL from the BIOS. Also the number of hidden sectors
> IS the LBA of the boot sector on that drive, so in effect we do know
> where we are.
>
> By the way, I have used GRUB for OS development and it worked great,
> but the version I used had no 64-bit OS support so I had to do some
> ugly hacks to get it to work. If it's going to be ugly, why not go all
> the way and make it really ugly, i.e. do everything myself?
>
> [snip]
>> Batteries not included, some assembly required.
>
> Cheers !
> Willow
>
>
wolfgang kern
Benjamin David Lunt mentioned:
...
> I do understand that
> mov bx,[bp+xx]
> is a byte smaller than
> mov bx,[xxxx]
> However, have you noticed that once you get to around 80h
> away from '$$' that no longer applies? In other words,
> mov bx,[bp+0081h]
> is no longer one byte less than
> mov bx,[xxxx]
> 0B2C:0100 8B4600 MOV AX,[BP+00]
> 0B2C:0103 8B467F MOV AX,[BP+7F]
> 0B2C:0106 8B868000 MOV AX,[BP+0080]
> 0B2C:010A 8B868100 MOV AX,[BP+0081]
> 0B2C:010E A11111 MOV AX,[1111]
> 0B2C:0111 8B5E00 MOV BX,[BP+00]
> 0B2C:0114 8B5E7F MOV BX,[BP+7F]
> 0B2C:0117 8B9E8000 MOV BX,[BP+0080]
> 0B2C:011B 8B9E8100 MOV BX,[BP+0081]
> 0B2C:011F 8B1E1111 MOV BX,[1111]
> I was just stating that how many do you have before offset
> 80h compared to after offset 80h? Is it worth the trouble?
...
Yeah, this 80h-barrier once made me rewrite my sys-flags access.
I didn't alter the usage of this 2048 bits (256 byte) array,
but I could shorten the whole OS-core by using a single register
pointing into the middle of the array (-80..ff followed by +00..7f).
So all my system routines keep EBP = 0_0090h and this array reside
near stack-bottom, which I put at 0010_0000h to have all 256 bytes
accessible with the shorter form from both, RM and PM.
And quite many of my structs are just 256 byte 'large', so this 80h-
bias trick became handy there as well, even it once needed me to think
twice on where the things really are :) meanwhile I'm familiar with.
__
wolfgang
Rod Pemberton
>
> > Could you explain?
>
> You are absolutely right. However, and sorry for the confusion, after
> reading it again, I didn't express myself very well, sorry.
>
> Anyway, let's look at the following few scenarios.
>
> 1. Let's say that we booted from a floppy disk. DL will be < 80h.
> However, how do you know that DL=00h means that the BIOS used
> the floppy at port 03F0h, or how do you know that DL=01h was the
> floppy at port 0370h. If you have two floppy drives, how do you
> know which floppy drive you booted from. The CMOS might be
> a little help, but not always. I think there is a BIOS call that
> you can call to see what port number that drive is using. This
> scenario is not to important, but what about the following:
>
AFAIK, you boot from the primary floppy only... I.e., DL should correspond
to the port used. Off hand, I don't ever recall being able to boot from B:
or secondary floppy... DOS will switch drives if nothing is in A:, but BIOS
shouldn't. Some BIOS' do allow you to reverse the floppy drive order. I
would hope that they they change the reported DL value and switch port
values in circuitry too.
> 2. Let's say that the drive at 80h has 3 partitions with the 2nd
> partition marked active. We would know that the second partition
> is most likely the partition we booted from, as you state in your
> comments above.
> However, the machine also has another drive at 81h which also has
> multiple partitions with one of those partitions marked
> active/bootable.
> My question is, how do you know which of those two active partitions
> was the booted-from partition? Let's say that both drives are
> standard hard drives on the same IDE controller, one being the
> master and one being the slave. With the BIOS/CMOS using 80h
> and 81h as the drive numbers, how do you associate 80h with one
> drive and 81h with the other? It is not always absolute that
> 80h will be the master and 81h will be the slave.
>
primary IDE
-master
-slave
secondary IDE
-master
-slave
AFAIK, you cannot boot from the slave(s), ever. You can boot from either of
the masters, if they have a partition marked bootable. AIUI, the primary is
selected to boot first.
AFAIR, I've never known any machine, new or old, that would boot from a
non-master IDE, not for HDs, nor for cdroms. AIR, BIOS' went from cable
and/or pin header select, to select boot order via BIOS - but no slaves, to
BIOS select - but no slaves and w/BBS. I believe that's why I always have
to put cdroms in as a slave on the primary channel when the harddisk is the
master boot device. On numerous occasions, I've installed a slave drive
from another machine where it was a boot drive and has a partition marked
bootable. AIR, I've always had to change the cable connections or pin
header, to switch harddisk boot order master/slave. The primary master
always boots assuming a partition is marked bootable. Of course, this was a
single channel of IDE. Unfortunately, I've not confirmed now that BBS spec
is available if BBS allows manual selection of secondaries for boot or not.
In these situations, there is only one potential master.
So, let's look at two potential masters for 80h and 81h: one master on
primary IDE channel and one master on secondary IDE channel. If the master
on the primary has a partition marked bootable, it'll boot. If the master
on the primary is not bootable, the master on the secondary should boot, if
a partition is marked bootable. If the master did not boot, it can't have a
partition marked bootable. So, since we've booted, I'd think that all you
need do is to check the primary master device to see if it has a bootable
partition: yes, then we booted master on primary using the bootable
partition, or no, then booted master on secondary using the bootable
partition.
I.e., shouldn't it be something like so:
-partition on master that booted = 80h
-enumerate remaining partitions by primary master, secondary master, primary
slave, secondary slave, as present
> 3. How about this one, using the same setup as above:
> What if we booted from a USB flash drive. The BIOS emulates it
> as a standard IDE hard drive giving it a DL value 82h*. As we
> go through the drive enumeration process, now no longer using the
> BIOS, we don't find the drive it had as 82h because we only found
> drives 80h and 81h. Later when we enumerate the USB, we find the
> flash drive. However, how do we know we booted from that flash
> drive?
>
I've not looked at what this machine does, so I'll have to take your word
it's not 80h or 81h. I would think it should be 80h though... AIUI, the
BIOS is doing IDE emulation. Since the booted USB drive is the first
"harddisk" (emulated) device, I would've guessed that it should be reported
as 80h.
> [three questions]
Except for cd/dvdroms, one solution for all three situations would be for
the bootloader to write a flag back to the disk loaded from, although that
makes cringe a bit... Another could be to use a serial number and have the
bootloader to load and save the disk's serial number (using initial DL).
There are things that could be used as a serial number, e.g., partition
table line or volume name.
> There really isn't much of a reason to find out which drive we booted
> from other than two things.
>
I was going to ask you why you were concerned with this as long as DL is
valid and you can use BIOS floppy/disk routines with DL.
> 1. When we have finished enumerating all of the hardware and are
> now ready to display the prompt, what drive do we set as the
> current (default) drive. We would like to set it to the
> one we booted from. However, the big question here is, how
> do we associate the name (maybe C:, D:, E: or what ever) with
> the actual, physical booted from volume.
>
I see this as the same as #1 above. Isn't it?
> 2. When we update the registry, or system files, or whatever
> other system files we would need to update after boot, how do
> we know to update the system files on the booted from volume,
> and not another volume with a similar setup? For example,
> let's say that we have the two drives mentioned above, with
> three partitions each. Each active partition has the same
> operating system on it. Yes, why would we do that, but for
> the sake of this example, which of the two OS's system files do
> we know to update after boot? The first drive's partition or
> the second drive's? If we booted from the flash drive in
> scenario 3 above, which has the same OS on it as one of the
> partitions on the IDE drives, how do we know to update the
> system files on the flash drive and not the partition on the
> physical IDE drive?
>
... because we've determined which drive we booted from? In a DOS like OS,
the boot harddisk should be mapped as C: I.e., you'll be updating C:
"Each active partition"... I usually take "active" to mean "bootable" for
which there is a flag, IIRC, in the partition table entry. You just mean
"valid", I think.
> Does that make it more clear? Hope so. Let me know if I need to
> explain it more. Sometimes I confuse myself, and the other times
> I am already confused :-)
>
I'm not sure... AFAIR, you can't boot slaves or secondaries. Yet, your
examples do that, or I took them to mean that.
Rod Pemberton
Benjamin David Lunt
"Rod Pemberton" <do_no...@noavailemail.cmm> wrote in message
> "Benjamin David Lunt" <zf...@fysnet.net> wrote in message
> news:%f8Qp.14998$eG6...@newsfe09.iad...
>>
Hi Rod,
>> > Could you explain?
>>
>> You are absolutely right. However, and sorry for the confusion, after
>> reading it again, I didn't express myself very well, sorry.
>>
>> Anyway, let's look at the following few scenarios.
>>
>> 1. Let's say that we booted from a floppy disk. DL will be < 80h.
>> However, how do you know that DL=00h means that the BIOS used
>> the floppy at port 03F0h, or how do you know that DL=01h was the
>> floppy at port 0370h. If you have two floppy drives, how do you
>> know which floppy drive you booted from. The CMOS might be
>> a little help, but not always. I think there is a BIOS call that
>> you can call to see what port number that drive is using. This
>> scenario is not to important, but what about the following:
>>
>
> AFAIK, you boot from the primary floppy only... I.e., DL should
> correspond
> to the port used. Off hand, I don't ever recall being able to boot from
> B:
> or secondary floppy... DOS will switch drives if nothing is in A:, but
> BIOS
> shouldn't. Some BIOS' do allow you to reverse the floppy drive order. I
> would hope that they they change the reported DL value and switch port
> values in circuitry too.
No. I got a FastData 486 here that will allow you to boot either one.
From the CMOS. I haven't checked on it, but I bet that the booted from
drive is 00h and the other is 01h no matter the order. I will have to
do some tests...
I have several drives that are drive-select. A jumper allows primary,
secondary or drive-select. Then the CMOS allows me to choose which
drive to boot from.
>> 3. How about this one, using the same setup as above:
>> What if we booted from a USB flash drive. The BIOS emulates it
>> as a standard IDE hard drive giving it a DL value 82h*. As we
>> go through the drive enumeration process, now no longer using the
>> BIOS, we don't find the drive it had as 82h because we only found
>> drives 80h and 81h. Later when we enumerate the USB, we find the
>> flash drive. However, how do we know we booted from that flash
>> drive?
>>
>
> I've not looked at what this machine does, so I'll have to take your word
> it's not 80h or 81h. I would think it should be 80h though... AIUI, the
> BIOS is doing IDE emulation. Since the booted USB drive is the first
> "harddisk" (emulated) device, I would've guessed that it should be
> reported
> as 80h.
I have not checked. I smell another test... However, you can not be
sure that every BIOS/CMOS will be the same. They may enumerate the
physical drives first.
Even though, if you have a DL value of 80h what is there to tell the
kernel (or loader) that the 80h points to the (now non existant[1]) USB
emulation drive and not the first (primary) hard drive?
[1] - now that I am in pmode, I no longer have access to the emulated
drive.
>> [three questions]
>
> Except for cd/dvdroms, one solution for all three situations would be for
> the bootloader to write a flag back to the disk loaded from, although that
> makes cringe a bit... Another could be to use a serial number and have
> the
> bootloader to load and save the disk's serial number (using initial DL).
> There are things that could be used as a serial number, e.g., partition
> table line or volume name.
Currently, I store the whole 512 byte boot sector into another known
memory offset, then when enumeration of volumes, I compare each enumerated
volume with the stored 512 byte boot sector. If a match, most likely
this is the booted from drive. However, this is not fool proof. I could
have a backup drive (or a ghost drive) with the same boot sector...
No, I meant active or bootable as you do.
>> Does that make it more clear? Hope so. Let me know if I need to
>> explain it more. Sometimes I confuse myself, and the other times
>> I am already confused :-)
>>
>
> I'm not sure... AFAIR, you can't boot slaves or secondaries. Yet, your
> examples do that, or I took them to mean that.
Yes, I do mean that. As far as I know, I can boot all block devices
attached to the machine, IDE, ATA, SATA, USB, etc., and at boot time,
when the BIOS turns control to us, all I have is a value in DL...
I will run some tests to be sure, I don't want to tell you that my
machines will boot secondary drives with out checking. However, I
am pretty sure that they have all these years, with a simple change
in the CMOS...
Ben
Rod Pemberton
>
> I will run some tests to be sure, I don't want to tell you that my
> machines will boot secondary drives with out checking. However, I
> am pretty sure that they have all these years, with a simple change
> in the CMOS...
>
Well, I've never done a thorough test of this. I'm just recalling my
personal experiences building PCs. So, I probably should do some tests on
the machines I've got once I get back to working on my OS. This machine has
BBS which allows booting other devices, like USB. So, finding out how DL
and ports correspond will be interesting... For safety, I usually unplug my
main drive when booting a non-main drive. So, that may change
ordering/numbering. It'd be nice if the AOD faq had such info on the
"machine characteristics" page. It just has basic boot DL. If you do write
a test for this and release it, I thank you in advance! It could be a quite
while before I get around to it.
http://aodfaq.wikispaces.com/machine+characteristics
Rod Pemberton
wolfgang kern
Rod Pemberton in discussion with Benjamin David Lunt"....
>> I will run some tests to be sure, I don't want to tell you that my
>> machines will boot secondary drives with out checking. However, I
>> am pretty sure that they have all these years, with a simple change
>> in the CMOS...
It may not be stored in CMOS anymore...
I can boot (Bios F11) from whatsoever device is connected as long I
allow bootoptions in the BIOS at all.
> Well, I've never done a thorough test of this. I'm just recalling my
> personal experiences building PCs. So, I probably should do some tests on
> the machines I've got once I get back to working on my OS. This machine
> has
> BBS which allows booting other devices, like USB. So, finding out how DL
> and ports correspond will be interesting... For safety, I usually unplug
> my
> main drive when booting a non-main drive. So, that may change
> ordering/numbering. It'd be nice if the AOD faq had such info on the
> "machine characteristics" page. It just has basic boot DL. If you do
> write
> a test for this and release it, I thank you in advance! It could be a
> quite
> while before I get around to it.
> http://aodfaq.wikispaces.com/machine+characteristics
windoze-install act like a trojan virus and Loonix checks and compare
BIOS-info against its own ill gotten C-styled libraries...
So MHO on the matter just is: both rely on CS-degree schools and got
nothing in common with real hardware needs.
I know the how to detect and interprete info from BIOS and (much more
reliable) the how to check on existing hardware on my own.
This way made me independent and absolutely free to configure my OS.
So I actually give a fart to what BIOS reports as the current drive
in DL, because it for sure doesn't reflect the given hardware.
__
wolfgang