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

Tried porting my 32 bit paging code to 64 bits...

i've been playing with bootBASIC. i've somehow broken variable assignment despite not changing anything at all to do with variable assignment or parsing. I've made `run` identical to `goto` to save 3 bytes, and removed `system` (exit) because i don't intend to run the dos version. it wasn't until i added and tried to test a statement to call machine code routines that i realised variable assignment is totally broken where it was fine in the original. there's nothing to see in a screenshot, it just goes into an infinite loop without displaying the prompt, but i created a monstrosity of a diff and thought i'd screenshot that. i was looking for places the binary code differed, but only discovered that everything is relative and there's (at least) 2 ways to assemble `add ax,0x14`. without a dos version of the program to debug with dos tools, i shall have to learn how to use gdb with qemu.

the script which produced this diff is itself a bit of a monstrosity. i hate making things like this 1 line, but terminals are too clever to accept multi-line pastes these days.
t1=/tmp/bb0; t2=/tmp/bbe; gawk '{sub(/^.{16}/, ""); print $0}' ../bootBASIC-master/basic.lst | egrep '^[^ \t]' > $t1; gawk '{sub(/^.{16}/, ""); print $0}' basic.lst | egrep '^[^ \t]' > $t2; cdiff -bu $t1 $t2; rm $t1 $t2

edit: found it almost by accident when taking one last look at the diff. turns out i'd mistaken a terminator for a version number. not many lists are 1-terminated. i should have known because all the name lengths are 1 more than you'd expect; i.e. `db 3,"if"`. smøl cöd issüz