Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #8230 > unrolled thread

BootProg released

Back to article view | Back to alt.os.development

Contents

  BootProg released "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-06-21 22:52 -0700
    Re: BootProg released "James Harris" <james.harris.1@gmail.com> - 2015-06-22 14:12 +0100
      The BIOS Drive ID urban legend "Mike Gonta" <mikegonta@gmail.com> - 2015-06-24 17:49 -0400
        Re: The BIOS Drive ID urban legend (was: BootProg released) "James Harris" <james.harris.1@gmail.com> - 2015-07-01 10:44 +0100
      Re: BootProg released "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-06-25 21:08 -0700
        Re: BootProg released "James Harris" <james.harris.1@gmail.com> - 2015-07-01 11:02 +0100
          Re: BootProg released "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-04 05:18 -0700
          Re: BootProg released "Kerr Mudd-John" <admin@127.0.0.1> - 2015-07-05 19:11 +0100
            Re: BootProg released "Kerr Mudd-John" <admin@127.0.0.1> - 2015-07-06 10:52 +0100
              Re: BootProg released "James Harris" <james.harris.1@gmail.com> - 2015-07-06 21:42 +0100

#8230 — BootProg released

----8<----
The "BootProg" Boot Sector


What is BootProg?

BootProg is a collection of 512-byte boot sectors (for the x86 PC) capable of
loading and executing a program from a FAT12-formatted floppy or a FAT16/32-
formatted hard disk (bootable USB sticks and CDs can also be made with
BootProg).

BootProg understands programs in the MS-DOS .COM or .EXE format. This makes
it possible to use existing 16-bit compilers such as Borland/Turbo C/C++,
Sybase/Open Watcom C/C++ and Smaller C and a variety of assemblers such as
NASM, FASM, TASM and MASM among the others.

BootProg doesn't require that the program occupy a contiguous span of sectors
or FAT clusters or reside at a specific fixed location on the disk. BootProg
faithfully parses the root directory and the chain of FAT clusters in order to
locate the program contents. The only requirement is that the program be named
"STARTUP.BIN" (without quotes). This makes updating the program easy. You just
need to update the file and you can reboot and execute it immediately.


What can BootProg be used for?

You can make a boot loader for your OS. The program that BootProg loads can be
your 2nd stage boot loader. Or, if your OS is relatively small, STARTUP.BIN
could contain the entire OS.

You can write low-level utilities to work with your PC's hardware and load them
with BootProg without having to jump through the hoops with your Windows, Linux
or even DOS.

You can make cool graphics demos or games that run on bare hardware.
...
----8<----

Finally, I made a BSD-licensed version of all the FAT12/16/32 versions of this boot sector, cleaned up code comments and threw in a utility to make floppy images (ready for VMs or for dd'ing onto physical floppies) with this (or another) boot sector and any files of choice.

https://github.com/alexfru/BootProg

Enjoy!

[toc] | [next] | [standalone]

#8235

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:8029ab57-0054-4410-aba8-d5189f025db7@googlegroups.com...

...

>BootProg doesn't require that the program occupy a contiguous span of 
>sectors
>or FAT clusters or reside at a specific fixed location on the disk. 
>BootProg
>faithfully parses the root directory and the chain of FAT clusters in 
>order to
>locate the program contents. The only requirement is that the program 
>be named
>"STARTUP.BIN" (without quotes). This makes updating the program easy. 
>You just
>need to update the file and you can reboot and execute it immediately.

Great job, Alex. I chose to do the same thing years ago so that the boot 
code didn't need to be written to special sectors etc. IMO following 
file system structures is a much better idea. At least it makes updates 
much easier. I only wrote a FAT12 version because that was all I needed 
at the time but I see you have added FAT16 and FAT32.

Mine is at

  http://codejar.pldev.org/aen/fatbootsect.nasm

As I say it was years ago when I wrote it and I only just managed to 
shoehorn everything into 512 bytes without even one byte spare. I think 
if I ever revisit it I might be able to make it a bit smaller, given 
that I now know more about assembly language than I did then, and if 
there is space add some features.

It is especially good that yours can load and relocate a .EXE format. 
Can that be over 64k, and what size can it go up to?

Why did you load the whole of the root directory? I only loaded as many 
sectors as it took to find the target file name.

What CPU does your code require? And what does it report if booted on an 
older CPU? You know my preferences on this. ;-)

FYI, int 0x19 won't always continue the boot. Nor will it always reboot. 
From my tests BIOSes differ.

Some BIOSes reportedly don't correctly pass the boot drive id in DL. Any 
idea how to cope with that? And, no, I don't handle it either.

James

[toc] | [prev] | [next] | [standalone]

