Page 191 of 262
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Feb 05, 2017 3:01 pm
by crunch
f2 wrote: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
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Feb 05, 2017 3:37 pm
by f2
crunch wrote:f2 wrote: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!
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Feb 05, 2017 3:56 pm
by Korona
crunch wrote:f2 wrote: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.
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Feb 05, 2017 4:29 pm
by crunch
Korona wrote:crunch wrote:f2 wrote: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
f2 wrote:
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?
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Feb 05, 2017 11:45 pm
by gerryg400
crunch wrote: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?
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Feb 06, 2017 2:21 am
by f2
crunch wrote:Just curious, are you linking into elf format or just a flat binary blob?
My kernel is just a plain binary file.
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Feb 06, 2017 3:53 am
by robbiedobbie
crunch wrote:
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);
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Feb 07, 2017 12:30 pm
by crunch
robbiedobbie wrote:
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!
Re: What does your OS look like? (Screen Shots..)
Posted: Wed Feb 08, 2017 7:44 am
by 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
Re: What does your OS look like? (Screen Shots..)
Posted: Thu Feb 09, 2017 6:26 am
by MajickTek
Sik wrote: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!
Re: What does your OS look like? (Screen Shots..)
Posted: Thu Feb 09, 2017 10:27 am
by MajickTek
szhou42 wrote: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.
Re: What does your OS look like? (Screen Shots..)
Posted: Fri Feb 10, 2017 8:30 am
by 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?
Re: What does your OS look like? (Screen Shots..)
Posted: Fri Feb 10, 2017 1:31 pm
by BrightLight
prasoc wrote: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.
Re: What does your OS look like? (Screen Shots..)
Posted: Fri Feb 10, 2017 7:21 pm
by zesterer
omarrx024 wrote:prasoc wrote: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?
Re: What does your OS look like? (Screen Shots..)
Posted: Fri Feb 10, 2017 7:47 pm
by SpyderTL
prasoc wrote: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!