OSDev.org

I successfully wrote a FAT12 boot sector on a disk and i'm writing the disk reading routines now. Since I'm new on this i would like to see some opinions on the route of my first toy OS:

1) What do you think it's easier? Going 16-bit RM or 32-bit PM? If going to PM32 want to create some form of 'Protected Mode DOS' where all code runs in ring 0. Sure, if all code runs in Ring 0 what is the benefit of PM at all? Well, no 1MB limit and segment mess, easier to code I think.

2) When switching to PM, how do you access to disk using Int 13 (since BIOS calls are not available from PM)?

3) And this is bizarre, what about creating some 16-bit Real Mode multitasking OS, trying to remain into the limitations of the 8086/88 programming model? This sounds like a good programming project.

Thank you very much.

Hi,



32-bit PM (as opposed to 16 bit RM) is a dual-edged sword. On the one hand you get to access all the processor functionality which you can't in real mode - different segment stuff, 32-bit address space, paging etc etc.

However with that, as you've correctly stated, you cannot use BIOS routines (without a vm86 task). IMHO if you're looking for a "protected mode DOS", I really think you should stick with 32-bit "unreal" mode, where you can access the full 4GB and use BIOS routines (but can't use paging).



You can call Int 13 by creating a vm86 task - that is, a special task that runs in 16 bit mode. It is, however, incredibly slow, so it is normal procedure to write your own ATA driver once you get into PMode. This is a reason why I personally think you'd be better off with unreal mode, as for what you wish to do it sounds the easiest route.



That is definately possible, you don't have to use the hardware assisted method of task switching - you can do cooperative context switching instead. I'm sure Dex can expand on this, as generally I'm a 32-bit protected mode "type"

Hope this helps,

James

Well Unreal mode sounds well for my project. Please clarify me on the addressing scheme of Unreal (since I could not find much documentation on it).

On real mode, for a linear address SEG:OFFSET where SEG and OFFSET are 16 bits wide.

PHYSICAL_ADDR = SEG << 4 + OFFSET

So, this addressing scheme actually works EQUAL in Unreal mode but using 32-bit offsets?

SEG << 4 + OFFSET_32

But this means that I can set CS,DS,ES,FS,GS to 0 and use OFFSET_32 as a physical address? This is better than switching to V86 for my needs.

Thanks!!!!

You're right, PM is better because of no memory limitations. However, it may be difficult in the beginning, because you have to correctly set up stuff like GDT, LDT, IDT, TSS, paging etc. You see how many people on this forum have trouble with this. But after you have done it, and your OS kernel works well and reliably, programming the rest becomes a lot easier.

What's more, it's nearly impossible to write a modern graphical user interface under 16bitRM, because you can't access video memory properly.


If you want to use Int13, you have to create a V86 task and call Int13 from there. Or it is also possible to switch back to realmode every time you need disk access. Windows 95 actually did something like that, AFAIK.

And of course, the solution might be to create your own disk drivers, but it ain't the simplest task to do. That's how it's done in real systems.


Yes, such projects exist.
Well, in RM there can be no proper multitasking with protected address spaces and privileges. However, in this case it's quite possible to implement multithreading.

Multithreading in Real Mode is achieved using timer IRQ0, which loads context (saved CPU registers' values) and transfers control to another thread at every timer tick. As you can see, it is preemptive sort of multithreading. Naturally, there are many problems with such a system (threads may conflict with each other, trying to access the same device, for example). But it's still a good programming project, because it requires a good deal of thinking and is actually possible.

So, as you can see, it's up to you to choose. Possibilities are endless.

Cheers,
CmpXchg

Exactly!

What are you trying to say with "can't access video memory properly" in 16bit RM? Can't you write to video memory addressing the proper address space where it's mapped?

thanks!

Maybe what you're saying is that in 16 bit RM only the first 64K VGA address space is available, but in higher video modes which require 128Kr 256k or more you must use some banking or segment-twiddling techniques due to the 64K segment size.

That's it?

Well, look at it this way. In 16 bit mode, you have access to 1MB of addressable space. A 1024x768x32 framebuffer takes 3.145MB of space.

To use a crude American expression which I hope I never use again: "Go figure"

Cheers,

James

This applies only to 16bit RM ... I wonder if it's possible to access a linear framebuffer in unreal mode. Anyway, this is not a priority now in my research kernel of course. I should get FAT12 I/O first!

Couldn't've said it better myself!


You're right again. In Unreal mode it there will be no problems accessing the framebuffer.

Buy the way, does you OS load from floppy?

16-bit RM is much easier because you have full access to the BIOS and you memory management is very simple.
32-bit PM requires direct access to the hardware with everythinkg you do and memory management is more complicated, aspecially when you use paging.

Making a kind of DOS? The design of DOS sucks, it's historic, it doesn't mike sense anymore imo. Think about something new.



Doesn't sound good to me. 16-bit realmode is a pre-historic thing. I think it's crazy x86 processors still have it. Serious OS-projects on ordinary hardware are 32-bit or 64-bit, not using any segmented memory and using paging.

* JamesM prepares the popcorn for the Dex-based bitchslapping that is about to commence.

/me stocks up on Coke and Chocolate-coated icecreams.

Edit: To say DOS is crap is a pretty big statement. It served the needs of millions of users for a decade.

It's plain flamebait. Ignore it. (*collects james' popcorn*)

Haha!

Yes, I know that 8086 segment addressing is incredibly painful to program for, that DOS was a very limited kind of "operating system" (sometimes I think if it deserves to call it "OS" ) but I want to start from something, I am not saying that my intention is to create a DOS clone, altough yes, it will run without protection (in Unreal mode, that's it) and be able to call BIOS, talk directly to hardware, etc.

I've finished writing in FASM the first stage of the boot loader, now with A20/Unreal mode/proper FAT12 kernel loading from diskette (this is to test things early).

So what I'm doing is: enabling A20, unreal mode, loading kernel at 0x10000000.

A question: it's possible to use ELF executables on Unreal mode? I know that's still real mode so I don't know the details of ELF to see if it's possible. Also I wonder if GCC can generate suitable executables for non-protected mode 32-bit binaries.

THank you very much.-