#8246 — The BIOS Drive ID urban legend

"James Harris" wrote:

> Some BIOSes reportedly don't correctly pass the boot drive id
> in DL.

That is an "urban legend".

Some people probably observed that even recent MS boot loaders
don't use the BIOS returned "DL" but rather rely on the BPB
Drive ID. They probably inferred from this that the BIOS Drive
ID could not be relied upon. (This, in itself led to a lot of
USB booting difficulties for a lot of people and resulted in
the MBR urban legend).

The fact is that early MS-DOS ran on computers (before and
during the early IBM PC era) that had no BIOS. CP/M, 86DOS and
early MS-DOS came with OEM supplied BIOS on disk. The machine
itself only had minimal firmware code to load one specific
sector to a specific address and jump to it. That "boot sector"
then loaded some or all of the "BIOS" file. Even with the
latest version (Win98) io.sys, only four sectors were loaded.
io.sys then loaded the rest itself.

So, at that time, there was no Drive ID and of course only one
floppy drive attached to the computer - so not much need to
identify it. Backwards compatibility being the hallmark of MS.


Mike Gonta
look and see - many look but few see

http://mikegonta.com

[toc] | [prev] | [next] | [standalone]

#8257 — Re: The BIOS Drive ID urban legend (was: BootProg released)

"Mike Gonta" <mikegonta@gmail.com> wrote in message 
news:mmf8m0$tm3$1@speranza.aioe.org...
> "James Harris" wrote:
>
>> Some BIOSes reportedly don't correctly pass the boot drive id
>> in DL.
>
> That is an "urban legend".

That would be very welcome, if true. But how do you know that it being 
an urban legend is not itself an urban legend? For example, SYSLINUX 
includes code to support machines which fail to pass the boot drive in 
DL. Are you saying that such code is pointless? If so why was it 
included?

> Some people probably observed that even recent MS boot loaders
> don't use the BIOS returned "DL" but rather rely on the BPB
> Drive ID.

Interesting. From the few releavant hard disk tests I have run I have 
seen the BIOS assign 0x80 to the boot drive regardless of which disk it 
booted from.

> They probably inferred from this that the BIOS Drive
> ID could not be relied upon. (This, in itself led to a lot of
> USB booting difficulties for a lot of people and resulted in
> the MBR urban legend).

I suspected that the problem was buggy old BIOSes rather than anything 
new - but that was purely because newer BIOSes would/should have fixed 
such bugs.

> The fact is that early MS-DOS ran on computers (before and
> during the early IBM PC era) that had no BIOS. CP/M, 86DOS and
> early MS-DOS came with OEM supplied BIOS on disk. The machine
> itself only had minimal firmware code to load one specific
> sector to a specific address and jump to it. That "boot sector"
> then loaded some or all of the "BIOS" file.

OK. That could be the issue.

> Even with the
> latest version (Win98) io.sys, only four sectors were loaded.
> io.sys then loaded the rest itself.
>
> So, at that time, there was no Drive ID and of course only one
> floppy drive attached to the computer - so not much need to
> identify it. Backwards compatibility being the hallmark of MS.

OK.

James

[toc] | [prev] | [next] | [standalone]

#8250

On Monday, June 22, 2015 at 6:12:45 AM UTC-7, James Harris wrote:
> "Alexei A. Frounze" <...@gmail.com> wrote in message 
> news:8029ab57-0054-4410-aba8-d5189f025db7@googlegroups.com...
> 
> ...
> 
> What CPU does your code require? And what does it report if booted on an 
> older CPU? You know my preferences on this. ;-)

Jim Leonard (the author of the 8088 Corruption, 8088 Domination and
8088 MPH) has recently expressed interest in making an 8086/8088 version
and it looks like the FAT12 variant can be made 8086/8088-compatible
(perhaps, with a few minor features removed). :)

Alex

[toc] | [prev] | [next] | [standalone]

#8258

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:ca5622b0-3742-49d5-a136-a6af5b808d9c@googlegroups.com...
> On Monday, June 22, 2015 at 6:12:45 AM UTC-7, James Harris wrote:
>> "Alexei A. Frounze" <...@gmail.com> wrote in message
>> news:8029ab57-0054-4410-aba8-d5189f025db7@googlegroups.com...
>>
>> ...
>>
>> What CPU does your code require? And what does it report if booted on 
>> an
>> older CPU? You know my preferences on this. ;-)
>
> Jim Leonard (the author of the 8088 Corruption, 8088 Domination and
> 8088 MPH) has recently expressed interest in making an 8086/8088 
> version
> and it looks like the FAT12 variant can be made 8086/8088-compatible
> (perhaps, with a few minor features removed). :)

