OSDev.org

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.

indiocolifa wrote: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.

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

indiocolifa wrote: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.

indiocolifa wrote: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. Rolling Eyes

xor ax,ax
mov ds,ax
mov word [ds:0B8000h],8403h  ;print a char on screen, but only in Unreal Mode

CmpXchg wrote:

indiocolifa wrote: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.

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.

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

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.

indiocolifa wrote: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.

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

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!

JamesM wrote:

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!

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" Wink

indiocolifa wrote: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! Laughing

indiocolifa wrote: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.

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.

svdmeer wrote:

indiocolifa wrote: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.

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.

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.

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.

svdmeer wrote:

indiocolifa wrote: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.

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.

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.

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.