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

[crunch]

Finally got my 64-bit OS working! I had many troubles with paging. Implementing "recursive mapping" helped me a lot.
I'm focusing now on the 64-bit version. Next big step: adding UEFI support (won't be easy).

Obsidian64.jpg

Looks nice. I recently moved everything over to 64 bit as well. I'm at a stumbling block with recursive mapping though... Are you using mcmodel=large or kernel? I've played around with both, and can't seem to wrap my head around how to do the recursive mapping properly when using mcmodel=kernel

[f2]

Finally got my 64-bit OS working! I had many troubles with paging. Implementing "recursive mapping" helped me a lot.
I'm focusing now on the 64-bit version. Next big step: adding UEFI support (won't be easy).

Obsidian64.jpg

Looks nice. I recently moved everything over to 64 bit as well. I'm at a stumbling block with recursive mapping though... Are you using mcmodel=large or kernel? I've played around with both, and can't seem to wrap my head around how to do the recursive mapping properly when using mcmodel=kernel

I don't use gcc at all, my OS is entirely written in assembly!

[Korona]

Finally got my 64-bit OS working! I had many troubles with paging. Implementing "recursive mapping" helped me a lot.
I'm focusing now on the 64-bit version. Next big step: adding UEFI support (won't be easy).

Obsidian64.jpg

Looks nice. I recently moved everything over to 64 bit as well. I'm at a stumbling block with recursive mapping though... Are you using mcmodel=large or kernel? I've played around with both, and can't seem to wrap my head around how to do the recursive mapping properly when using mcmodel=kernel

-mcmodel only affects the size of offsets that GCC generates, for example to access variables in your static data segment. In particular it does not interact with paging it all (other than restricting the addresses you can link your kernel to). -mcmodel should always be set to kernel (unless your static kernel image is larger than 2 GiB but I really hope that this is not the case ). It does not restrict the pointers you handle yourself.

[crunch]

Finally got my 64-bit OS working! I had many troubles with paging. Implementing "recursive mapping" helped me a lot.
I'm focusing now on the 64-bit version. Next big step: adding UEFI support (won't be easy).

Obsidian64.jpg

Looks nice. I recently moved everything over to 64 bit as well. I'm at a stumbling block with recursive mapping though... Are you using mcmodel=large or kernel? I've played around with both, and can't seem to wrap my head around how to do the recursive mapping properly when using mcmodel=kernel

-mcmodel only affects the size of offsets that GCC generates, for example to access variables in your static data segment. In particular it does not interact with paging it all (other than restricting the addresses you can link your kernel to). -mcmodel should always be set to kernel (unless your static kernel image is larger than 2 GiB but I really hope that this is not the case ). It does not restrict the pointers you handle yourself.

I'm aware of that, but using mcmodel=kernel necessitates that you can't put the recursive mapping in the last entry. I just haven't been able to successfully implement recursive mapping at a different location, but then again, I haven't put too much effort into it yet

I don't use gcc at all, my OS is entirely written in assembly!

Just curious, are you linking into elf format or just a flat binary blob?

[gerryg400]

I'm aware of that, but using mcmodel=kernel necessitates that you can't put the recursive mapping in the last entry. I just haven't been able to successfully implement recursive mapping at a different location, but then again, I haven't put too much effort into it yet

No it doesn't. What makes you think that?

[f2]

Just curious, are you linking into elf format or just a flat binary blob?

My kernel is just a plain binary file.

[robbiedobbie]

I'm aware of that, but using mcmodel=kernel necessitates that you can't put the recursive mapping in the last entry. I just haven't been able to successfully implement recursive mapping at a different location, but then again, I haven't put too much effort into it yet

You mean that putting your kernel on address -2gb results in not being able to recursive map your last entry. This however is no issue, just use another entry for recursive mapping (I used index 256). This gives me the following memory map:

Code: Select all

| Start            | End              | Usage                       |
| ---------------- | ---------------- | --------------------------- |
| ffff800000000000 | ffff808000000000 | Recursive pagetable mapping |
| ffff808000000000 | _kernelBegin     | Large static allocations    |
| _kernelBegin     | _kernelEnd       | Kernel image                |
| _kernelEnd       | ffffffffffffffff | Kernel heap                 |

In which obviously the usage is just a convention I'm using for my kernel. _kernelBegin is located at ffffffff80000000.

Calculating the address to acces a certain entry with the recursive mapping at a different entry can be done with:

Code: Select all

void* entriesToAddress(uint64_t pml4, uint64_t pdp, uint64_t pd, uint64_t pt) {
  uint64_t address = (pml4 << 39);

  if((address & (1ll << 47)) > 0) {
      //We need to sign extend
      address |= 0xFFFF000000000000UL;
    }

  address |= pdp << 30;
  address |= pd << 21;
  address |= pt << 12;
  return (void*)address;
}