I have looked up Jim Leonard's work that you mentioned. I had heard the 
name but was not familiar with it before. Very impressive!

My own fat boot sector is pure 8086 code. As it is intended for starting 
an OS I made a number of choices for reliability:

* It carries out quite a lot of checks of diskette geometry before it 
starts - e.g. to ensure that the values are such that mutlibyte 
arithmetic won't overflow.

* It sticks to 8086 code so that it cannot simply fail without issuing 
an explanation as to why it has failed.

* It prints progress info largely so that if something goes wrong (bad 
sector, file not found, bad disk setup) the user can see where the error 
occurred.

As OS developers often like to do things themselves I chose to have the 
boot sector do nothing more than load the next file. The loaded file 
starts with there having been no mode changes, no A20 changes, and no 
checks carried out other than those which were necessary to ensure that 
the load completes or reports. The loaded file is effectively just 
another boot 'sector' but larger.

Things I would like to add if I can make space:

* Further reports, especially retries of reads so the user can see if a 
read fails once or twice and then works.

* Move code so that the loaded file can start at 0x7c00.

* Read the graphics card current page rather than just forcing it to 
zero.

Given your comments about FAT32 needing most space I may wait until I 
have a FAT32 version working before I try to add any extras, so that all 
three versions can be the same.

James

[toc] | [prev] | [next] | [standalone]

#8293

On Wednesday, July 1, 2015 at 3:02:18 AM UTC-7, James Harris wrote:
...
> My own fat boot sector is pure 8086 code. As it is intended for starting 
> an OS I made a number of choices for reliability:
> 
> * It carries out quite a lot of checks of diskette geometry before it 
> starts - e.g. to ensure that the values are such that mutlibyte 
> arithmetic won't overflow.

Unless I made a mistake in mine, it should handle all sane values.
For anything more rigorous, you need a special tool to check the FS,
which is not the boot sector's job.

> * It sticks to 8086 code so that it cannot simply fail without issuing 
> an explanation as to why it has failed.
> 
> * It prints progress info largely so that if something goes wrong (bad 
> sector, file not found, bad disk setup) the user can see where the error 
> occurred.

That's all nice.

> As OS developers often like to do things themselves I chose to have the 
> boot sector do nothing more than load the next file. The loaded file 
> starts with there having been no mode changes, no A20 changes, and no 
> checks carried out other than those which were necessary to ensure that 
> the load completes or reports. The loaded file is effectively just 
> another boot 'sector' but larger.

Understandable.

> Things I would like to add if I can make space:
> 
> * Further reports, especially retries of reads so the user can see if a 
> read fails once or twice and then works.

Nice to have. Btw, if multiple read attempts fail, you may probably
notice the difference in the sounds produced by the floppy drive.
Drive resets can cause moves to cylinder 0. And seeks to the next
cylinders won't occur.

> * Move code so that the loaded file can start at 0x7c00.
> 
> * Read the graphics card current page rather than just forcing it to 
> zero.

Why would it be anything but page 0 at boot time?

> Given your comments about FAT32 needing most space I may wait until I 
> have a FAT32 version working before I try to add any extras, so that all 
> three versions can be the same.

It may be impossible. Especially, if your BIOS doesn't support function
42h on int 13h and/or you stick to 8086 code. I think, there's no good
reason to try to use FAT32 on systems older than those supporting
Windows 9x.

Alex

[toc] | [prev] | [next] | [standalone]

#8300

On Wed, 01 Jul 2015 11:02:17 +0100, James Harris  
<james.harris.1@gmail.com> wrote:

> "Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message  
> news:ca5622b0-3742-49d5-a136-a6af5b808d9c@googlegroups.com...
>> On Monday, June 22, 2015 at 6:12:45 AM UTC-7, James Harris wrote:
>>> "Alexei A. Frounze" <...@gmail.com> wrote in message
>>> news:8029ab57-0054-4410-aba8-d5189f025db7@googlegroups.com...
>>>
>>> ...
>>>
>>> What CPU does your code require? And what does it report if booted on  
>>> an
>>> older CPU? You know my preferences on this. ;-)
>>
>> Jim Leonard (the author of the 8088 Corruption, 8088 Domination and
>> 8088 MPH) has recently expressed interest in making an 8086/8088 version
>> and it looks like the FAT12 variant can be made 8086/8088-compatible
>> (perhaps, with a few minor features removed). :)

It's just the pusha and popa that aren't available, AFAICT.

