OSDev.org

pvc wrote:@TimothyWilliams I'm glad you like it

And you managed to port GCC, what next? Python, Assembler, web design, or what?

GCC is actually not ported. It's just sitting there and waiting. I was getting it to almost work, but not exactly. I think binutils is done but disabled for now.

Hi all,

I'm back in the game. I don't know for how long, but I'm back.
Just started to work on an UEFI bootloader: Also added multi-user features: I hope to put my GUI back on my OS one day...

Hi,
I'm back after more years!
This is my new 2019 "co-kernel" version, able to

- Launch Win32 code files (With few NT functions)
- Launch Clang/LLVM code files
- OpenGL & GZE 3D engine + displayer
- Customizable animated bootscreen
- Multi-OS The performances remain correct
- Network UDP/TCP client server, telnet, Serial RS232
- Garbage collector
- Multi-threading
- Powerfull GUI (Checkbox, windows, progressbar, picturebox....) and console
- Include POO CpcdosC+, C/C++, BASIC programing language (Python HTML/CSS in building)
- Very few DOS dependencies


Starting + OpenGL tests 1 :
https://www.youtube.com/watch?v=k37PGs592AA

OpenGL tests 2 (2 meshs + Shadow) :
https://www.youtube.com/watch?v=85T0fYL_SVo

An example of an OS based on Cpcdos created by a young Canadian (Guillaume)

His first version called "ElieOS"

Regards

Doesn't have many features in my 'os', but it's the first time I have ever created simple task scheduler and it's even working.
Two processes incrementing values in different intervals
Simple memory manager, which I had to debug, because it was allocating memory where my kernel exists... so many hours wasted
Terminal in 13h mode with pre-rendered font (took most of my kernel size, lol) with support for displaying string, hex, decimal and binary values.

I hope that someday I will have graphics mode with some window manager, etc. But don't know when, I wanted to create 16-bit OS, but decided few days ago that 32-bit may be easier. I know that I can't use BIOS, but I have whole memory without segmentation.

@cybek: That chunky text makes me nostalgic! I wanted to make a 16-bit OS too, but now I'm not so sure either. If I 'just' make a Forth system, I might put it into unreal mode and make a "double-indirect threaded" interpreter. With that, definitions are just lists of addresses, so interpreted code could go into 32-bit space with the data and the VESA graphics framebuffer. Only the relatively small amount of machine code would need to go in low memory. I don't know, though; got no solid OS plans at present.

BTW, everyone's experienced at least one really frustrating bug. If that was your first, welcome to the club, you're a real programmer now!

eekee wrote:@cybek: That chunky text makes me nostalgic!

If you would like to know, it's this font: https://fonts.google.com/specimen/Press+Start+2P
I wanted to enable 13h mode before entering protected mode, and be able to print some text, so I was looking for pixelated font, which can be rendered as small as possible.
I'm happy that you like this font
I have made a program that renders whole ascii table, compress it to bitwise array and creates ASM file which can be included in kernel. It's huge compared to rest of the kernel.

I wanted to make a 16-bit OS too, but now I'm not so sure either. If I 'just' make a Forth system, I might put it into unreal mode and make a "double-indirect threaded" interpreter.

Yea, 16-bit OS feels more nostalgic, but making it is a pain. It's more difficult because of architecture, but it's easier because you have BIOS routines. 32-bit is simpler because of linear memory, but harder because of lack of BIOS. Maybe some ARM OS then?

BTW, everyone's experienced at least one really frustrating bug. If that was your first, welcome to the club, you're a real programmer now!

Haha, thanks But unfortunately it's not my first bug, just recent one

cybek wrote:If you would like to know, it's this font: https://fonts.google.com/specimen/Press+Start+2P

Thanks! And yeah, font data is huge at this stage. It's possible to go a little smaller, down to 6x8 without merging lines, but not with style. Re. BIOS convenience, perhaps UEFI could make up for the lack of it? I don't want to post too much in the screenshot thread.

Hi,

My little operating system Soso is finally able to run Doom

https://github.com/ozkl/soso

It is a 32 bit x86 OS with multitasking support.
Doom runs on mmap'ed framebuffer device (/dev/fb0).
All the data is in initrd which is mounted as a FAT32 image (yes, it supports VFS and FAT32).

By the way, I found very hard to implement pseudo TTY system (master and slave devices) and supporting VT-100 like terminals. So i went my own poor way

Here two doom processes are running in different TTYs on the same framebuffer device.

The 32-bit version of my Operating System:


Currently working on a 64-bit version and I am planning to go full 64, but there is not much to see.

Not much, but after coming back to my bootloader project, I got memory detection working (I think!)

This is Mako. I've been working on it for the last ~6 months, and it I think it finally does enough to be a real "operating system"[1].

https://github.com/AjayMT/mako



Huge thanks to the OSDev community for all the help and resources, I never thought I would be able to do anything like this. My operating system is not complete or perfect (and likely never will be) but I'm proud of it nevertheless. I feel like I can build literally anything now that I've done this.

[1]: It reads and writes files and runs user programs.

@ajaymt: Always good to see alternative window management! It looks really nice, too. A small note of caution though: I've used a system which fades the text in non-current windows, like yours does. While it's great that it shows so clearly which is the current window, it becomes a bad thing when you're trying to read documentation or notes in one window while typing into another. Also, it's confusing when a window holds a program which doesn't fade.

Mine is a 86-DOS clone, with a 32-bit kernel 'overlay'.

The system starts in real-mode, with the files 'IO.SYS', and 'RMDOS.SYS', and the user can choose to boot into the 32-bit system (doskrnl.exe - microkernel), or remain in 16-bit RMDOS (execution monitor).

doskrnl.exe is loaded exactly past 1MB, while rmdos.sys and io.sys remain in conventional memory, along with the PC-BIOS. if the user is in the 32-bit system, if they run a .com file, the system goes back to real-mode, runs the .com file or 16-bit .exe file, and then goes back to the protected-mode system.

I don't have any pictures of it running, atm, but I have this screenshot of a sorta 'pseudo disk layout':

LAI's hardware support gets better and better. Here is @Matt8898 from GitHub who implemented a few missing opcodes and successful booted LAI on his "laptop".

(For those who don't know about it already, LAI is an AML interpreter: https://github.com/qword-os/lai)