OSDev.org

Ok (all my posts starts with Ok, because i don't now what i should say so...) i'm starting at Osdev Forum, so I'll introduce myself:

My name is Guilherme Ferreira Franco, i live in Brasil, i'm 17 years old and i work on a pseudo-scholarship in a Federal Institute in the State of Rio de Janeiro, in a city called Campos dos goytacazes (The capital of Rio de Janeiro State is the City of Rio de Janeiro), i say pseudo because officially i don't have an scholarship, lets say that i entered and started working, i don't recieve nothing by this, but they let me in.

The question is that the institute need an program to run some internal functions, like: voting of principals and rectors; backuping, formatting and testing of computers. And all them need to be error proof, invasions proof and dummies proof (any one have to understand it), and all that at the same time!.
I decided that no program would do this better than a OS.
Once that a have very much experience in 8086 and in code optmization, and i'm crazy to do an OS, i decide to do an 16-bit pure 8086 code OS.
now, heres the introduction of my OS:


HARD OS:

PURPOSE:
The purpose of this OS is provide a simple 8086 Operational System, wich have modern features, emulating some processor functions through single step debugging, and implementing a more intelligent and efficient use of the 8086 instructions, giving coders much more work to code it, but giving a very high performance, and very good appearence, using only 8086 instructions and 320*200 256 color video mode.

METHODS:
Use more brain power and less hardware power, finding out the most efficient mode to do something, like:

How move 1000 bytes from ds:si to es:di? (in NASM compiler)

If you need space:

Mov cx,500
Rep Movsw

If you need speed:

TIMES 500 db 0A5h

And a a mix of the two:

Mov cx,25
LOOPMOVE:
TIMES 20 db 0A5h
Loop LOOPMOVE


LONG EXPLANATION:

The HARD OS is a modular kernel operational system, coded in 8086 assembly, that runs only the 8086 opcodes, and have modern features, like memory protection, multi-tasking, idle-process, performace counting, watch dog, paging, and all that using the single step debugger to ensure avoiding kernel to be damaged and do alterations on the next opcode to be executed, no process or module can write on the kernel, jump to it, or do anything that could cut off kernel control about the system, and using a invalid opcode manager, so the process can only execute 8086 instruction, so if you try to enter protected mode, or change Control register values or acess any non-8086 functions you'll be blocked out.

One of its features is what i call GMDR (General Maintance and Debugging Routine), an routine attached to Int 08h that test random areas from memory, and each time it is called it test a different checksum of a different module or process (because there are three types of checksum), any error will call the right error handler for it, and if there's none, or there's a double fault (error on error handler) the system's general error handler will be called, and this is defined by the user (generally it locks system in the kernel and asks the user what to do, but in some extreme cases, in wich the managed data is too important, the system prints a minimal phrase on screen warning about the crash, disables PIC and Halt the processor).

The general system Error handler is a interface to decide what to do when system can't solve a problem by its own, and its attached to Int 3 (0CCh in hex), that is called by the GMDR or when system execute a free memory area, because any free memory area is filled out with 0CCh bytes.

Another important interface is the system main setup and managing page, a page that stops everything when called, and its invoked directly by the kernel.
Only the user may call this, by pressing Ctrl+Alt+Del.

And another great feature is that its have an integrated X manager, with some features as dinamic pallete change, graphic object simulation and more things, all that in 320*200 256 color video mode.

The rest will be explained at the first relase.

In sume, the legacy of this OS is, CODE HARD

Wow! What an incredible idea!

Memory protection, multitasking ...... under complete 8086 environment, something 8086 was not designed for. What a great challenge to 8086 designers.

Good luck.

Are you sure you're going to be able to fit such a wealth of features in the 8086's limited address space? I can understand memory protection and multitasking, but a full X server seems dubious for less than 1 megabyte of memory. In addition, you're not going to get very good performance if every memory access causes an exception, so you sort of have conflicting goals.

You may want to take a look at the original MINIX, because IIRC it also ran under the 8086, and does many of the things you want your OS to do, although it only uses segmentation for memory protection.

I know that you said, but this is the idea, must be HARD, very HARD to code this.
And the video only takes 64KiB of memory [320*200*1 (8-bit color)].
I already did something to 320*200 to have a better appearence, like a dinamic pallete changing, to create a 24 bit colours, but only 256 colours at the same time on screen.
And its will support Virtual Memory.

guilherme wrote: Mov cx,25
LOOPMOVE:
TIMES 20 db 0A5h
Loop LOOPMOVE

Er, isn't 'db' an assemble-time directive? In which case that code makes no sense...

EDIT: OK, I see that 0A5h = movs. It's all very strange to read though...

M

guilherme wrote: The HARD OS is a modular kernel operational system, coded in 8086 assembly, that runs only the 8086 opcodes, and have modern features, like memory protection, multi-tasking, idle-process, performace counting, watch dog, paging, and all that using the single step debugger to ensure avoiding kernel to be damaged and do alterations on the next opcode to be executed, no process or module can write on the kernel, jump to it, or do anything that could cut off kernel control about the system, and using a invalid opcode manager, so the process can only execute 8086 instruction, so if you try to enter protected mode, or change Control register values or acess any non-8086 functions you'll be blocked out.

One of its features is what i call GMDR (General Maintance and Debugging Routine), an routine attached to Int 08h that test random areas from memory, and each time it is called it test a different checksum of a different module or process (because there are three types of checksum), any error will call the right error handler for it, and if there's none, or there's a double fault (error on error handler) the system's general error handler will be called, and this is defined by the user (generally it locks system in the kernel and asks the user what to do, but in some extreme cases, in wich the managed data is too important, the system prints a minimal phrase on screen warning about the crash, disables PIC and Halt the processor).

One of the things to watch out for is the limitations of the 8086 that are documented, but less obvious. For instance, an 8086 does not have an invalid opcode interrupt, instead it will just reset itself upon an invalid opcode.

You may want to look at my 8086 emulator project for a complete list of the opcodes and a few other details(though it's a bit backwards to read the source of an emulator): http://sourceforge.net/projects/x86lib/ (don't download the release, it's very old.)

I understand, but this invalid opcode is managed by the single step debugger, by reading the next instruction to go, and comparing it with 8086 instructions.

As far as I know the 8086 has no hardware debugging capabilities.

The 8086 have an single step Debugger, or trap debugger, an debugger called after each instruction when the TF (Trap Flag) is enabled.
To keep this running, it just need to read next instruction that will be executed and check if it won't mean any harm to the debugger, this means: avoid TF clearing, avoid Vector at IVT to be overrided, and avoid the code to be overrided.

Well that just shows how much I know about the 8086. I've only done real mode programming to test graphic functions for windows/linux programs, because it's easier to set things up and I can use a simple memory layout.

guilherme wrote:The 8086 have an single step Debugger, or trap debugger, an debugger called after each instruction when the TF (Trap Flag) is enabled.
To keep this running, it just need to read next instruction that will be executed and check if it won't mean any harm to the debugger, this means: avoid TF clearing, avoid Vector at IVT to be overrided, and avoid the code to be overrided.

I have a feeling this will be a very tedious project and yet run very slowly.

Tedious, just for me who will need to code it, slow, only if you want.
This OS will have process and modules descriptors with wich you can select the interval in wich the debugging and protection routine happens, those can be selected by number of instructions or milliseconds.
The option that requires less memory is also the most secure of all: the "single step" one, and all that this have to watch is one instrution foward, but the other options will need to scan more instructions, and, when you select by time, the protection is disabled, it will serve only for basic debugging and attached routines purposes.

it's a good idea. i've got a multi-tasking (i.e. context-switching) OS kernel i've written myself in C and assembly that works on original 8086/8088 CPUs, it's waiting for me to finish a FAT driver.

anyway, just so you know using the trap flag to single step is going to make it SSLLLLLLOOOOOOOOOOOWWWWWWWWWWWWWWW on an 8086 class processor. i've written software that monitors and logs port I/O using the single-step feature and it does make programs unbearably slow. i ran it on a 4.77 MHz 8088 original IBM XT. even if you only run a couple instructions and then return, it's painful.

even if you return immediately, there is the overhead of the CPU pushing and popping CS, IP, and the flags word. so it's already at least 6 or 7 times slower even if you dont run any of your own code except the iret.

it's still an interesting idea. have you been working on it?

guilherme wrote:Tedious, just for me who will need to code it, slow, only if you want.
This OS will have process and modules descriptors with wich you can select the interval in wich the debugging and protection routine happens, those can be selected by number of instructions or milliseconds.
The option that requires less memory is also the most secure of all: the "single step" one, and all that this have to watch is one instrution foward, but the other options will need to scan more instructions, and, when you select by time, the protection is disabled, it will serve only for basic debugging and attached routines purposes.

if you don't run the protection routines after every single instruction, they essentially become worthless. what if somebody wrote some self-modifying code that does not get detected by your routines that scan ahead in memory after a certain interval? it can rewrite code in memory during this interval that does some malicious stuff to your kernel that your routine couldn't catch and then run it.

it really is impossible to implement protection on an 8086 without using the single-stepper. don't forget to intercept all POPF functions executed by user code, and OR the trap flag into the current SS:SP just in case somebody tries to disable it that way. and, of course, make sure nobody overwrites the IVT entry for interrupt 1, but that's obvious.

EDIT: i just realized you already mentioned it'll have to check for overwriting IVT for int 1 and make sure the TF doesnt get cleared, sorry.

earlz wrote:One of the things to watch out for is the limitations of the 8086 that are documented, but less obvious. For instance, an 8086 does not have an invalid opcode interrupt, instead it will just reset itself upon an invalid opcode.

You may want to look at my 8086 emulator project for a complete list of the opcodes and a few other details(though it's a bit backwards to read the source of an emulator): http://sourceforge.net/projects/x86lib/ (don't download the release, it's very old.)

i'm writing an 8086 PC emulator myself http://fake86.rubbermallet.org and just wanted to mention that the 8086 won't reset itself on an invalid opcode, it just continues to the next byte in RAM.