Index
> OS Construction > OpenRodent Operating System. |
| Author |
|
|
IsaacZ 05 Dec 2025, 17:59
Hello, I'm here to talk about my new 16-Bit open-source Operating System designed in FASM for X86 CPUs. This operating system includes a Graphical User Interface, a TextEdit app, and a shell. I would like someone to give some suggestions on what I can improve, and what I should add. Source is free, so take it if u want.
Download link will be below 
|
|||||||||||
05 Dec 2025, 17:59 |
|
|
sleepsleep 06 Dec 2025, 00:45
cool, network and fat32 or ext, then we can rock the world, we need 256 colors minimum, if possible, highres and more colors,
 |
|||
|
06 Dec 2025, 00:45 |
|
|
SeproMan 06 Dec 2025, 20:54
The bootloader
A bootloader should be able to run successfully on real hardware, and sadly your bootloader won't achieve that! Next are the details that you need to be aware about: 1. BIOS starts your bootloader with just one piece of information in the DL register: the bootdrive id. All the rest is up to you to initialize. You are required to setup the segment registers and don't trust them to be in any particular state. Your 'mov [boot_drive], dl' instruction depends on a correct DS segment register, so you need to issue DS=0 in accordance with the 'org 0x7C00' setting. 2. BIOS operates in the Real Address Mode, therefore using an address like 0xB8000 can't possibly work like you think it will. All of your messages will have been sent to the regular low memory instead of to the video memory. You did not see this because the kernel got loaded real shortly after and it wrote to the screen in the correct fashion. 3. The 'int 0x13' instruction will make BIOS return a status in the carry flag. It is VERY IMPORTANT to inspect this flag and to NOT CONTINUE if the carry flag got set. Don't ever ignore the error reports that a service provides. The assembly In your assembly program you're not supposed to put your data in the execution path of the cpu! Right below that 'call print_string' the "title db 'TEXTEDIT.APP', 0x0D, 0x0A, 0" en "exit_command db 'exit', 0" data items will get erroneously executed by the cpu! Your wait loop will not operate as expected. The very first time through the 'delay1' loop the BP register will work with your setting of 3690, but all of the 3689 other times it will work with the value 0 (aka 65536 iterations, so that's about 17 times longer). Next is a correct nested loop construct: Code:
mov si, 3690
outer:
mov bp, 3690
inner:
dec bp
nop
jnz inner
dec si
jnz outer
Finally There's a lot more that can be said, especially about the many redundant bits of code, but those are not the immediate danger to care about. In time you will get better and as a consequence those imperfections will disappear naturally. Best of luck... _________________ Real Address Mode. |
|||
|
06 Dec 2025, 20:54 |
|
|
IsaacZ 07 Dec 2025, 17:00
SeproMan wrote: The bootloader Thank you for that information I will definitely fix all that eventually, I realize that my code is a bit clunky, I've recently been working on another more solid operating system. I'm probably not going to update OpenRodent for a few months since I'm a pretty new OS developer. For now I'll be learning more on computer hardware and assembly. Thanks again! |
|||
|
07 Dec 2025, 17:00 |
|
|
bzt 12 Dec 2025, 10:25
Hi
About the boot loader: everything that SeproMan said, plus you can't rely on CPU flags or the stack either. You must clear direction flag and set SP before you could use "int" or "push". Also you must start your boot loader with a short jump instruction because some BIOSes checks that (similar magic like 0xAA55 at 0x1FE). Take a look at my boot sector, it does all the necessary initialization (it also disables the PIC and NMI because it's about to change CPU mode). Also I would suggest to use INT13/AH=42 because that works with modern storage like USB sticks too. The rest of my code (everything after "parse the MFS superblock" comment) loads a file from a Minix3 file system, don't mind that part. About the higher resolution: it's not as simple you might think. VideoRAM is mapped to 0xA0000, and due to real mode addressing, you have just 64k. A 1024 x 768 x 32bpp mode's framebuffer (3145728 bytes) can't fit into that, so you must "page in" portions of that framebuffer, this is called "bank switching", and sadly there's no standardized way to do it (there's a BIOS int, but it's so slow, your screen will flicker). So if you don't want to write video drivers yourself, then banking SVGA is not a good option. You should use "linear VBE" instead. That maps the VideoRAM somewhere 0xE000000 continuously (that's why it's called "linear" framebuffer), but the downside is, then you must use protected mode to access that area (or maybe switch to "unreal" addressing, look it up. It's officially undocumented, but there are lots of example code and it's well-known to be supported). About the delay, I wrote example code on how to do it here. |
|||
|
12 Dec 2025, 10:25 |
|
|
IsaacZ 12 Dec 2025, 18:16
bzt wrote: Hi Thanks @bzt I will definitely take all that, Like I said, I've been working on a new solid & Light-weight CLI OS, called "OS/LIPROX" which I'll continually be updating to be a solid OS. Thanks again! |
|||
|
12 Dec 2025, 18:16 |
|
|
bzt 12 Dec 2025, 22:15
IsaacZ wrote: I've been working on a new solid & Light-weight CLI OS First, like I've said, consider using protected mode. Don't care about segmentation, paging, protection rings, etc. forget all of that. Just set up segments with base of 0 and limit of 0xffffffff and you're good to go (this is called flat memory model). You can care about those features later, when / if you want them, but for a single user, single threaded, CLI OS I don't think they are necessary. However being able to address the entire 4G memory with a single register is very very handy and will save you from lots of headaches later. There's a catch though, you'll need a wrapper function to call BIOS interrupts (switch to real mode, do int, switch back to protected mode). Good news, you only have to implement this once, and then you'll just do "call biosint" instead of "int". Second advice, for now it's okay to load stuff as-is from a raw image, but sooner or later you'll need a file system. Make sure that you add your boot files defragmented, and then you won't have to parse the file system in your boot sector, just adjust the first sector's lba in the BIOS int call to point to the first sector of the file content and you'll be good to go. Basically Code: now you have: [boot sector] [kernel] make it like this: [boot sector] ...some more data... [kernel] ...some more data... As for the file system itself I would recommend Minix3 because it's featureful yet easy to implement (both in generating from fasm source and to parse), or maybe FAT16 with 8+3 names because that has lots and lots of example code. I don't recommend FAT12 (too limited) nor FAT32 (lots of pitfalls, specially with the backup sectors and LFN), neither ext2/3/4 (even trickier, do not try to implement this as your very first file system). But it's up to you, whatever you want. Any kind of file system's meta data can be added to a fasm source with "db". |
|||
|
12 Dec 2025, 22:15 |
|
< Last Thread | Next Thread > |
Forum Rules:
|