1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

power down

Discussion in 'PC Hardware' started by Allan Adler, Oct 19, 2007.

  1. I've enjoyed reading the arguments over what's correct and what's not,
    although frankly I don't care about the conclusions. But anyway, this
    afternoon I decided to try it for myself, and I found that bochs refused
    to boot without the signature but all seven real computers booted fine.

    Apart from my need (or whatever!) to boot in bochs, I don't see any reason
    to omit the signature. I can afford those two bytes in my boot sector. My
    OS will never go anywhere outside of my office, but if in some parallel
    universe it did I think I'd keep the signature - not because any spec is
    splendidly correct in its ivory tower, but for Max's reason: if my OS
    might encounter a machine that won't boot without the signature, then let
    it have the signature.
    Ciaran Keating, Nov 7, 2007
    1. Advertisements

  2. Allan Adler

    s_dubrovich Guest

    Good for you!, for stepping outside the box of dogma, to find that
    beyond the edge, the world is indeed round. Thanks for your report on
    You'll note, that on the lame code I provided Mr. Adler, that the boot
    signature is present for the faint of heart, or for the hard hearted

    Now, to the real point of slaying dogma; the result of bochs: If an
    emulator doesn't match the 'real world' in this matter, then how
    confident can one be in its emulation of other 'dark corners'? --
    that is food for thought, and also rhetorical.

    Best regards,

    s_dubrovich, Nov 7, 2007
    1. Advertisements

  3. Allan Adler

    Bob Eager Guest

    Indeed. The argument was really about Mr dBP's rigid insistence that the
    signature was REQUIRED; one justification he gave was a very ambiguous
    Microsoft Knowledge Base article (and Microsoft are always correct,

    Of course, most people would follow the usual course of being rigid in
    what you generate, and lax in what you accept, to avoid problems. Mr dBP
    is incapable of putting this politely, or the argument would not have
    continued. As I stated, I've written a number of bootstraps, and I've
    always included that signature (partly because I've used the same boot
    block, near enough, for all kinds of disks).
    Bob Eager, Nov 7, 2007
  4. As a serious issue, I brought real PC versus emulator testing with Alexei a
    while back for OS development. I indicated that the emulators are likely to
    have errors that real hardware wouldn't. He actually came up with a few
    situations where emulators catch mistakes. IIRC, they had to something to
    do with paging.

    Rod Pemberton
    Rod Pemberton, Nov 8, 2007
  5. I think the real issue with JdBP is logic versus facts. He has numerous
    articles on his website which are rich with detail. You'll notice he picks
    up on incorrect details very easily. But, IMO, he doesn't seem to pick up
    on logical contradictions. Unfortunately, to me, his articles seem to lack
    things other than detail like organization, comprehension, and structure.
    The ones I've looked at are just a big blob of fact after fact.

    How hard would it have been to go through stepwise logic?

    a) Claim: PC's require 0xAA55
    b) Fact: PC's boot DOS with 0xAA55
    c) Fact: PC's boot CP/M without 0xAA55
    d) Result: contradiction, therefore error

    I believe I pick up on logical contradictions quite easily. For example,
    (not to pick on him any more than I already have...) Keith Thompson, posts
    regularly to c.l.c. Over a thread of 250+ posts, he presented numerous
    logical contradictions, in some cases completely reversing his position. I
    found one contradiction in the thread so interesting and odd that I saved
    it. It was the only one unrelated to C:

    In one post:

    "Rule 1: Try not to be offensive.
    Rule 2: Try not to be offended."

    In another post (being offensive...):

    "*Please* don't feed the troll."

    In another post (being offended...):

    "*Please* stop using the insulting term "net nannies". I'm very
    interested in having this discussion with you, but I will cease doing so if
    you continue with the insults."

    So much for: "Try not to be..." What type of person does a 180 on not one,
    but two moral beliefs? in a short time period? Aren't such beliefs a fixed
    part of one's core personality?

    Rod Pemberton
    Rod Pemberton, Nov 8, 2007
  6. Allan Adler

    s_dubrovich Guest

    Your point is well taken. Emulators have their place, I don't mean to
    dismiss them out of hand. And I only need to look at the stock price
    of vmware to recognize their value and market of usefulness.

    On another subject..
    I dug out some of Paul Edwards work, MBR disassembly, I may as well
    list it here to show that the boot signature check is resident in the
    MBR, and not in some rom firmware, AFAIK:
    I've prefaced the pertinent line with '!'.

    ; This is a disassembly of the disk partition table of an MSDOS 5.0
    ; partitioned hard disk. This is located at track 0, head 0, sector 1
    ; which is the first sector loaded by the BIOS, to location 7c00.

    ; The comments were added by Paul Edwards. There is no sign of a
    ; on this program in the partition table, and anyhow disks are bought
    ; pre-partitioned, and even if they weren't, I don't think the output
    ; the "fdisk" command is copyrightable. Also, I've never heard of
    anyone who
    ; bought a blank hard disk being charged with pirating software.

    ; The comments are all mine, and I am releasing them to the public
    ; Contact your lawyer before trying to use the code though!

    cli ; disable interrupts
    xor ax,ax ; set ax = 0
    mov ss,ax ; set ss = 0
    mov sp,7C00 ; set sp = 7c00
    mov si,sp ; set si = 7c00
    push ax ;
    pop es ; set es = 0
    push ax ;
    pop ds ; set ds = 0
    sti ; enable interrupts
    cld ; clear direction flag
    mov di,0600 ; set di = 0600
    mov cx,0100 ; set cx = 0100
    repnz movsw ; mov this 512 byte sector from 7c00 to
    jmp 0000:061D ; jmp continue, in new location
    mov si,07BE ; set si to 07be (disk parameter table)
    mov bl,04 ; set bl to 4
    cmp byte ptr [si], 80H ; if *si == 80 (got valid entry)
    je validate ; then go to partition validation routine
    cmp byte ptr [si], 00H ; if *si != 0
    jne invalid_part ; then go to invalid partition routine
    add si,0010 ; otherwise go to next entry
    dec bl ; count down, max of 4 entries
    jne nextentry ; if not end of table, read next
    int 18 ; jump to rom basic (ie failure)

    ; now that we've found a bootable partion (80) make sure that all
    ; other partitions are set to 00 (not bootable)
    mov dx,[si] ; get first word of DPT in dx
    mov cx,[si+02] ; get second word in cx
    mov bp,si ; save si in bp
    add si,0010 ; go to next DPT entry
    dec bl ; count down
    je process ; if reached end, continue processing, all
    cmp byte ptr [si], 00H ; keep reading entries while they
    je nextzero ; are zero
    ; otherwise fall through to invalid
    partition rtn
    mov si,invp_msg ; "invalid partition table" message
    lodsb ; check that we're not
    cmp al,00 ; at the end of the string
    je infloop ; if we are then go into infinite loop
    push si ; push location of message string
    mov bx,0007 ; set bx to 7 (display page + colour)
    mov ah,0E ; set ah to e (subfunction write text)
    int 10 ; write text function
    pop si ; restore si
    jmp nextch ; print next character
    jmp infloop ; infinite loop

    ; We have a good partition, bp points to the entry,
    ; dx and cx contain first two words
    mov di,0005 ; set di to 5 (number of read attempts)
    mov bx,7C00 ; set bx to 7c00
    mov ax,0201 ; set ax to 0201
    push di ; save di
    int 13 ; read 1 disk sector into 7c00, using
    ; track, sector, head + drive info from DPT
    pop di ; restore di
    jnb readok ; if read was OK, continue
    xor ax,ax ; set ax = 0
    int 13 ; reset the disk
    dec di ; decrease count
    jne readagain ; redo the read
    mov si,loaderr_msg ; set "Error Loading OS" message
    jmp nextch ; print out message
    mov si,missing_msg ; point to "Missing OS" message
    mov di,7DFE ; set di to 7DFE
    ! cmp word ptr [di], 0AA55H ; see if last word is 0AA55
    jne nextch ; if it isn't, print out "missing OS"
    mov si,bp ; set si to point back to DPT entry
    jmp 0000:7C00 ; jump to OS boot sector

    ; so at time the OS boot sector is called, si is pointing to DPT,
    ; and cx and dx contain values suitable for reading from int

    inp_msg db "Invalid partion table", 0
    loaderr_msg db "Error Loading operating system", 0
    missing_msg db "Missing operating system", 0

    ; followed by DPT entries (4)

    Now, for a custom storage solution for a custom OS without a regard
    for partitions allowing other OS's, ....[left to imagination!]

    s_dubrovich, Nov 8, 2007
  7. Allan Adler

    Bob Eager Guest

    Sorry about the delay - it was easiest to scan them but I've only just
    got time.


    for a week or so.
    Bob Eager, Nov 8, 2007
  8. Cool. Thanks for that.

    Rod Pemberton
    Rod Pemberton, Nov 8, 2007
  9. Allan Adler

    Matt Guest

    J de Boyne Pollard wrote:

    To quote yourself:
    A BIOS parameter block is a variant record embedded within the boot
    block (block zero) of a disc volume. It describes the volume's
    filesystem format, and provides various pieces of (filesystem-dependent)
    information about the size and layout of some of the on-disc data
    structures for that filesystem.

    The "BIOS" in "BIOS parameter block" is not a reference to what is
    nowadays commonly referred to as "the BIOS": the machine's firmware. PC
    firmware is wholly ignorant of BIOS parameter blocks.

    Thus are only required for filesystems that require them. They are not
    in any way required by firmware, and thus cannot be important to the
    boot process before the actual boot sector is being executed, which was
    the subject under discussion.

    Firmwares know nothing of FATs, thus they know nothing of BPBs, and
    these are thus redundant UNLESS you have a specific FAT implementation
    that does require them. Not having examined the actual code of every FAT
    filesystem ever written, I cannot be authoritative on the subject, but
    I'm sure that it is not only posible for someone to write a FAT
    implementation based purely on the partition data, but that it has been
    done. The information required to build a FAT filesystem is provided in
    the partition table, as all you need are size and partition type.

    Matt, Nov 8, 2007
  10. Thus are only required for filesystems that require them. They are not
    On floppy - not so. Firmware needs to read the BPB to determine the floppy
    Maxim S. Shatskih, Nov 8, 2007
  11. Allan Adler

    Bob Eager Guest

    Why does it need to know the size? It's reading the first sector - which
    is always - well - the first sector.

    Proof please. If there is some, I'd be interested (in a good way...I'm
    not being awkward).

    (aside...once again, in practice it's a good idea to have a BPB. El
    Torito will write values into a BPB to indicate disk parameters, so if
    you didn't have a BPB you'd still need to leave space for the parts that
    get overwritten).
    Bob Eager, Nov 8, 2007
  12. On floppy - not so. Firmware needs to read the BPB to determine the floppy
    Yes, the first sector can be read even without the knowledge on diskette's
    SectorsPerTrack and Tracks, but, to access the whole diskette, the controller
    must be set up in a proper way, and this requires knowing SectorsPerTrack and
    Tracks from some source. This source is BPB.
    Try looking at Linux or Windows source (the Windows floppy driver source is
    provided in the DDK).

    Also - remember the 800.com resident app of early 90ies? It allowed
    non-standard floppy formats. So, the same floppy media can be formatted several
    ways, and thus the format information should be kept somewhere on the media

    It is kept in the BPB.
    Maxim S. Shatskih, Nov 8, 2007
  13. Allan Adler

    Matt Guest

    But as such is part of the filesystem, not the booting process. Another
    block containing the relevant information, stored elsewhere on the disc,
    would work equally well, as long as the filesystem in question was
    designed to find it.

    Matt, Nov 8, 2007
  14. Allan Adler

    Bob Eager Guest

    But to access the rest of the diskette, code is executed from the
    diskette itself. The 'firmware' needs knowledge only of how to get that
    first sector. The code then feeds the 'firmware' C/H/S values, and it
    blindly accesses those. It needs no innate knowledge of the diskette
    size at all, apart from what it already has (e.g. it will already know
    whether the diskette is DD, HD or ED, from the sensor hole's presence
    and/or position). That will be enough to set data rate, etc. without
    reading the diskette at all. It doesn't need to know maximum
    sector/track numbers.
    No, that merely shows what is commonly done. That is for the convenience
    of the boot code, not for the 'firmware'.
    But only if you need to access it from something that doesn't already
    know. 800.com was there specifically for DOS/Windows, so of course it
    needed it. But I might have an operating system that formatted all
    diskettes a strange way. It wouldn't matter if theer was a NPB or not,
    since only my operating system would nedd to read them, and it would

    But that's off the point. The 'firmware' needs no knowledge of the disk,
    except how to read the first sector; in particular it doesn't need to
    know its size. The boot code, read from that sector, has all the
    information it needs to ask the 'firmware' to read specific cylinders,
    heads and sectors.
    Bob Eager, Nov 8, 2007
  15. Not quite sure whether you're being serious or sarcastic, Steve...
    serious, I think...

    No comment on the lameness! But I think we're agreed then.

    A spec is only as useful as its implementations.

    I think any emulator can only ever be a "best effort". To be perfect, it
    would have to be the actual target hardware... hardly the point of an
    emulator. Bochs is extraordinarily useful, and a credit to its producers.

    Maybe it's wrong to refuse to boot my signature-less floppy, but I'd be
    wrong too for expecting it to be 100% perfect. Or maybe it's right to
    implement whatever specs. Or maybe this is the real world and it's nice to
    have my attention drawn to a grey area in my boot sector.
    Ciaran Keating, Nov 8, 2007
  16. No. It's not a BPB. It's a BP...no...a DP...no...well it's a structure at
    DOS (etc.) - DOS BPB (Bios Parameter Block)
    GRUB - GRUB BPB (Bios Parameter Block)
    LILO - BDP (Boot Device Parameters)
    CP/M - DPB (Disk Parameter Block)


    Rod Pemberton
    Rod Pemberton, Nov 9, 2007
  17. Maxim S. Shatskih wrote:
    A KESYS boot-record is quite different to the M$-layout, but I never
    had any problem to boot my stuff from FD, HD or CD.

    Last time I checked on my BIOSes they all determine FD-size at boot
    just by trying (2.88/1.44/720/360; the typical noise) and load only
    the first 512 bytes to 7c00h regardless if the FD is formatted with
    ie: 4Kb sectors (as long sectors aren't smaller than 512 bytes).

    The idea that the BIOS interpretes a boot-record and the name
    'BIOS-parameter-block' may come from early (XT)IBM PCs ?

    OTOH my new machines haven't even got any FD-connector,
    so what ... :)

    Wolfgang Kern, Nov 9, 2007
  18. Allan Adler

    s_dubrovich Guest

    Genuinely sincere.
    It's the last sentence for me..grey matter drawn to grey areas in a
    dance of poetic base2 interlude.

    s_dubrovich, Nov 9, 2007
  19. Allan Adler

    Bob Eager Guest

    Are you sure that isn't just the ROM BIOS seek test?
    The XT's ROM BIOS boot code was painfully simple. It did all it should
    do...read the boot sector and transfer control to it.

    STI ; enable interrupts
    SUB AX,AX ; establish addressing
    ; Reset the disk parameter table vector
    ; Load system from diskette. CX is used as the retry count.
    MOV CX,4 ; retry count
    H1: ; IPL_SYSTEM
    PUSH CX ; save retry count
    MOV AH,0 ; reset the diskette system
    INT 13H ; diskette handler
    JC H2 ; j if error
    MOV AX,0201H ; read in the single sector...
    SUB DX,DX ; ...to the boot location
    MOV CX,1 ; drive 0, head 0, sector 1,
    track 0
    INT 13H


    POP CX ; recover retry count

    JNC H4 ; j if read OK

    LOOP H1 ; else do possible retry


    ; Retries exhausted; enter ROM BASIC



    INT 18H ; go to resident BASIC


    ; Read successful; enter system bootstrap





    That's it!
    Bob Eager, Nov 9, 2007
  20. Bob Eager replied:
    In addition to that you could hear which type of FD were inserted.
    [snipped copy of the well known boot-code]
    Sure this old boot image will work also today, but the point
    was about how the BIOS determines FD-size and format ...
    When the BIOS can read a sector then it for sure know already!
    and "that's" what I meant :)

    Wolfgang Kern, Nov 9, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.