OSDev.org

http://my.execpc.com/~geezer/temp/mbload.zip

It boots OSD and Neural DK with apparent success, as
well as a graphical Multiboot test kernel that I wrote:
http://my.execpc.com/~geezer/temp/mbtest.zip

I had lesser success with these kernels:
- Mobius booted to its kernel debugger because it couldn't
find the shell
- TabOS booted, but froze up while trying to load the
keyboard translation table
- Wild Magnolia booted, then immediately displayed a blue-and-
white page fault screen. I was able to use the Esc key to
select different screens.

Try it with your own kernel and let me know if it works or not.
If it doesn't work, please try booting the graphical Multiboot
test kernel before sending an error report. This will help
narrow down the cause of the problem.

Not all fields of the Multiboot system information structure
are filled out. In particular, MBLOAD-C does not set the
kernel and module command lines, the root device, or the
hard drive information fields. Also, GZIP compression is not
yet supported.

Works for me - which is to be expected since my kernel currently does little else but printing the data from the Multiboot Data Structure to screen.

One thing though: MBLOAD leaves the unsupported data fields uninitialized, relying on the kernel to evaluate the FLAGS field properly. Perhaps it would be a good idea to initialize the unsupported fields to "safe" values (i.e., zero). If a dumb kernel (like mine ) just reads e.g. the CMDLINE field without heeding the FLAGS, things can get ugly...

Very cool! However, I can reproduce this behaviour with current Mobius builds. I'll check later exactly why it's failing to find any multiboot modules. Also, the ability to parse GRUB config files would be nice, as I'm coming up against DOS's command line limit.

Good work!

Oops, there was a bug in the code that displays BIOS memory ranges (damn last-minute changes). You can re-download the .ZIP file, or find the definition of mboot_range_t in MBLOAD.C, and change the 'type' field from

   uint32_t type      __PACKED__;

to

   uint16_t type, res_type   __PACKED__;

OK, Mobius isn't booting because it can't find its config file, which is stored as a multiboot module. The actual data seems to be there, but the string is coming out as zero length; i.e. the only character stored at the string address is a nul. Following that nul it looks like there's a couple of strings from the MBLOAD program itself -- I'd like to include the text, but copying from Bochs has stopped working.

MBLOAD zeroes the 'string' field of the Multiboot module structure:
GRUB puts a pointer to the module command-line in this field. Do Mobius modules need the command line?

I changed the copy_high() function to copy_linear(), which
can now copy between any two linear addresses; to or from
extended memory. After loading everything, I then copied the first 4096 bytes of the first module (system.pro) down to
conventional memory and dumped it. Everything looked OK.

I did this testing without an XMS driver present. Did you try running MBLOAD without HIMEM.SYS loaded? If XMS is present, the initial load address of the kernel and modules is not usually the final load address. I have to copy everything to its correct place, which is tricky and may not work properly. Since this copying will most likely trash DOS (by overwriting the High Memory Area), I do it just before entering pmode.

The version of Mobius I'm using is the old diskette image
on your website. You posted an URL to a newer diskette image
in the "Testing OS reports" thread, but that's now 404.

Which version of MS-DOS or FreeDOS are you using?

Thanks

Tim Robinson wrote: but copying from Bochs has stopped working.

If you use Ctrl+C to stop the simulation, copy won't work. Bochs must actually be running for the Copy button to function. Also, it sometimes seems to put junk into the Windows clipboard. Try pasting into different programs, e.g. Notepad and Wordpad.

Version 0.45 is now up:
http://my.execpc.com/~geezer/temp/mbload.zip

This version sets the kernel and module command lines to the full pathname of the files, with GRUB-style device names, e.g. (hd0,0)/my-os/bin/kernel.exe
Alas, it does not yet support the GRUB config file (menu.lst) or menu. I'll keep working on it.

There was also a palette bug in the graphical Multiboot test kernel, which I've fixed:
http://my.execpc.com/~geezer/temp/mbtest.zip

OK, I tried MBLOAD with Mobius again. Mobius now puts most of its modules in a single .tar.gz file, which makes the MBLOAD command line shorter. But I can't expect it to boot fully unless MBLOAD unzips .gz files automatically like GRUB does.

Anyway, I tried MBLOAD on FreeDOS under Virtual PC, and after the memory info it said:
[tt]init_drives: DRIVER.SYS not present[/tt]
I have an empty AUTOEXEC.BAT and no CONFIG.SYS. Not sure what DRIVER.SYS is.

So -- I'm no closer to booting Mobius with MBLOAD.

Hi Tim. Thanks for trying out my code.

I use DRIVER.SYS -- specifically INT 2Fh AX=0803h -- to map DOS drive letters to INT 13h drive numbers. According to Ralf Brown's list, the functionality of DRIVER.SYS has been built-in to MS-DOS since version 3.2. Though FreeDOS doesn't appear to support this, it looks like I can use INT 21h AX=440Dh CX=0860h instead, so this much should be easy to fix.

GZIP decompression will take a bit longer. It's more complex
than either LZW or LZSS decompression. Mark Adler put INFLATE.C into the public domain, so I'll try adapting his code.

doesnt the zlib support all this?? or can you not link it in as a license issue or something?

MB boots my kernel just find. Thanks for the excellent work.

I would be nice, however, if there was a version that didn't require DOS (sorry, I don't like GRUB's GPL license)

Thanks again Chris!

2.5 years ald thread

You looked at a program designed to load OSes from within DOS and said it would be nice if it didn't require DOS... that was kinda the point you know...

kemp, I'm sure it would be simpler to make MBLOAD work without DOS than to make GRUB non-GPL...

I would like an "embeddable" version of MBLOAD too.

tory wrote: kemp, I'm sure it would be simpler to make MBLOAD work without DOS than to make GRUB non-GPL...

I would like an "embeddable" version of MBLOAD too.

you're welcome to try, though i doubt it'll be as easy as you think to get it working (filesystem ? memory reporting ?)

[me=Pype.Clicker]is simply happy with GRUB oh ... maybe i could just make use of 16 bits programs loaded, writing results in memory that 32 bit kernel could reuse later ... [/me]