OSDev.org

Finally, I also have something to show.
In the last 2 days, I finished paging in my kernel and tried to 1:1 map the first GB of RAM.
And this is how it looks like if your PMM gives away the video-memory:

It was a FreeBASIC-specific rounding issue in my mark_used function, which lead to a wrong array index to my bitmap. Without that happening, finding that bug would have been really nasty

That looks very simular to jrepan's visual bug on page 5.

Yeah, it does. Maybe his paging code also had overwritten the video memory
However, my problem was that I used "/" for a division. In FreeBASIC, this gives me a float, and when I put a float into an integer, FreeBASIC rounds the value. So I got 5.75 rounded up to 6, which resulted in wrong array access. Using "\" performs an integer division and the output is 5. I was very confused when I compared the behavior of FreeBASIC and C when using "/" at first

death2all's screenshot also looks very similar, his code also put page tables in the video RAM ^^

haha common error on here, as it seems perhaps a mention in the wiki:
One time, I even managed it in 1024*768*32 mode, back when I was in my old (borked up) kernel, but I lost the screeny :'( not to worry. I might break my kernel when i go to GMode just to see what happens (on a backup copy, ofc)

Also works as an error handler!

don't know why... I was just reminded of the thread by this c error!
i must need to switch modes somehow,but forgot to because i wrote text-bode bits instead!



(i haven't been working on it for a while,actually. got back a day or 2 and now i'm doing relativly good.except this!)

This reminded me of a European Space Agency rocket called the Ariane 5, which had some code to correct the rocket's angle of trajectory. 40 seconds into the flight that code decides to convert a 64-bit float into a 16-bit signed integer, which, as integers are wont to do when you try to put too much data in them, overflowed. The rocket decided it was facing the wrong direction, so it aimed itself at the ground. Thankfully it was unmanned, and they had had the forethought to put a self-destruct system onboard, so they just blew it up. But if that had actually reached the ground it could have been catastrophic -- I read somewhere that if a fully-fuelled Saturn V rocket had exploded it would have been like a small nuclear bomb. Obviously the Ariane 5 is not the same size as a Saturn V but it's still basically a big tube filled with explosive chemicals.

Not exactly, nobody wanted to blew the rocket up. What truly happened is this: after the overflow, on board system core dumped the memory and sent it back to the main control centre on the ground. The computer there examined the input and said, hey what's that? the confirmation code for self-destruct? fine...

My OS has had "support" for swapping back to B8000 text mode when it kernel panics for a while... but I never really debugged it (no real need), so it causes some interesting effects when the OS crashes. However, this one really took the cake

It's from it crashing while running the GUI, blowing the GUI pixels up and treating them as characters it seems.

Not sure if you're trying to be funny. Read the full account here (pdf).


JAL

Really recommended reading. No-one really royally screwed up. In the end and at the core of it, the fault was re-using Ariane 4 parts without re-testing them to Ariane 5 specs. Plus a couple of bogus decisions on error handling.

Teaches you to think further than just fulfilling the contract. Oh, and document, document, document your assumptions.

Error occurred in GUI:

Shouldn't of swapped display pages...

Looks neat, do you have screenshots of the GUI in normal operation?


JAL

Yeah!
Here is what is should look like:

Deliciously old-skool!


JAL