//Querying the different pagetable levels:
PageMapLevel4* pml4 = (PageMapLevel4*)entriesToAddress(RECURSIVE_ENTRY, RECURSIVE_ENTRY, RECURSIVE_ENTRY, RECURSIVE_ENTRY);
PageDirectoryPointer* pdp = (PageDirectoryPointer*)entriesToAddress(RECURSIVE_ENTRY, RECURSIVE_ENTRY, RECURSIVE_ENTRY, pml4Entry);
PageDirectory* pd = (PageDirectory*)entriesToAddress(RECURSIVE_ENTRY, RECURSIVE_ENTRY, pml4Entry, pdpEntry);
PageTable* pt = (PageTable*)entriesToAddress(RECURSIVE_ENTRY, pml4Entry, pdpEntry, pdEntry);

[crunch]

Calculating the address to acces a certain entry with the recursive mapping at a different entry can be done with:

Code: Select all

//Querying the different pagetable levels:
PageMapLevel4* pml4 = (PageMapLevel4*)entriesToAddress(RECURSIVE_ENTRY, RECURSIVE_ENTRY, RECURSIVE_ENTRY, RECURSIVE_ENTRY);
PageDirectoryPointer* pdp = (PageDirectoryPointer*)entriesToAddress(RECURSIVE_ENTRY, RECURSIVE_ENTRY, RECURSIVE_ENTRY, pml4Entry);
PageDirectory* pd = (PageDirectory*)entriesToAddress(RECURSIVE_ENTRY, RECURSIVE_ENTRY, pml4Entry, pdpEntry);
PageTable* pt = (PageTable*)entriesToAddress(RECURSIVE_ENTRY, pml4Entry, pdpEntry, pdEntry);

Thanks, this snippet of code cleared it up for me!

[Sik]

Finally added something to the taskbar:



Since this thing is single tasking (eventually having programs save their state when quitting so they can be restored when loaded back), all the "Apps" button does is just load the desktop application (what you see here). Really, not different from the home button on modern phones. Still seeing what to do with the rest of the taskbar (the idea was to add icons for recent programs but not sure how that'd pan out).

As for the calculator, got multiplication working now =P

[MajickTek]

Finally added something to the taskbar:



Since this thing is single tasking (eventually having programs save their state when quitting so they can be restored when loaded back), all the "Apps" button does is just load the desktop application (what you see here). Really, not different from the home button on modern phones. Still seeing what to do with the rest of the taskbar (the idea was to add icons for recent programs but not sure how that'd pan out).

As for the calculator, got multiplication working now =P

Now that is really cool. I never even thought of something like that!

[MajickTek]

https://github.com/szhou42/osdev
My first GUI (looks familiar? )

It looks almost like the beginnings of ToaruOS to me. Nice work! I think the buttons are upside-down (light goes on top?) Other than that, it's simply amazing.

[prasoc]

my first baby steps here. just got drawing pixels and terminal font support in

working on implementing a filesystem now, then I can finally start developing a way to open "windows" (small buffers of memory that you can draw on)

one question however: what is the best way to achieve screen "updates"? do you have a ticker that updates once every 1/60th a second or something?

[BrightLight]

one question however: what is the best way to achieve screen "updates"? do you have a ticker that updates once every 1/60th a second or something?

Personally, I redraw the screen whenever it needs an update, which is whenever the mouse cursor is moved, a window is dragged, or an application specifically requests a redraw after writing to the window canvas. I also support a locking technique that prevents the screen from being updated until the back buffer is entirely ready to be displayed. A heavily optimized SSE memcpy is always useful here.

[zesterer]

one question however: what is the best way to achieve screen "updates"? do you have a ticker that updates once every 1/60th a second or something?

Personally, I redraw the screen whenever it needs an update, which is whenever the mouse cursor is moved, a window is dragged, or an application specifically requests a redraw after writing to the window canvas. I also support a locking technique that prevents the screen from being updated until the back buffer is entirely ready to be displayed. A heavily optimized SSE memcpy is always useful here.

Presumably though it doesn't redraw on *every* update though? You'd end up redrawing a ridiculous number of times. I presume it's capped at something reasonable like 50-60Hz?

[SpyderTL]

my first baby steps here. just got drawing pixels and terminal font support in

working on implementing a filesystem now, then I can finally start developing a way to open "windows" (small buffers of memory that you can draw on)

one question however: what is the best way to achieve screen "updates"? do you have a ticker that updates once every 1/60th a second or something?

That's really impressive. How long have you been working on this?

In some ways, you're ahead of me, and I've been doing this for around 8 years now...

The easiest approach is just to redraw everything as needed, but it's too slow for every day use.

Depending on whether you want to support transparency or non-rectangular render boundaries, there are some tricks you can use to speed things up. But essentially, you just want to update only what is strictly necessary, and draw things in reverse order, from furthest to nearest.

Eventually, if/when you get access to 2D/3D hardware acceleration, then you can really speed things up and add some impressive effects. But that's really probably one of the last things you should spend time on.

Still, nice work!