>
> I have looked up Jim Leonard's work that you mentioned. I had heard the  
> name but was not familiar with it before. Very impressive!
>
> My own fat boot sector is pure 8086 code. As it is intended for starting  
> an OS I made a number of choices for reliability:
>
> * It carries out quite a lot of checks of diskette geometry before it  
> starts - e.g. to ensure that the values are such that mutlibyte  
> arithmetic won't overflow.
>
> * It sticks to 8086 code so that it cannot simply fail without issuing  
> an explanation as to why it has failed.
>
> * It prints progress info largely so that if something goes wrong (bad  
> sector, file not found, bad disk setup) the user can see where the error  
> occurred.
>
> As OS developers often like to do things themselves I chose to have the  
> boot sector do nothing more than load the next file. The loaded file  
> starts with there having been no mode changes, no A20 changes, and no  
> checks carried out other than those which were necessary to ensure that  
> the load completes or reports. The loaded file is effectively just  
> another boot 'sector' but larger.
>
> Things I would like to add if I can make space:
>
> * Further reports, especially retries of reads so the user can see if a  
> read fails once or twice and then works.
>
> * Move code so that the loaded file can start at 0x7c00.
>
I still don't get why this has to be; just because MS coded it that way.


> * Read the graphics card current page rather than just forcing it to  
> zero.
>
seems if you're cold booting there shouldn't be any question as to any  
previous page.

> Given your comments about FAT32 needing most space I may wait until I  
> have a FAT32 version working before I try to add any extras, so that all  
> three versions can be the same.
>
> James
>

Didn't we have a compo to create minimal code for a boot sector not so  
long ago?



-- 
Bah, and indeed, Humbug

[toc] | [prev] | [next] | [standalone]

#8307

On Sun, 05 Jul 2015 21:44:31 +0100, James Harris  
<james.harris.1@gmail.com> wrote:

> "Kerr Mudd-John" <admin@127.0.0.1> wrote in message  
> news:op.x1bbg12dmsr2db@dell3100.workgroup...
>> On Wed, 01 Jul 2015 11:02:17 +0100, James Harris  
>> <james.harris.1@gmail.com> wrote:
>
> ...
>
>>> Things I would like to add if I can make space:
>
> ...
>
>>> * Move code so that the loaded file can start at 0x7c00.
>>>
>> I still don't get why this has to be; just because MS coded it that way.
>
> MS didn't write the BIOS.
>
> I found the following. It explains in some detail why 0x7c00 was chosen.  
> I don't know whether it is correct or not but it sounds valid and makes  
> an interesting read: basically that the lowest practical amount of RAM  
> that the original IBM PC could run IBM DOS 1.0 on was 32k so they chose  
> the 31k point (i.e. 0x7c00).
>
>   http://www.glamenv-septzen.net/en/view/6
>
> That ties in with Wikipedia. Apparently the earliest IBM PC has memory  
> options of between 16k and 256k.
>
>   https://en.wikipedia.org/wiki/IBM_Personal_Computer
>
> James
>

OK. But we don't need to be so constrained nowadays (says he still coding  
for 8086)


-- 
Bah, and indeed, Humbug

[toc] | [prev] | [next] | [standalone]

#8309

"Kerr Mudd-John" <admin@127.0.0.1> wrote in message 
news:op.x1ci1fsamsr2db@dell3100.workgroup...
> On Sun, 05 Jul 2015 21:44:31 +0100, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Kerr Mudd-John" <admin@127.0.0.1> wrote in message 
>> news:op.x1bbg12dmsr2db@dell3100.workgroup...
>>> On Wed, 01 Jul 2015 11:02:17 +0100, James Harris 
>>> <james.harris.1@gmail.com> wrote:

...

>>>> * Move code so that the loaded file can start at 0x7c00.

...

>> I found the following. It explains in some detail why 0x7c00 was 
>> chosen.  I don't know whether it is correct or not but it sounds 
>> valid and makes  an interesting read: basically that the lowest 
>> practical amount of RAM  that the original IBM PC could run IBM DOS 
>> 1.0 on was 32k so they chose  the 31k point (i.e. 0x7c00).
>>
>>   http://www.glamenv-septzen.net/en/view/6

...

> OK. But we don't need to be so constrained nowadays

7c00 is a bit of a de-facto standard. Apart from the BIOS loading floppy 
and hard disk boot sectors there it is used in other contexts too. The 
Microsoft MBR copies itself to 0x600 and loads a VBR to 0x7c00. And PXE 
bootroms I have used load their targets to 0x7c00. And some loaded boot 
code *expects* to have been loaded to that address.

But having read over the linked page above ISTM better to ignore it 
unless need dictates otherwise.

My FAT boot sector currently loads its target to 0x1_0000, i.e. 64k and 
it loads up to the first 64k of that file.

I may one day change the FAT boot sector to load to 0x8000, i.e. 32k. 
Not sure.

James

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.development

csiph-web