OSDev.org

Hmm, though looking at the disassembly: I'm going to say that it's 16-bit code. Evidenced by the stray data16. If it were disassembled as 16-bit code, that would be correct.

Which means the disassembly you've listed is wrong, as it's out of sync with the actual code

Why are you looking at some disassembly when you could just check source code?

Well, according to http://www.ptb.de/ntp/ntp.cgi it's 00:59 CET, that's 23:59 UTC.

http://xanclic.bplaced.net/quok.tar.bz2

PS: No, I didn't meet the requirement to load the file in RM. And I also don't know if I met the other requirements.

Ok, I hope this works

Notes:

- It loads ELF at 060h:0 them moves it to linked address and jumps to e_entry in real mode (e_entry/16):(e_entry mod 16)
- If ELF is linked at 40000h you should be able to boot up to 250k file sizes
- Automatic CHS / LBA detection: boot floppy or any partition under 2Tb
- Obviously automatic runtime detection of FAT-12 / FAT-16 file systems
- Acceptable Sector sizes are 512, 1024, 2048, 4096, and 8192 bytes
- As a bonus if you link 'MZ' executable it will load it at 60h:0 and jump to 60h:200h
This lets you have up to 626k boot file. (memory overruns are checked)

Edit: fixed bug in the initial version

fronty wrote:Why are you looking at some disassembly when you could just check source code?

.. because I'm not so bsd-savvy ??

Thanks for the pointer though... very instructive
Now, after reviewing the said source code, I can confirm that the openbsd boot ELF file (32 bit) effectively contains a litlle 16-bit bootstrap part (entry point),
that switches to pmode and gives execution to the rest of the 32-bit code.

One interesting thing I found via the pointer you gave, is the 'biosboot' source code,

http://www.openbsd.org/cgi-bin/cvsweb/s ... S?rev=1.40

whose comments show how comparable it is to the goals of this contest,
except :
-apparently the file system used is not FAT1X but rather UFS (bsd standard ??) with inodes, direct block table, etc...
-many parameters are {hard coded/patched at install} in the boot loader (inodeblk, inodedbl, fs_bsize_p, etc...) whereas in this contest, we must compute them at run time

In particular :
* We would have liked biosboot to go from the superblock to
* the root directory to the inode for /boot, thence to read
* its blocks into memory.
*
* As code and data space is quite tight in the 512-byte
* partition boot sector, we instead get installboot to pass
* us some pre-processed fields.
hehe..
If somebody ever reaches the contest's goal, we won't need any installboot or any boot sector patcher anymore...

Since I failed to mention CPU state at all in the original rules, I decided that booting in to either real mode or protected mode will be allowed. I have modified my tests accordingly. Just mention if your entry wants real mode or protected mode. I'll offer a prize for a real mode entry and a prize for a protected mode entry.

@quok:

concerning the real/protected mode bootstrap mode ambiguity, perhaps it would have been wise to
expect the boot loader to start the OSLOADER in realmode *by default* (as it is the case for a legacy x86 cpu at power up), except
if this particular OSLOADER file is *multiboot* compliant ?

http://www.gnu.org/software/grub/manual ... iboot.html

=> in this case, we should boot it in 32 bit protected mode..

This way, such a designed bootloader would be :
-able to boot either of them with recompiling or run time options
-able to boot the (16 bit bootstrap) openbsd 'boot' (as advertised)
-even cooler

just my .02

a427 wrote:@quok:

concerning the real/protected mode bootstrap mode ambiguity, perhaps it would have been wise to
expect the boot loader to start the OSLOADER in realmode *by default* (as it is the case for a legacy x86 cpu at power up), except
if this particular OSLOADER file is *multiboot* compliant ?

http://www.gnu.org/software/grub/manual ... iboot.html

=> in this case, we should boot it in 32 bit protected mode..

This way, such a designed bootloader would be :
-able to boot either of them with recompiling or run time options
-able to boot the (16 bit bootstrap) openbsd 'boot' (as advertised)
-even cooler

just my .02

Actually, my osloader is of course a 32-bit ELF file and it does expect to be started from real mode. The ELF entry point is that 16-bit code. It just sets up a protected mode environment and jumps some C code. There's also a multiboot header which utilizes the a.out kludge to specify a different entry point for multiboot-compliant loaders. This entry point just copies the loader to low memory where it expects to be, then sets up the same protected mode environment and then jumps to the same C code. For the purposes of this contest I just #ifdef out the real-mode code and change the entry point in the linker script for the protected mode version of the loader. I don't expect anyone to write a bootsector that can run both the real mode and protected mode versions except perhaps with different compile-time options.

Well, since my entry didn't work on the mentioned 486 laptop, I changed it a bit and here's the new one. I hope this will work at least as well as the last did.

Well, this entry lacks a feature the before had: It doesn't enable the A20 line anymore.

Well, here it is: http://xanclic.bplaced.net/quok-v2.tar.bz2

Hope it works, though I don't think so.

This is improved version of the boot loader:

- It now can boot ELF files up to 512k in size.
- Boot 'MZ' and flat binaries up to 626k in size.
- Boot Windows 98's IO.SYS anywhere under 2Tb.
- Boot FreeDOS's kernel.sys
- User configurable boot file name (via volume label).

- Variable Sector Size (512, 1k, 2k, 4k), FAT-12 / FAT-16, and CHS/LBA are all detectable at runtime.

Please, give it a good testing on various hardware, because I have only tried it on two PCs and emulators.
If somebody has access to floppies with sector size other than 512 bytes testing will be greatly appreciated.

Thanks,
technik3k

Edit: fixed bug testing for bad cluster #