Devblog 5

Livefetch is being shipped.
Now that version output shows the version of livefetch being the full release. I have updated it for homebrew and the README is complete.
Now any mac user will be able to use this system monitor.
–WilGulf

#Devblog 4
I know I said the info was done, but here comes more.
Using many of apples APIs we now can get the GPU model, battery and display stats.
Livefetch also supports homebrew as the package manager you can install livefetch on your own system with, but also livefetch can track the amount of packages installed with homebrew.
Hope to soon ship!
–WilGulf

#Info complete
Now i have got so much system info on macos.
Memory, swap, disk, local-ip, system locale and much more. But that i got working after much much time.
Soon ready for first release for macos.
–WilGulf

#Real info
Finally all info shown is the real data from the system. Now it is now you can see how the updating works. And no i do not use RHEL i just like the tuff logo.
–WilGulf

#10h
I don’t have anything to show right now, but as you can see i have 11 more hours on this project.
I have both been working on fixes and some new things needed for the next big thing being: getting to ring 3/usermode.
–WilGulf

livefetch

When larping a linux distro you always need fastfetch/neofetch open. But the problem with those are that the info displayed gets outdated, after just a minute the ram usage could be completely wrong.
This fastfetch like project shows the info live and that darker line looping through is what updates the info.
Now both the info and logo shown is just a test and not real system information. This is just for testing.
In the background there is a config read when starting the program that determines the logo and if that darker line should be shown.
Later comes actually implementing a way to get that information on all the different operating systems.
–WilGulf

Now we got progress!

The kernel now has my implementation of paging working. If you don’t know what paging is, it is basically a way of managing the memory that is used by most x86 operating systems.
The paging implementation took some C files and some updates to the assembly files but now it is done!
Now I have many ways to go with what to implement next. We’ll see what i choose.
–WilGulf

My webOS

I took a break from developing my actual OS (NeoOS) and tried making a webOS like many others.
Now I got my first app open that also can be closed.
I also started on a dock and some animations for it. You may think this look really close to macOS and that is exactly what i try to make it look like, or more exactly macOS 12 monterey.
–WilGulf

IDT Done!

Now I got the IDT working. You can see it is working cause when that “Divide By Zero” message appears the kernel does a division with a zero. Normally that would make the kernel start bootlooping but now the interrupt handler handles the divide by zero and stops the kernel instead.
Interrupt handling does not only stop crashes but also allow keyboards or syscalls to invoke interrupts that the kernel can process.

Next step may be to use that interrupt handler to implement syscalls.
– WilGulf

Hello

Yes we got it, hello world on the screen. Turns out the loading of the kernel set up the stack wrong. One line of assembly was in the wrong section.
I also continued with the GDT. It isnt something you can see but in the background the GDT has been initialized.
That is my progress so far, now after GDT comes some interrupt handling.

–WilGulf

HELP

What is wrong?

Well as I said, I would continue with getting Hello World on the screen. Well that wasn’t hard to do the “simple” way, just pasting several lines for each letter. But I wanted to do it the real way, implement a writer function.

1. I started with making a function to clear the framebuffer from that “Booting…” message. And also moving the cursor to the start.
2. Then I continued with the writer. The writer took two parameters: (char *buf, unsigned int len). Both arguments needed.
3. The function i began testing with calling it from kmain like this: writer(“hello”, 5) .
4. Then in the function i processed it like this:

unsigned char *bytes = (unsigned char *)buf;
for (unsigned int i = 0; i < len; i++) {
fb_write_cell(pos * 2, bytes[i], 0x0F, 0x00);
pos++;
}

But thats where it went wrong. When compiling and booting after adding that function content it wouldn’t boot.
And that is wierd cause when i removed the bytes[i] line it booted. Somehow my kernel cant handle it. I don’t know what could currently be causing this.

What now?

Well i will of course try to solve this myself or find a way to make the writer work.
And if you have any knowledge in C and os development please help me.
The projects current code can be found on my github.

– WilGulf

Settings, yay!

Had to learn how swifts UserDefaults to store the chosen haptic. I had a really hard time to get the menu to show the correct one when entering the settings. Somehow it would always default to start. Turns out all i needed was to update the selected one on appear.
But now we are done with the settings and just some final touches left and we’ll see if I can maybe make this look better.

The basics done!

The core function is done, you get the slider to choose the bpm and a button start and stop.
The haptics also works, right now using the ‘start’ haptic.
You may have noticed the settings button. I am working on letting you choose which haptic type the metronome uses. But that page is not ready to be shown yet.

I got my OS booting without entering a bootloop!!!

I wanted to leave assembly and start to use C. But to do that I need to call the main function in C from assembly.
Much googling and testing later I got it to actually use the main functions while loop to keep itself from bootlooping. Never thought i would be so happy about completing the first and easiest task in os development.
I will comeback with another post when i get ‘hello world’ on the screen.