OSDev.org

Something is wrong here, can't tell what.

I'm experiencing a wetware problem, (difficulty sleeping,) and did a bit of coding at the crack of dawn this morning to reset some (emotional) parameters. This BIOS 'hello world' started off well, but by the time I realized I ought to set up ES, the best I could think of was to copy it from CS. This was evidently not the right choice.

This took a while to figure out, but I did eventually! What was happening was I changed my boot loader to load the C kernel at 0x1100, but still linked the C kernel to 0x1000 (the previous loaded address). Enjoy the beautiful carnage of things I don't understand below.

My operating system decided the kernel was negative bytes in size. Truly the king of operating systems right here.

I got bored of my previous kernel panic "style", so I decided to spruce things up.

https://i.imgur.com/vZwEnAF.png

I really thought I could delay writing a bitmap font renderer until I get a basic userspace up and going, and just depend on Limine's write(), but apparently not! Fonts, here I come

First try on task manager.
https://www.youtube.com/watch?v=q8qkrRSUBVk

Getting WDH from the OHCI controller along with SO (Schedule Overrun) and SF (Start of Frame). But when I go to the DoneHead descriptor pointer, it's NULL like maybe the BIOS is still using the controller. Since there are two OHCI controllers in the system, I output a semicolon for 9:0:0 and a comma for 9:1:0 in case I get the "ghost WDH"

Achievement unlocked? It fills up the screen with pretty morse code. No idea how this sequence of events is happening. Yes, 9:0:0 starts with frame 5 and then ... frame 4 ... followed by 5.

A helpful stack trace from my OS clears everything up.

Accidentally passed the wrong function pointer when setting up the IDT, so instead of setting the int 0x40 handler to a function written in assembly which calls a function written in C, I set it to the C function it was supposed to call. And with the function not being a proper interrupt handler, things get weird when it returns. It looks like the background colour is getting changed, the screen is getting cleared to show a bunch of sigmas, some garbage is being printed, and a couple of inverted question marks on a black background are thrown in at various places near the horizontal middle of the screen. Well, after I fixed that mistake, the IDT seems to be working.

I try to add graphics shell in my os. It's drawn here https://github.com/Alexey1994/BelOS/blo ... ll2/main.c

This happens when you run a graphical program to draw on the framebuffer, then immediately run the `list` program to dump out a long text file. Looks kinda beautiful in a broken way

The visuals of this one aren't particularly visually impressive but it's been crazy and mind-blowing nonetheless. This happens every time my system boots on real hardware. I think it has to be an issue relating to the stack. I moved the stack to a different spot and now it gets further into the boot process before crashing so maybe i'm on to something.

AthenX-2.0 triggerd exceptions quit often in its early stages(not much has changed), so I built a exception handler that would dump as much detailed info as possible.
Sack trace
Memory map
Function translation from stack trace information