OSDev.org

Posted: **Thu Jul 30, 2015 1:37 pm**

Something went wrong with my printf implementation...

Posted: **Fri Jul 31, 2015 11:34 am**

It's because I forgot one line of code:

mov byte[is_program_running], 0

Posted: **Sun Aug 02, 2015 1:00 pm**

Significant interleaving of serial port log messages whilst I was stress-testing the scheduler:

Code: Select all

vfmoLodfs./
tyggs.vf
es:r. Logmoengetr: dferenisoterng ins_messsfag .rmectagssaore ge y:loloop
op
voofstfs: ent ent: ererining messag Moge lunootp
m: esmosauntingg te loop
ysos.rootfs to /

I should probably do something about that.

Regards,
John.

Posted: **Tue Aug 04, 2015 10:42 pm**

Not really sure why this is happening, something to do with my double buffering implementation

EDIT: I eventually figured it out, main issue was the size of the kernel after including that wallpaper data as a header exported from GIMP, it'd go from 17kb to 8MB
EDIT2: Actually seems like the problem might be something deeper than that, everything is fine if I copy the translated GIMP output into an array first and then just copy that to the framebuffer.
EDIT3: Finally found the problem, buffer overflow because GIMPS macro assumes that data will only be read once.

Posted: **Sun Aug 09, 2015 4:09 am**

I have this strange suspicion it didn't actually allocate a block....

Posted: **Tue Sep 08, 2015 9:44 pm**

Well, setup multithreading, AHC and EXT2 parsing since my last post so I was trying my hand at loading an image from disk, this is the spectacular close but not there yet outcome:

Posted: **Sun Sep 13, 2015 11:31 am**

When I finally managed to compile my kernel from a year ago again:

Posted: **Mon Sep 14, 2015 3:22 pm**

Editing console rendering code always goes wrong. Today the redraw logic (used for scrolling and such) only updated a fourth of the screen, while the normal single-character rendering code continued to work.

Posted: **Tue Sep 22, 2015 10:15 am**

This photo is a bit old, but it shows quite accurately what happens when you don't check the framebuffer type (pixels or chars) that GRUB gives you:

On the other hand, it means that I used the rest of the info correctly.

Posted: **Wed Sep 23, 2015 1:56 pm**

I was adjusting my panic() routine to send NMIs to the other cores causing them to also dump stack traces.
as they all got the NMI at the same time they all dumped their stack traces at the same time, they got interleaved

Posted: **Sat Oct 10, 2015 4:11 am**

Hmm.. Looks fine.
Let's test out my new scroll() function

... fail

Posted: **Thu Oct 22, 2015 1:19 am**

A couple of days old, it's a test of my object allocator with SMP.
Unsynchronized serial output FTW.

Posted: **Thu Oct 29, 2015 9:00 am**

When something really went wrong:
Printing text when SUDDENLY interrupt arrives

Posted: **Thu Oct 29, 2015 11:08 am**

ThiHellos iHellos HelloHelloindeeHellod verHelloy fuHellonny

Posted: **Wed Dec 02, 2015 9:14 pm**

bug in my printDec( ) caused an infinite loop, and also a cool gradient

OSDev.org

When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots

Re: When your OS goes crazy - Screenshots