Starting basic OS Development

[Joe[x86]]

(Sorry to bump guys)

Alright, check back with me in 50 years. =/.

[Adron]

(Sorry to bump guys)

Alright, check back with me in 50 years. =/.

Finding out it's a big project?

[Warrior]

Haha you're not even in the kernel yet!

I just did some major design reconsiderations at the last minute (which sucks) so now I'm rewritting my virtual memory stuff :/

[Joe[x86]]

Alright, I just realized that I totally fail!

I've pretty much given up hope of writing anything big, but I'm still interested in some system-level assembly. Right now I'm going to try to write a little thing to take keyboard interrupts, parse them (backspace, etc), and output them to the screen.

EDIT -
Getting the keystroke is real easy.
http://www.ctyme.com/intr/rb-1754.htm
XOR AH, AH
INT 0x16
;AL = Keystroke

EDIT -

Code Select Expand

; x86 Assembly
; System Level
; Notepad Bootloader
; Compile with Netwide Assembler (NASM)
; Author: Joe LaFrance

BITS 16                       ; 16-bit mode
ORG 0x7C00                    ; Move to 0x7C00 in memory, where a bootloader should be loaded
 
MAIN:                         ; This is the entry-point. The first code executed by the processor.

.SETUP                       ; LABEL: Set up the output. This is automatically called.
  MOV BH, 0                   ; Page Number
  MOV BL, 0                   ; Foreground Color

.GETSTROKE                   ; LABEL: Jump here to get a keystroke in AL
  XOR AH, AH                  ; Set AH = 0x00
  INT 0x16                    ; Interrupt KBD - Get keystroke

.PARSEKEY                    ; LABEL: Jump here to parse a keystroke from AL
  CMP AL, 0x08                ; Compare to backspace
  JE .BACKSPACE               ; Backspace
  JNE .NOTBACKSPACE           ; Not backspace

.BACKSPACE                   ; LABEL: Jump here to put a backspace key on the screen
  MOV AH, 0x0E                ; Print to screen
  MOV AL, 0x08                ; Backspace
  INT 0x10                    ; Print
  MOV AL, ' '                 ; Space
  INT 0x10                    ; Print
  MOV AL, 0x08                ; Backspace
  INT 0x10                    ; Print
  JMP .GETSTROKE

.NOTBACKSPACE                ; LABEL: Jump here to put a non-backspace key on the screen
  MOV AH, 0x0E                ; Print to screen
  INT 0x10                    ; Print
  JMP .GETSTROKE

RET




TIMES 510-($-$$)    DB 0      ; Fills unused sector space with 0s
                    DW 0xAA55 ; Adds the bootloader signature to the ending
Untested.

[Warrior]

I'd get out of realmode unless you have a REALLY good reason not to.
Problem with Protected Mode is you can't use BIOS interrupts anymore.

You need to manually set entries in your IDT for your ISRs (Interrupt Service Routines), Remap the PIC (Programmable Interrupt Controller), and then add your IRQs.

Note: If you do NOT remap the PIC whenever an IRQ fires you will get an exception (since they overlap in handlers).

Move to protected mode is easy. I'd really suggest using something multiboot compliant (GRUB or something) to read multiple Operating systems. Even though I swear by GRUB writing a bootloader can be a good experience.

Ok, here's how to move to protected mode:

Create a valid GDT (I'd do this once to enter PMode with 3 entries NULL, CODE, and DATA then I'd redo it with an entry for the TSS(es?) and User segments)
Create a valid IDT (Optional, you can do this in the kernel)
Set the PE Bit in the MSW Register
Do a far jump
Setup your segments with your (DS and SS)
Setup your protected mode stack
Enable Interrupts.

Protected Mode offers protection (duh) by having either segmentation or paging. Segmentation really sucks (and not many compilers compile code withought flat address spaces).

