What does your OS look like? (Screen Shots..)

[xvedejas]

Heey Valix, that looks good!

But are that blue and dark-purple pixels above the green rectangle supposed to be there?

I'm pretty sure that's from uninitialized memory; I don't bother to clear the screen

[Synon]

Heey Valix, that looks good!

But are that blue and dark-purple pixels above the green rectangle supposed to be there?

I'm pretty sure that's from uninitialized memory; I don't bother to clear the screen

I don't see any :S

[StephanvanSchaik]

Heey Valix, that looks good!

But are that blue and dark-purple pixels above the green rectangle supposed to be there?

Not seeing any, are you sure your LCD-screen or TFT-screen doesn't have any defect pixels?


Regards,
Stephan J.R. van Schaik.

[fronty]

The blue pixel is definitely there. If it isn't, I'm selling a screen which has magical dead pixel which moves when you scroll.

[StephanvanSchaik]

The blue pixel is definitely there. If it isn't, I'm selling a screen which has magical dead pixel which moves when you scroll.

I had to put my hands on the screen to actually see it, but I only see one, so I'm wondering if there are any others.


Regards,
Stephan J.R. van Schaik.

[Firestryke31]

My latest project, the Vixen UEFI implementation for BIOS-based computers, similar to Intel's DUET. Why not just use that, you ask? Well, why not just use Windows, Linux or OS X? So far it has a partition bootsector that will parse the EFI partition file system (big whoop, it's just FAT32), load /EFI/VIXEN/VIXENROM.BIN, and run it. That will then set up the basic environment, go to protected mode, and run the C code there. That will then set up the text output driver, and use it to output a string. I'm so thrilled, I made the screenshot animated.


Ooh, fancy!

I still have an absolutely massive to do list (the tables I do have are half-implemented if even that, and I'm not even to the point where I can use that shiny new CRC32 function I needed help with earlier) but the fact that I know how to implement the protocols definitely will help speed things up.

[xvedejas]

Really simple font driver now



[EDIT] updated screenshot

The text scrolls up as it is printed, just as expected. I need to implement some sort of cursor so that text input looks more natural. I made the font myself, you'll notice that each character fits in a 5x6 space, which lets me represent each letter as a 32-bit integer. It's convenient for the time being.

[Neolander]

After months of design considerations, documentation hell, various wall-banging, slow coding, and computer overheating due to Bochs, I'm finally one step closer towards being done with my bootstrap 32-bit kernel and starting work on the 64-bit C++ one. Because finally, I'm done collecting information needed for the main kernel to boot. I feel so proud, right now...

I know, it sucks compared to what's around. It's just some debug info displayed using some debug routines (that I'm proud of too) in a pretty fashion. But well... I guess that's what parents feel facing their child who just stood.

[f2]

Really simple font driver now

The text scrolls up as it is printed, just as expected. I need to implement some sort of cursor so that text input looks more natural. I made the font myself, you'll notice that each character fits in a 5x6 space, which lets me represent each letter as a 32-bit integer. It's convenient for the time being.

Wow. That's look great! I like also this font. A bit small but I like

[neonz]

After two months, finally got somewhere.

Screen after booting and demonstration of VER and UPTIME commands of SHELL program:

And I've ported Brainfuck interpretator (of corse, it was more work with fixing bugs in my C library, than doing anything with bfi.c).

[rJah]

I just got threads to work, woooohoooo

tasks1.png (2.82 KiB) Viewed 4722 times

[Synon]

On this I have a working GDT and IDT and a semi-working IRQ handler (which doesn't seem to re-enable interrupts before leaving, so only one clock tick is displayed (even though immediately before IRET it executes STI)).

Anyway, here's a screenshot of it during booting. The function that prints the boot splash is called hooray().

[piranha]

On this I have a working GDT and IDT and a semi-working IRQ handler (which doesn't seem to re-enable interrupts before leaving, so only one clock tick is displayed (even though immediately before IRET it executes STI)).

Are you sure you're ack'ing the interrupt?

-JL

[Synon]

On this I have a working GDT and IDT and a semi-working IRQ handler (which doesn't seem to re-enable interrupts before leaving, so only one clock tick is displayed (even though immediately before IRET it executes STI)).

Are you sure you're ack'ing the interrupt?

-JL

I reset the PICs as soon as an IRQ is called, so yes. I'll see if other interrupts (non-clock related ones) work after the clock interrupt...

Code: Select all

if (rs.interrupt >= 40)
		outb(0xA0, 0x20); /* Reset slave */
	outb(0x20, 0x20); /* Reset master */

Edit: Also, putting this:

Code: Select all

for (;;)
        sti();

made the clock work; so it seems most likely a problem with enabling interrupts again.

[froggey]

even though immediately before IRET it executes STI.

You don't need to do this, in fact it's probably a bad idea: if your code gets interrupted while IRQs are disabled, for example because of a CPU exception, you would end up briefly enabling IRQs even if the code was expecting them to be disabled. IRET will automatically load the copy of eflags that got saved on the stack when the interrupt occurred, and that will restore the state of IF (the IRQ enable bit in eflags).