Theres not all that much to say here. I've been working on "JoeOS" for a two days now, and succeeded to load a stage two bootloader. Aparently a guy named c0n has been working on OS Dev since December and I've already passed him, so I'm proud enough to continue for weeks. Anyhow, if anyone is interested in following my progress, the thread discussing this is here. zorm[vL] is working on one too now, so I guess we can get through this together helping eachother. Anyhow, I started this with half-ass ASM knoledge, and so far its been easy. I've got a nice chart of interrupts to refer to, located here, so I'm pretty much set. JoeOS is open source, and can be downloaded and built using the instructions in it's readme. Check it out if you want, but it's nothing to write home about. Leave feedback too, I'd love to hear what you have to say about it (well, if you aren't too negative about it =p).

haha

Those are DOS interrupts, mostly. If you want to make an OS, you have to make your own table. :P

Actually, the BIOS provides your own set of interrupts and anything else can be defined in the IVT or if you're in PMode you can sort it out in your interrupt/exception handler..

http://www.ctyme.com/intr/int.htm - Ralph Browns interrupt list (HTML Format)

Edit: Didn't realize that I posted the same link as above -- those are indeed BIOS interrupt that work in real mode and v8086 mode

Sounds cool, i wanted to do something like this for a while myself. I might just have a go now ;)

How difficult is it to get the bootstrap working using just bios interrupts?

OS development is my current job, and it's fun  ;).  Luckily, we work on sensor nodes, which are quite a bit simpler to deal with than a desktop system.

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.

[quote author=Joe[x86] link=topic=11883.msg116406#msg116406 date=1119128453]
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.
[/quote]

I make $15 an hour, and work part time (~20 hours/week).  The graduate students who work on our project get paid more, but they also do less programming and more paper writing and submitting.

Our OS, however is free: license

[quote][15:25:22] <Joe[x86]2> wtf
[15:25:24] <Joe[x86]2> well
[15:25:30] <Joe[x86]2> It loads stage 1 just fine
[15:25:37] <Joe[x86]2> attempts to load stage two
[15:25:38] <Joe[x86]2> and does
[15:25:39] <Joe[x86]2> and
[15:25:49] <Joe[x86]2> stage two prints its welcome message.. *counts*
[15:25:57] <Joe[x86]2> 10 fucking times[/quote]

Oh man, I need to cut myself. I've done a lot of cutting myself lately. By the way, I hope you know I'm not serious about cutting myself. I haven't even hit my head against the wall yet.

Not difficult at all, the BIOS provides int 13 (floppy) and you can either implement a filesystem reading to get the ability to search for files, or if you know exactly where your file is on your floppy you can read that number of sectors to the designated area of memory. Then you far jump to set CS

Joe, I would suggest creating an OSS instead of an OS. Just to get a better idea of what your OS will be like in the end (or when you have a functional copy).

That's a bad idea, even though it's good to have a clear idea of what design you want this can only be acomplished after RESEARCH on the topic is done. Making a shell which is only a component of an operating system is something that can cause you to get ahead of yourself and lose sight of the basics which are an effective message passing system, a stable error handler, ability to print hex, decimals, etc.. to the screen, a way to manage drivers, and a FileSystem service. If he is to take your logic than he might as well write everything seperately and defeat the purpose of writing an Operating System in the first place.

[quote author=Warrior link=topic=11883.msg117530#msg117530 date=1119752065]
That's a bad idea, even though it's good to have a clear idea of what design you want this can only be acomplished after RESEARCH on the topic is done. Making a shell which is only a component of an operating system is something that can cause you to get ahead of yourself and lose sight of the basics which are an effective message passing system, a stable error handler, ability to print hex, decimals, etc.. to the screen, a way to manage drivers, and a FileSystem service. If he is to take your logic than he might as well write everything seperately and defeat the purpose of writing an Operating System in the first place.
[/quote]

Although I agree with you, modulatization is also a good thing, and if he wrote everything separately, it might be a good exercise in modularization as well.  :P

Possibly, but a shell is hardly any way to learn how to write an operating system.

Im a bit stupid when it comes to OS development but will it run .exe so it could run games etc. If so and its more stable the MS(Though it must be how could it be less stable) then id give out $5.

(Sorry to bump guys)

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

[quote author=Vote Joe! link=topic=11883.msg122256#msg122256 date=1122554188]
(Sorry to bump guys)

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

Finding out it's a big project? :P

Haha you're not even in the kernel yet! :o

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

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]; 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[/code]
Untested.

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.

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.

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.

[quote author=Joe link=topic=11883.msg132003#msg132003 date=1130382269]
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.
[/quote]

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

pfft..FASM.

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?

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

[quote author=Joe link=topic=11883.msg116406#msg116406 date=1119128453]
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.
[/quote]

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.

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 :)

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

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.

[quote author=Warrior link=topic=11883.msg146753#msg146753 date=1140587735]
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.
[/quote]

I keep trying to tell you man, hack ntdll and hal.dll.  Reproduce *that* and go for native Windows driver compatibility.  :)

Well if anything, I'd port some of the 2D Accelerants for VBE in Open BeOS or in Linux. Of course until now no one has documented, maybe I should be the first! Most of the things that worry me are reversng some NIC's and such but my NIC fortunately was made open source by VIA (Go them).

Of course my OS is no where near that mature. Right now I'm implementing Kernel->User communication via Call Gates (Messier but faster than plain int xx) and taking into account possible errors that could acompany "cpuid".