Boot from CD and load method.

[Teehee]

Hi.

1º. My "OS" is getting bigger bc of .bmp files. It does not fill in a floppy anymore. Ok, i just need to put it in a CD and boot from there. I've read the 'El Torito' spec., but i didn't understand much. Can you give me some orientation? (i'm using pure assembly)

2º. Even if i boot it from CD, how i will load all my OS if there is only less than 1Mb availabled? Do i need load a part, then jmp to PM, copy.. back to RM, load next part, jmp PM, copy.. and so on...? plis no

[Combuster]

1º. My "OS" is getting bigger bc of .bmp files. It does not fill in a floppy anymore. Ok, i just need to put it in a CD and boot from there. I've read the 'El Torito' spec., but i didn't understand much. Can you give me some orientation? (i'm using pure assembly)

El torito is just to tell how to boot a CD - you can either tell it to emulate a regular (floppy) disk, so you can keep using your existing bootloader. Or you can do without emulation which means you'll have to write new code and you'll have to add ISO9660 filesystem support to it.

plis no

Sorry, yes. Its easier than including a full protected mode driver though as you can still use bios functions.

[Tosi]

I would use PNG instead of BMP files, but then you have to write PNG code, or port libpng to your OS.

[Chandra]

Hi.

1º. My "OS" is getting bigger bc of .bmp files. It does not fill in a floppy anymore. Ok, i just need to put it in a CD and boot from there. I've read the 'El Torito' spec., but i didn't understand much. Can you give me some orientation? (i'm using pure assembly)

Of course. Read 'Int 13h Extensions'.

2º. Even if i boot it from CD, how i will load all my OS if there is only less than 1Mb available?

Employ Unreal mode.

Do i need load a part, then jmp to PM, copy.. back to RM, load next part, jmp PM, copy.. and so on...? plis no

Yes, to some extent. All you need to do is - switch to Unreal mode then load a part of file then copy it to extended memory, then load next part and continue as before.
You don't need Protected mode <--> Real mode transition though.

Have Fun.

[Combuster]

You need protected mode to enter unreal mode, and the bios might undo unreal mode at every call you make to it.

Entering protected mode does not technically require a jump (although intel recommends it for decoding reasons) - its changing from 16 to 32-bits code that really does.

[Chandra]

You need protected mode to enter unreal mode.

You are right, but I'm sure that is the only transition required, no?

and the bios might undo unreal mode at every call you make to it.

Wow.
I'm not sure if this happens when calling Int 13h. I've been using Unreal mode and Int 13h simultaneously, but so far I've not seen such behaviour. So, I assume this applies on other BIOS calls.

[Brendan]

Hi,

and the bios might undo unreal mode at every call you make to it.

Wow.
I'm not sure if this happens when calling Int 13h. I've been using Unreal mode and Int 13h simultaneously, but so far I've not seen such behaviour. So, I assume this applies on other BIOS calls.

The only BIOS function/s that are guaranteed to mess up unreal mode are the "extended memory move" and "switch to protected mode" functions (that nobody actually uses). In my experience (for network boot) the PXE functions almost always mess up unreal mode too (especially if you're using etherboot/gPXE).

However, nothing really prevents any BIOS function from using protected mode internally and messing up unreal mode, because there's no formal specification that says what a BIOS must/must not do; and just because one BIOS does things a certain way doesn't mean that all BIOSs do things the same way or that future BIOSs won't do things differently.

Also note that EFI/UEFI runs in protected/long mode, and for some computers the "BIOS" may just be a layer built on top of EFI/UEFI (e.g. like "bootcamp" on 80x86 Apple machines). In this case it would be tempting for the people writing the "BIOS compatibility layer" to reuse the EFI/UEFI drivers to access the disk, etc (to avoid the need to rewrite a bunch of different drivers). Basically the BIOS function/s could just switch to protected/long mode, use the existing EFI functions, then switch back to real mode. Worse, even though EFI/UEFI uses polling (and not IRQs) for devices, it does use a timer IRQ. This means that (as an extreme worst case) a "BIOS compatibility layer" could have an IRQ0 handler that switches to protected/long mode and transfers control to the real EFI/UEFI IRQ0 handler; where (from your real/unreal mode boot loader's perspective) unreal mode is disabled at unpredictable times.

Basically what I'm saying is that almost all BIOS functions on almost all current BIOSs are "safe" and won't interfere with unreal mode; but I'd be tempted to find an alternative (e.g. "disable IRQs, switch to protected mode, do what you have to, switch back to real mode, then enable IRQs again") that is more robust anyway.

Also note that I used unreal mode for all my boot loaders for a very long time without any problems (other than re-enabling unreal mode after calling any PXE function). As a precaution (and not for any tangible reason) I stopped doing that a few years ago and started using the "switch to/from protected mode" method instead.


Cheers,

Brendan

[Chandra]

Also note that I used unreal mode for all my boot loaders for a very long time without any problems (other than re-enabling unreal mode after calling any PXE function). As a precaution (and not for any tangible reason) I stopped doing that a few years ago and started using the "switch to/from protected mode" method instead.

Hmm... interesting. Isn't there any performance loss while making continuous transition to and from protected mode? I mean,
Map IRQs -> Resore IRQs -> Map IRQs -> Resore IRQs -> ......
Lots of Far Jumps ....
Lots of Bit Togglings....
I'm not convinced that it is the proper price to pay but I can't see an alternative either.

[Brendan]

Hi,

Also note that I used unreal mode for all my boot loaders for a very long time without any problems (other than re-enabling unreal mode after calling any PXE function). As a precaution (and not for any tangible reason) I stopped doing that a few years ago and started using the "switch to/from protected mode" method instead.

Hmm... interesting. Isn't there any performance loss while making continuous transition to and from protected mode? I mean,
Map IRQs -> Resore IRQs -> Map IRQs -> Resore IRQs -> ......
Lots of Far Jumps ....
Lots of Bit Togglings....
I'm not convinced that it is the proper price to pay but I can't see an alternative either.

To avoid messing with IRQs too much, you'd disable IRQs, switch to protected mode, do what you have to, then return to real mode and enable IRQs again - no need to mess with PICs and remap the IRQs.

The overhead of this depends on what you're doing. For an example, if you're loading a 5 MiB kernel from disk, then you could load about 512 KiB at a time into a buffer in real mode, then switch to protected mode to copy that 512 KiB buffer somewhere else. For 5 MiB you'd switch to protected mode and back 10 times, and the overhead of doing this will be almost nothing compared to the time spent reading the data from disk.


Cheers,

Brendan

[Chandra]

To avoid messing with IRQs too much, you'd disable IRQs, switch to protected mode, do what you have to, then return to real mode and enable IRQs again - no need to mess with PICs and remap the IRQs.

And what if an Exception Fires while you are in protected mode? You can trust your code(as long as you have written it fairly) but you cannot trust hardware. I've an old code that fires and 'Invalid Opcode' Exception under AMD Processor but run fines under Intels (and of course under emulator). If you want to have a look on it, I can attach it.

Ah! that is just an over-estimation. I must realize that there are lot of ways our code can break, even under normal situations (and that's what is called bug). So it's like worrying about an ant in your bed but overlooking the Tiger in your room. Never mind.
Cheers!

[Brynet-Inc]

So it's like worrying about an ant in your bed but overlooking the Tiger in your room. Never mind.
Cheers!

Why are you living in a jungle?