Paging is a mechanism of protecting memory by splitting it into chunks of 4KB. You can then (assuming you have a flat memory model) address a virtual 4GB for each process you spawn (of course marking unused pages as non resident and when a page fault occurs you read it from the disk) and it allows you to map physical addresses to virtual.

Another thing with Protected Mode is that you can use ALL of your memory instead of having the (afaik 64kb) memory limit by real mode. (Note: This also assumes you enable the a20 gate)

Most modern OSes (32 Bit, 64Bit may use Long Mode) use Protected Mode.

Anyways, I guess I went a little overboard with the explaining but I tried to go over some key features which make Protected Mode superior to real mode.

For more information check out the Intel Manual 2 (Instruction Set) and 3 (System Programmers Guide) which is basically the OSDeveloper's bible.

Remember, make it fun.

[Joe[x86]]

Like I said earlier, I'm more interested in learning assembly than using it to create an OS. I just want to put that hunk of scrap metal you call a Compaq to good use. =).

However, that seems like a pretty good explination at first glance. Way over my head, but hey, I may come back to it some day.

[Warrior]

Uh the read "The Art of Assembly". Lol. It will teach you way more than this project will if you know nothing about assembly.

Also unless you want to try to "beat" the compiler (at a later time write an OS in pure asm), I'd suggest learning C or Pascal or even C++ (Eww for OSDev btw) as those languages can be used as well.

[MyndFyre]

Like I said earlier, I'm more interested in learning assembly than using it to create an OS. I just want to put that hunk of scrap metal you call a Compaq to good use. =).

However, that seems like a pretty good explination at first glance. Way over my head, but hey, I may come back to it some day.

You can learn assembly without creating a bootloader you know.  You can use NASM to compile 32-bit programs even!

[Warrior]

pfft..FASM.

[Joe[x86]]

NASM seems to be the only one with syntax I can understand. Plus, I'm too far in to port all my.. 10 lines of code. How's that for stubornness?

[Warrior]

FASM = NASM syntax with a few changes. Like 2 or 3. It allows for elaborate macros though which are leet.

[Grok]

LoRd[nK], what are you laughing at?

Yoni[vL], theres DOS interrupts, BIOS interrupts, and everthing down to calculator interrupts.

OnlyMeat, sounds good. Aparently it's a real shitty way to learn, but eh, it's working for me.

K, you get paid decent for your work? JoeOS is going to be free software, but my dad want's me to make money off it, so I might end up making it.. eh.. $5 or something, or shareware.

Advice for your dad:  Joe will make gobs of money off this because it is training you in depth at new levels of computing, and future employers will find him incredibly valuable the wider his knowledge is in the computer knowledge spectrum.  Knowing programming from the machine level all the way to n-Tiered application development is almost unheard of in IT.  Let Joe fully study what he has current motivation to study.  When his interest shifts, encourage him in the new areas too.  After college and a couple years exposure in the market, he'll be getting offers relative to his potential value.

[Warrior]

Agreed, OSDev can be fun once you program the barebones of it which is reliable exception management and things like interrupt handling. Implementing higher things like SMP and detecting devices, deciding how to abstract your Filesystem(s) and devices and all that can be great fun

[UserLoser]

Blah, I've been wanting to do this for a while but I don't know where to start--or what to use to compile your assembly code/whatnot

[Warrior]

Well I use FASM or NASM to compile my assembly (Sometimes I'll code inline assembly with intel syntax turned on) and DJGPP to compile (DJGPP isn't recommended since it has some limitations but I got over most of them), however I plan to build a GCC cross compiler when the need arises. When my OS is mature enough to execute programs and I have most GCC dependancies ported then I'll build the compiler on my OS and be self hosted.

OSDev is around 60% research and 40% implementation. There are plenty of examples of good (and bad) implementations floating around. I usually follow what most do adding my own twists here and there.

One of the biggest annoyances is lack of hardware support so even if you do get to VESA in a good reso with like 32 or 24 bpp it still will be painfully slow even with MTRR enabled.