16bit OS, What next?

[Hendore]

Hey everyone, I'm pretty familiar with x86 asm aswell as other higher level languages such as C++ altough that won't be of any help as I'm not entering protected mode just yet. I've been messing around with the BIOS functions in some simple bootloaders and managed to successfully display text, read keystrokes and load sectors. I hope to create a very simple real mode OS, much simpler than MSDOS. The OS will have a few applications such as a calculator and calander.

At first, I was thinking of making each app (calc, cal) 512 bytes long and putting each app on its own sector similar to the bootloader. Then the bootloader would be my actual operating system, which would simply load the sector the application is on when there names where inputed and execute them, then return back to the bootloader once complete by loading it again from the application.

I'm sure this would work, but it doesn't seem like it's a nice way of doing a simple 16bit OS. For example, if i was to add a new application I would have to edit the bootloader/os for it to be possible to load the new application.

I'm just wondering, what are the steps involved in creating a small real mode operating system. Thanks for reading, I hope I didn't write alot of nonsense it's 00:50am here =]

Thanks again.

[chezzestix]

Well I'm still a noob but here are the steps as I understand them. However I was previously engaged in a project like this on a different platform that didnt have a protected mode so I have a little experience.

You have a good idea here and here are some suggested steps:

1) Bootloader (for your shell)
2) Shell
-Taking user input
-Comparing against a list
-Control transferring mechanism
3) Lots of application programming

The idea you put forth is fairly simple in theory and has potential to become a... use... for old computers. The biggest perceivable obstical will be the 1MB limit imposed on your system not running in protected mode.

Any help/colaboration you need or want I can provide just pass me a PM. I have a current project but its a prolonged one with no forseeable end so a day here and there of application programming wont stunt it too bad.

[bewing]

Basically, the next typical concept is a filesystem. That way, you can give your programs names, and associate the names with the locations on the disk. So, whatever shell you create gets a program name input from the user -- you search some kind of "directory" for that name, when you find it, there is a sector number associated with the name (and maybe a length). And you read that sector and run it.

[svdmeer]

A 16-bit realmode OS is very simple because you don't have to write drivers to get things working.

I assume you won't use multitasking, very hard without any protectmode code.

Your OS will be simple, but it will be bigger than just one sector. Even reading a FAT12-file takes with both legacy int13h and extensions, with multiple-sector support and support for fragmented files, takes more than one sector.

One sector for each problem means you won't use a filesystem. Sounds like a bad idea. FAT12 and FAT16 is not hard to implement, so use FAT12 or FAT16.


A bootsector which loads applications stored in one sector and jump to the code is not an OS. The applications are only loaded by the OS without an OS providing any services. That means applications rely on the BIOS or must access hardware directly. How do you want to save documents? How do you write any serious program in one sector? Impossible.

[M-Saunders]

MikeOS, my OS project, covers a lot of what you've said:

http://mikeos.berlios.de

It's a small, 16-bit OS written in assembly, but has FAT12 code so you don't have to worry about that sector business. Please see the Handbook, which has a section on making a simple OS. And if you need any help, just ask!

M

[Hendore]

Thank you all for the replies. It seems from them, the filesystem is indeed the next step. I've decided I will use the FAT12 filesystem due to its simplicity.

svdmeer: Your right, my OS won't have multitasking.

Thanks for that M-Saunders, I'll be sure to take a look at it.

[Dex]

You can also look at MiniDos a 2k Dos clone written in fasm

Latest Ver is here: http://www.dex4u.com/etc/MiniDos.zip
Image for qemu:
http://www.dex4u.com/etc/MdosQemu.zip

[Hendore]

Thanks for sharing Dex, I'll take a look at that for sure

I've been working on implementing the FAT12 filesystem, well, doing alot of reading and not alot of coding but it's all fun, but I've hit a snag and I'm really unsure why it's not working.

I know my root directory begins at sector 19 ((numberOfFATs * sectorsPerFAT) + bootsector) = ((2 * 9) + 1). And I know the root directory is 14 sectors ((rootDirEntries * 32) / bytesPerSector). So using the BIOS Int 13/AH=02h function, I'm trying to read all 14 sectors into memory at 0x0200 (directly after the bootloader) but the carry flag is being set from the disk read function, resulting in an infinite loop in my .readRootDir routine.

Here is what I have so far, obviously something is wrong. If you can spot what it is I would be very gratefull.

Code: Select all

[BITS 16]
[ORG 0x7c00]

jmp beginBoot

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; BIOS PARAMETER BLOCK
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
oemID 			db 	"MY -OS- "
bytesPerSector		dw	512
sectorsPerCluster	db	1
reservedSectors		dw	1
fatCopies		db	2
rootDirEntries		dw	224
numSectors		dw	2880
mediaType		db	0xF0
sectorsPerFat		dw	9
sectorsPerTrack		dw	18
numberOfHeads		dw	2
hiddenSectors		dd	0
sectorsBig		dd	0

beginBoot:

  ; Reset the floppy before reading anything
  .resetFloppy:
    mov ah, 0h
    int 13h
    jc .resetFloppy	; Keep trying to reset floppy

  ; Load 14 sectors starting from sector 19 (root-dir)
  .readRootDir:
    mov ah, 02h
    mov al, rootDirSize
    mov ch, 2
    mov cl, rootDirLocation
    mov dh, 0
    mov dl, 0

    push 0x0200
    pop es
    xor bx, bx

    int 13h

    mov al, '+'     ; Added this just to make sure it was this
    call printChar ; routine that i was stuck in

    jc .readRootDir

  jmp $

printChar:
  mov ah, 0Eh
  int 10h
  ret

rootDirLocation db 19	; (fatCopies * sectorsPerFat) + reservedSectors
rootDirSize db 14	; (rootDirEntries * 32) / bytesPerSector

times 510 - ($-$$) db 0
dw 0xAA55

Thank you all for the help.

[Hendore]

OK, Just got back to work on this, it seems I must convert the logical block address I allready have of my root-dir into cylinders, heads and sectors to be used with the BIOS Int 13/AH=02h function.

Once I do get my kernel loaded and executing, I was just wondering what the most common ways where when adding commands such as ls, cp and cd.

I guess each command could be an application, when the user types a command/application filename it could just search the current directory for that binary and execute it with any parameters. Or the commands could be built into the kernel I guess. I'm thinking, making each command an executable seems like the more alegent way and would allow for new commands to be easily added.

What do you guy's think?

[Dex]

In DexOS, i have some built in commands and some that are small app's, it much easier to add commands and for others to add commands this way (as in small apps).