Multitasking in real-mode?

[wxwisiasdf]

The original question has been "questioned" before, but there was no real answer.
So, what will be a good and practical way to do multitasking? (dosen't matters if it's the hard way)

No V8086 mode
I will not use protected mode, i have my reasons
I dont use real-mode because of BIOS functions, i myself dont like them and i slowly replace them with own drivers
I need multitasking to run drivers in the background while my programs dances on ORG 0x100
I don't care about portability
I know BIOS is outdated and UEFI is the new thing

[sunnysideup]

Looks like you'll have to use segmentation, and every context will have to use different segment registers... There's not gonna be much concept of protection however I guess.

[nullplan]

In order to do multitasking on any machine, you will need memory protection and a timer interrupt. And in a pinch, memory protection can slide.

If you have multiple programs in real mode, they will all run in the same address space, so all your program images will need to be position-independent, or else be relocatable. This is what DOS executables did, they had a list of relocations, and the DOS loader had to add the base address (or was it the segment?) to each of them. It is possible, it's just a hassle. But position independence is even more of a hassle in 16-bit mode, so there.

What you actually do then, is not that much different from all other OS kernels, only you are hobbling yourself with the least attractive mode of operation the CPU can be in. Your kernel needs to keep track of all processes in the system, and on task switch save all registers onto kernel stack and load registers from the other task's kernel stack. Since you are in real mode, there will be no automatic stack switch, so all processes will be required to have at least a few words of free stack at all times (at least while the interrupt flag is set). And good luck keeping track of the FPU.

[iansjack]

The original question has been "questioned" before, but there was no real answer.

Could that be because there is no satisfactory answer?

I don't see it as that much of a problem - you restrict yourself to such a small address space that you can't usefully run many tasks at the same time anyway.

Would you care to elucidate on your reasons for not using protected mode?

[wxwisiasdf]

The original question has been "questioned" before, but there was no real answer.

Could that be because there is no satisfactory answer?

I don't see it as that much of a problem - you restrict yourself to such a small address space that you can't usefully run many tasks at the same time anyway.

Would you care to elucidate on your reasons for not using protected mode?

• I need to support 8086 hardware (goal set by myself).
• Possibly port the OS to other 8/16-bit plaftorms (C64 with A65?).
• I don't plan on running more than 4 or 5 tasks (of 2 or 4 paragraphs each) at the same time (most of them drivers).
• I don't want to get out of the real-mode bubble yet.
• A20 can give some extra memory.
• It's nice to have challenges, like small memory to deal with.

[linguofreak]

Broadly speaking, writing a real-mode OS is like writing a language runtime library for a protected mode OS. Writing a multitasking real-mode OS is like providing a user threads implementation in that runtime library.

I need multitasking to run drivers in the background while my programs dances on ORG 0x100

No you don't. Unless you're writing a microkernel, a driver is more akin to a library in a userspace process than it is to a thread in a userspace process. They aren't tasks. Drivers are generally passive: they wait for something to happen (such as a program making a system call that causes the kernel to ask the driver to do something, or an interrupt from the device that the driver manages). Drivers generally aren't scheduled entities and, on multitasking systems, run on some other task's timeslice.

[*]Possibly port the OS to other 8/16-bit plaftorms (C64 with A65?).

In this case, it might actually be better to put the system together for one of those other platforms and then port it to x86. This way you avoid the risk of accidentally writing something that depends on x86 segmentation and then having to kludge around that, or rewrite things entirely, when you port the OS.

[*]A20 can give some extra memory.

Not much in real mode. You only add 1/16 of the total that you have available without it. And if you're wanting to be able to run on 8086s, you can't count on A20 even being there. The high-order address line on an 8086 is A19. A20 didn't even exist before the 286. Technically, the A20 mechanism doesn't even *give* you extra memory. Until you tell it to stop doing so, it forces A20 to zero to take away memory that you'd otherwise have on a 286 or better so that it can show software written for an 8086 what it expects to see: wraparound from the top to the bottom of the first megabyte (the only megabyte on an 8086), rather than the end of the first megabyte being followed by the beginning of the second. On non-PC x86 platforms (not that there are many), the A20 kludge doesn't exist: you'll always see all available memory.

And if you want to port your OS to stuff like the C64, you can't count on having more than 64k available anyway.

[bzt]

I need to support 8086 hardware (goal set by myself).
Possibly port the OS to other 8/16-bit plaftorms (C64 with A65?).

Then check out Contiki OS. It is an Open Source, multitasking OS which runs on 8/16-bit platforms, among others x86 (real mode), C64 and Atmel AVR too. Even has a minimal GUI.


Cheers,
bzt

[azblue]

Keep track of each task's segments, flags, GPRs and IP & SP. I'm not sure how exactly you plan on doing things, but you'll probably need to keep track of how much memory each task has.

[Thomas]

Hi SuperLeaf1995,

It is possible to do this, basically save registers etc and switch context, its probably not possible to address protection of tasks easily though.

These best book on the purpose is MicroC/OS 2 book by Jean J. Labrosse. See: https://www.amazon.com/MicroC-OS-II-Ker ... 8&me=&qid=
The contiki project as pointed above is interesting. Another idea would be to simply implement a multitasking layer on top of DOS.
You might find the well documented prex microkernel interesting : http://prex.sourceforge.net/
Xinu x86 version also another system which is easy to understand. ELKS is also something you might find interesting due to the huge amount of programs that are already ported to it. http://elks.sourceforge.net/

--Thomas