When your OS goes crazy - Screenshots

[saltq]

Something is wrong here, can't tell what.

[eekee]

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.

[techdude17]

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.

[techdude17]

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

[IsaccBarker]

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

[CorruptedByCPU]

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

[sounds]

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.

[dlandahl]

A helpful stack trace from my OS clears everything up.

[SeaLiteral]

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.

[Alexey1994]

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

[brain]

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

[SomeGuyWithAKeyboard]

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.

[KingVentrix007]

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

[andyloris]

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

[eekee]

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