Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jan 16, 2016 5:08 pm
Why not stick to the VGA font? Easy.akasei wrote:O'rly? Find me bitmap font at 8x8 pixels
OSDev.org
The Place to Start for Operating System Developers
http://f.osdev.org/
What does your OS look like? (Screen Shots..)
Page 139 of 262
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Jan 17, 2016 1:05 am
Why 8x8? I have WIP Unicode 8x16 font support.akasei wrote:O'rly? Find me bitmap font at 8x8 pixelscatnikita255 wrote:Great. But font is ugly.
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Jan 17, 2016 5:32 am
My school work. Now I have no time to engage in. Sorry, the English version does not exist.
Information devices:
Console command list:
Kolibri API emulation:
Information devices:
Console command list:
Kolibri API emulation:
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Jan 17, 2016 6:48 am
to shmx
This is pretty impressive! Could you give a link to the source code?
This is pretty impressive! Could you give a link to the source code?
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Jan 17, 2016 7:11 am
The source code is not open. At the moment, I am not ready to open the source code. I can show fragments of that's just you are interested (please write in PM). Actually, architecture of souce code is is very bad. I started to do it in 13 years. Now nothing can be correct (too much code). OS is written in C, compiler GCC (core), BCC(bootloader).
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Jan 17, 2016 7:29 am
I started doing a second version in C++11. I did allocators physical memory, virtual memory, heap, multitasking, smp... I take into account all the mistakes of last version. No time to do it now.
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Jan 18, 2016 1:29 am
My OS working again! With wallpaper AND clocks! Lots of Clocks! YAY!
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Jan 18, 2016 11:38 am
You are also Russian?shmx wrote:My school work. Now I have no time to engage in. Sorry, the English version does not exist.
Information devices:
Console command list:
Kolibri API emulation:
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Jan 18, 2016 1:13 pm
Yes. Does it matter?catnikita255 wrote:You are also Russian?
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Jan 18, 2016 10:09 pm
Hi,
My current boot code (very much subject to change)...
For 15-bpp:
And for 8-bpp ("3:3:2"):
Both of these images are generated for sRGB.
The code to generate these pictures involves:
Cheers,
Brendan
My current boot code (very much subject to change)...
For 15-bpp:
And for 8-bpp ("3:3:2"):
Both of these images are generated for sRGB.
The code to generate these pictures involves:
- Code to convert EDID into my own "Display Info Data" file format
- Code to generate a list of video modes; including using VBE 3.0 "CRTC info" to construct video modes that perfectly match the "Display Info Data" file's video mode timings
- Code to auto-select the best possible video mode (to suit the video card, display, OS, etc) using a whole bunch of heuristics
- A "log output" boot module (the piece that actually generates the image and blits it to frame buffer), that's running in its own sandbox at CPL=3 in its own virtual address space
- Temporary code to generate a background image (in 48-bpp device independent XYZ format).
- Code to generate a routine at run-time, where the resulting routine does "48-bpp device independent XYZ -> device dependent RGB", including gamma correct dithering; that takes into account:
- the display's primary colours
- the display's white point
- the display's gamma
- how many colours the display can actually show
- the video mode's pixel format
- Support for "RAM fault tolerance" (avoiding previously found faulty pages, testing pages before use, etc)
- Boot image/inital RAM disk decompression; with max. size of 1.5 GiB (decompressed), even if the OS failed to enable A20 and physical memory is completely fragmented
- Digital signature checks on all executable code, TPM "static root of trust" for (future) remote attestation
- CRC checks on all files used
- Pre-boot environment abstraction (only the first stage boot loader knows/cares what the firmware is - easy to add support for UEFI or anything else later)
- Full exception handling (and reporting register contents, etc at time of crash)
- Support for headless systems (no monitors) and support for multiple monitors (if boot loader can setup frame buffers)
- Lots of smaller things I've forgotten
Cheers,
Brendan
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jan 19, 2016 1:11 am
Questions for Brendan:
What kind of user options are allowed for setting the video mode? Is your auto-select heuristics subject to choose overly safe video modes? If users know that other unsafe video modes should work, are you allowing them to select those modes and possibly cause damage to their hardware? If there is a boot settings file or similar, is it possible to set a "override-all-heuristics" mode? Please note that it could still rule out "definitely-not-supported" cases. Perhaps it is all about how much uncertainty is allowed, e.g. you could say it is not possible to select a video mode with less than "50% reliablity" or something.
Is this the first time you generate a routine at run-time? Just a detail question, are you generating the run-time code by arranging instructions like data or like code? Perhaps this needs some clarification. Compare these two examples:
Do you see the difference? The first one is more like "data" and the latter is more like "code". I did not explain my point very well but there is a little difference between these two approaches. The end result is the same.
What kind of user options are allowed for setting the video mode? Is your auto-select heuristics subject to choose overly safe video modes? If users know that other unsafe video modes should work, are you allowing them to select those modes and possibly cause damage to their hardware? If there is a boot settings file or similar, is it possible to set a "override-all-heuristics" mode? Please note that it could still rule out "definitely-not-supported" cases. Perhaps it is all about how much uncertainty is allowed, e.g. you could say it is not possible to select a video mode with less than "50% reliablity" or something.
Is this the first time you generate a routine at run-time? Just a detail question, are you generating the run-time code by arranging instructions like data or like code? Perhaps this needs some clarification. Compare these two examples:
Code: Select all
section .text
Example:
mov eax, 0x00C3C081 ; eax = "rum-time code"
; Register eax contains code as "data"
; "xor eax, eax"
; "ret"
mov [RunTimeReturnZero+0], eax ; install "run-time code"
; Flush caches etc.
call RunTimeReturnZero ; run "run-time code"
ret ; return 0x00000000
section .runtime
align 16
RunTimeReturnZero: resb 16
Code: Select all
section .text
Example:
mov ecx, (CodeBlock1.End-CodeBlock1) ; ecx = size of code to copy
mov esi, CodeBlock1 ; ds:esi = source
mov edi, RunTimeReturnZero+0 ; es:edi = destination
cld ; clear direction flag
rep movsb ; copy "run-time code" as "code"
; Flush caches etc.
call RunTimeReturnZero ; run "run-time code"
ret ; return 0x00000000
section .codepool
CodeBlock1:
xor eax, eax ; eax = 0x00000000
ret ; return 0x00000000
.End: ; nop
section .runtime
align 16
RunTimeReturnZero: resb 16
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jan 19, 2016 4:14 am
I declare this the typo of the day!Code: Select all
rum-time code
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jan 19, 2016 4:44 am
Hi,
More specifically, it's a set of "snippets", where each one has some instructions and then a list of things to patch (e.g. "replace the dword at offset 33 within this snippet with the redX multiplier", "replace the relative jump target at offset 22 with the correct displacement for the end of the first snippet", etc). It analyses everything, chooses which snippets to combine and builds a "snippet list"; then allocates RAM for the routine and generates it by concatenating the selected snippets and patching them. The end result is a routine that's typically between about 160 instructions and 220 instructions; that has very few branches and where most "variables" (horizontal resolution, address of dynamically allocated lookup tables, etc) are hard-coded immediate data.
Cheers,
Brendan
There's no user options for controlling the video mode.Antti wrote:What kind of user options are allowed for setting the video mode?
If there's little/no information then there's a strong tendency towards 640*480. If there's information about the display but no information about the video card's video mode timing, then it's a little more relaxed. If there's information about the display and information about the video card's video mode timings; then you get the best possible compromise. However it also takes into account other things - for example; if the computer only has 64 MiB of free RAM then 1920*1600 can't be safe, because the OS would consume almost 50 MiB of RAM for buffers, etc and there wouldn't be enough RAM left to do anything else.Antti wrote:Is your auto-select heuristics subject to choose overly safe video modes?
The provision of these things is an admission that the system (hardware + software) failed to be fit for the purpose it was intended. It works without end user hassle/configuration, or it deserves to go in the trash.Antti wrote:If users know that other unsafe video modes should work, are you allowing them to select those modes and possibly cause damage to their hardware? If there is a boot settings file or similar, is it possible to set a "override-all-heuristics" mode? Please note that it could still rule out "definitely-not-supported" cases. Perhaps it is all about how much uncertainty is allowed, e.g. you could say it is not possible to select a video mode with less than "50% reliablity" or something.
It's not something I've done before (and not something that usually makes sense).Antti wrote:Is this the first time you generate a routine at run-time?
Antti wrote:Just a detail question, are you generating the run-time code by arranging instructions like data or like code? Perhaps this needs some clarification. Compare these two examples:
It's more like the latter (instructions arranged like code).Antti wrote:Do you see the difference? The first one is more like "data" and the latter is more like "code". I did not explain my point very well but there is a little difference between these two approaches. The end result is the same.
More specifically, it's a set of "snippets", where each one has some instructions and then a list of things to patch (e.g. "replace the dword at offset 33 within this snippet with the redX multiplier", "replace the relative jump target at offset 22 with the correct displacement for the end of the first snippet", etc). It analyses everything, chooses which snippets to combine and builds a "snippet list"; then allocates RAM for the routine and generates it by concatenating the selected snippets and patching them. The end result is a routine that's typically between about 160 instructions and 220 instructions; that has very few branches and where most "variables" (horizontal resolution, address of dynamically allocated lookup tables, etc) are hard-coded immediate data.
Cheers,
Brendan
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jan 19, 2016 7:24 am
No. But your OS is very cool.shmx wrote:Yes. Does it matter?catnikita255 wrote:You are also Russian?
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jan 19, 2016 10:17 am
Can you elaborate? I can't find any information about a 48 bit graphics format on the web. Did you create it yourself?Brendan wrote:Temporary code to generate a background image (in 48-bpp device independent XYZ format).
Code to generate a routine at run-time, where the resulting routine does "48-bpp device independent XYZ -> device dependent RGB", including gamma correct dithering; that takes into account: