OSDev.org

I am trying write a simple bootloader, and I want to show an image when my bootloader starts. How can I do this?

I am using assembly with nasm assembler.

Learn the format of the image you are using, and write an image parser in assembly to display it. I recommend gif of no larger than 320x200 because you can render that perfectly on mode 13h.

or 640x480 16-color.
and it has to fit in memory

hm, can you show me example please ?

Not really, its far too in depth to simply copy and paste a few lines. It's going to take a few hundred lines of code to display a gif, and you'll have to understand the pallette registers, the format of mode 13h, and the gif format including LZ compression used to make the file smaller. You will also know enough BIOS interrupts to read the file from the filesystem, and you will actually need a filesystem (failing that you could embed the image in your bootloader, making it much larger). I suggest you read up on the GIF format, and go from there.

I did this many years ago, and also the ancient PCX format which can be a little easier. It's worth it but not trivial.

For a real world of hurt, try implementing jpeg without libjpeg or such. That is naaaasty.

If the image is about 256 pixels or less (16x16), you can embed the raw data in your bootloader, and switch to mode 13 through bios, and simply copy the lines to correct offsets - don't forget to skip over pixels!

As mentioned, you need to parse the format of an image and render it.

That's not easy at all from a general view point, but perfectly possible.

Try starting off with this: http://en.wikipedia.org/wiki/Graphics_I ... ile_format

And assuming you know Assembly you need to program using it. Hopefully you're at least somewhat good at it, otherwise you'll need to go through more trouble optimizing a high-level-language.

You'll also likely have to store the file somewhere (a filesystem), which will also not be easy.

You should both work on the previous mentioned subjects, and try and get a better understanding of what's necessary and effective to get this done right.

You could also just write directly to video memory without an image file being loaded from a storage drive and write pixel-by-pixel in graphics mode (like 13h mentioned before), but that can be even more tedious depending on the purpose.

EXTRA:

The answers to this question, and the links given might also help you out with your problem:

http://stackoverflow.com/questions/1420 ... es#tab-top

If you think GIF is too much of a hassle for something as small as a splash screen, you might want to look into PCX, which has a simple format and uses LRE compression. You can be done with it in a matter of minutes.

I love dead threads.

How about zombie processes?

I don't know, that's on wikipedia

Why GIF ? Just use raw data or something close to it, like bitmaps. BIOS interrupts are not that hard once you got Ralf Brown's interrupt list, or their corresponding articles on the wiki. Your bootloader doesn't need to be in assembly, I tell it by experience, and as a proof, GRUB is mostly written in C.

AbstractYouShudNow wrote:Why GIF ? Just use raw data or something close to it, like bitmaps.

Raw bitmap at 320x200x8 is almost 64 KB. 320x200x8 GIF is much smaller. PNG will get even smaller, but the process of decoding a PNG is a bit more involved than a GIF or even just a bitmap that's been tossed through RLE.

EDIT: Quick test, using this image: Raw bitmap, 64000 bytes. GIF, 32988 bytes. Unoptimized PNG, 20658 bytes. Optimized (optipng -o7) PNG, 11398 bytes. If you're willing to write/port a small deflate and PNG library, PNG is great. If you're not, GIF or PCX (didn't have GIMP on hand to test with -- probably similar size results to GIF) is your best bet.

Disclaimer: My numbers for PNG are higher than they should be -- that's 32-bit RGBA PNG and not PNG-8.

It's highly unlikely that the file's size is a concern.

For one image it might not be worth using gif or png. Lets say your image is 32k as png but the image decompressor is 32k you wouldn't save anything if the image decompressed is 64k. In fact at runtime you're taking up even more ram, 96k, with 64k decompressed image plus 32k decompressor...