What does your OS look like? (Screen Shots..)
Re: What does your OS look like? (Screen Shots..)
Nice one - I know how much work you put in to the "behind the scenes reliability", too. Good to see how far it has come on. Out of interest, is the "% reliable" rating a measure of your confidence of whether a video mode is likely to work on the current adapter / monitor? If so, how do you arrive at that figure?
Interesting to see that 640x480x32 has such a low reliability rating, but I guess that most adapters don't bother with such a high colour value at such a low resolution...
Cheers,
Adam
Interesting to see that 640x480x32 has such a low reliability rating, but I guess that most adapters don't bother with such a high colour value at such a low resolution...
Cheers,
Adam
Re: What does your OS look like? (Screen Shots..)
Hi,
Here's the font data at 2 different sizes (top left is 6 * 8 pixels per character; the squares with diagonal lines correspond to "undisplayable" control characters):
The boot code itself allows several of these "display modules" at the same time (e.g. you could use 4 display modules, and send to boot log to the video card, serial port, network card and sound card all at the same time).
For each video mode listed by VBE, I try to create additional "derived" video modes. If the video card supports it, my code can use double scanned mode and CRTC timing information; so that (for e.g.) for one "1024 * 768, 32-bpp" video mode reported by VBE I might end up with:
Then I use the EDID information from the monitor to estimate the probability that the monitor will be able to handle each video mode. This is complicated, because it's impossible to determine the video card's timing (without forcing the video card to use your own CRTC timings), and therefore impossible to determine if the horizontal frequency and vertical frequency is within the monitor's limits. For example, a video card might report a 800 * 600 video mode, and the monitor might support 800 * 600 at 60 Hz but might not support 800 * 600 at 75 Hz, and you won't know what timing the video card uses as default.
If my code can use CRTC info to force the video card to use specific timings, then it'll give the video mode either a very high reliability rating or a very low reliability rating based on what EDID reported. If my code can't use CRTC info then it can't be too sure about the video card's timing, and it'll calculate the horizontal and vertical timings the video card might use if the refresh rate is 60 Hz and see if that is within the monitor's limits and use that for the basis of the reliability rating, and then find out how many standard timings the monitor supports at the same resolution and adjust the reliability rating according to that. For example (for a "800 * 600" video mode with unknown timing), if my code determines that (at 60 Hz) the video mode's timing would be supported by the monitor then it might give it a base rating of 66%; and then if the monitor says it supports "800 * 600 at 60 Hz" and "800 * 600 at 70 Hz" but doesn't support "800 * 600 at 80 Hz", then my code would adjust this rating by 2/3 and come up with a final rating of 44%.
Of course if my code can't get EDID from the monitor, then it will assume the monitor is "standard VGA" and calculate reliability ratings based on that (and most high resolution video modes will get very low ratings). In addition, my code does make some more assumptions about video mode timings. For example, for standard VGA modes (e.g. "640 * 480 at 4-bpp", "320 * 200 at 8-bpp", etc) it will assume that the video card probably uses standard VGA timings, and you'll get higher reliability ratings because of this.
From here, my code uses the user's preferences and the reliability rating to select a video mode from the list. Eventually this selection will also take into account the monitor's preferences (as some monitors have "preferred" video modes that give better results - especially LCD monitors), but I haven't done this yet (in most cases the monitor says it prefers something like "1680 * 1050" and the video card won't support it anyway).
This entire system seems to work, sort of. However, it does mean that in a large number of cases (e.g. mostly video cards that don't support CRTC info, which is unfortunately most of them) the user doesn't get the video mode they want. For example, the user might set the preferences for "800 * 600 at 32-bpp @ 70 Hz", and they might get "640 * 480 at 4-bpp @ 59.950 Hz" because the reliability rating for this (standard VGA) video mode is high enough to override the user's preferences. It also causes problems on every emulator I've tested, because none of the emulators return EDID information for the monitor - my code assumes it's a standard VGA monitor in this case, so you end up with very low reliability ratings for most video modes, which makes it almost impossible for the user to end up with anything other than standard VGA video modes. Note: I hacked my Bochs BIOS so that it will return EDID information for a standard 15 inch monitor.
I guess what I'm saying is that the code still needs some fine tuning, but it will never be perfect. Initially I wanted a fully automated boot that always gives very reliable results (with no need for the user to intervene at all). In the end I had to implement a "interactive boot menu" to cope with the uncertainty, because it's impossible to guarantee reliable results using VBE regardless of how hard you try.
Cheers,
Brendan
They are valid code points, but they're also control characters (newline, tab, etc) just like ASCII, which means you don't need font data for them. There's a similar range of control characters (code points 0x000080 to 0x009F) and a few orphans (0x00007F/delete and 0x0000AD/soft hyphen), and some characters that look the same (e.g. space and "no-break space"). I ended up with a total of 189 individual characters in my font data.jal wrote:Are 0x00-0x1F valud Unicode code points? Never new that...
Here's the font data at 2 different sizes (top left is 6 * 8 pixels per character; the squares with diagonal lines correspond to "undisplayable" control characters):
It's modular. The module that displays the boot log using the video card could be replaced by a module that does anything else; including sending the boot log to a braille terminal, or doing morse code with the PC speaker, or...jal wrote:That's pretty cool, although you still may want some options for visually impaired (or the opposit) people.It's completely resolution independent.
The boot code itself allows several of these "display modules" at the same time (e.g. you could use 4 display modules, and send to boot log to the video card, serial port, network card and sound card all at the same time).
Thanks. Was wondering if anyone would notice the "anti-aliased-ness", although you haven't seen 6*8 characters on 8-bpp yet (it's ugly, and barely readable).jal wrote:Anti-aliased and all. Impressive.Here's a screen shot
The full mess goes a little like this...AJ wrote:Nice one - I know how much work you put in to the "behind the scenes reliability", too. Good to see how far it has come on. Out of interest, is the "% reliable" rating a measure of your confidence of whether a video mode is likely to work on the current adapter / monitor? If so, how do you arrive at that figure?
For each video mode listed by VBE, I try to create additional "derived" video modes. If the video card supports it, my code can use double scanned mode and CRTC timing information; so that (for e.g.) for one "1024 * 768, 32-bpp" video mode reported by VBE I might end up with:
- 1024 * 768, 32-bpp, unknown refresh rate (the original mode)
- 1024 * 768, 32-bpp @ 60.004 Hz refresh rate
- 1024 * 768, 32-bpp @ 70.069 Hz refresh rate
- 1024 * 768, 32-bpp @ 75.029 Hz refresh rate
- 1024 * 768, 32-bpp @ 84.997 Hz refresh rate
- 1024 * 384, 32-bpp @ 60.004 Hz refresh rate
- 1024 * 384, 32-bpp @ 70.069 Hz refresh rate
- 1024 * 384, 32-bpp @ 75.029 Hz refresh rate
- 1024 * 384, 32-bpp @ 84.997 Hz refresh rate
Then I use the EDID information from the monitor to estimate the probability that the monitor will be able to handle each video mode. This is complicated, because it's impossible to determine the video card's timing (without forcing the video card to use your own CRTC timings), and therefore impossible to determine if the horizontal frequency and vertical frequency is within the monitor's limits. For example, a video card might report a 800 * 600 video mode, and the monitor might support 800 * 600 at 60 Hz but might not support 800 * 600 at 75 Hz, and you won't know what timing the video card uses as default.
If my code can use CRTC info to force the video card to use specific timings, then it'll give the video mode either a very high reliability rating or a very low reliability rating based on what EDID reported. If my code can't use CRTC info then it can't be too sure about the video card's timing, and it'll calculate the horizontal and vertical timings the video card might use if the refresh rate is 60 Hz and see if that is within the monitor's limits and use that for the basis of the reliability rating, and then find out how many standard timings the monitor supports at the same resolution and adjust the reliability rating according to that. For example (for a "800 * 600" video mode with unknown timing), if my code determines that (at 60 Hz) the video mode's timing would be supported by the monitor then it might give it a base rating of 66%; and then if the monitor says it supports "800 * 600 at 60 Hz" and "800 * 600 at 70 Hz" but doesn't support "800 * 600 at 80 Hz", then my code would adjust this rating by 2/3 and come up with a final rating of 44%.
Of course if my code can't get EDID from the monitor, then it will assume the monitor is "standard VGA" and calculate reliability ratings based on that (and most high resolution video modes will get very low ratings). In addition, my code does make some more assumptions about video mode timings. For example, for standard VGA modes (e.g. "640 * 480 at 4-bpp", "320 * 200 at 8-bpp", etc) it will assume that the video card probably uses standard VGA timings, and you'll get higher reliability ratings because of this.
From here, my code uses the user's preferences and the reliability rating to select a video mode from the list. Eventually this selection will also take into account the monitor's preferences (as some monitors have "preferred" video modes that give better results - especially LCD monitors), but I haven't done this yet (in most cases the monitor says it prefers something like "1680 * 1050" and the video card won't support it anyway).
This entire system seems to work, sort of. However, it does mean that in a large number of cases (e.g. mostly video cards that don't support CRTC info, which is unfortunately most of them) the user doesn't get the video mode they want. For example, the user might set the preferences for "800 * 600 at 32-bpp @ 70 Hz", and they might get "640 * 480 at 4-bpp @ 59.950 Hz" because the reliability rating for this (standard VGA) video mode is high enough to override the user's preferences. It also causes problems on every emulator I've tested, because none of the emulators return EDID information for the monitor - my code assumes it's a standard VGA monitor in this case, so you end up with very low reliability ratings for most video modes, which makes it almost impossible for the user to end up with anything other than standard VGA video modes. Note: I hacked my Bochs BIOS so that it will return EDID information for a standard 15 inch monitor.
I guess what I'm saying is that the code still needs some fine tuning, but it will never be perfect. Initially I wanted a fully automated boot that always gives very reliable results (with no need for the user to intervene at all). In the end I had to implement a "interactive boot menu" to cope with the uncertainty, because it's impossible to guarantee reliable results using VBE regardless of how hard you try.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: What does your OS look like? (Screen Shots..)
Thank you very much!Brendan wrote: Here's the font data at 2 different sizes (top left is 6 * 8 pixels per character; the squares with diagonal lines correspond to "undisplayable" control characters):
"Open source seems to embrace the dark side of human nature." - Ville Turjanmaa
Re: What does your OS look like? (Screen Shots..)
Hello guys,
bOOze, my first attempt at writing an OS kernel, which never got past the basic MM and scheduling parts due to insufficient thinking on my part. Ah well. I was going to give it another try but had a few problems compiling the lastest version of Bochs, which led me, well, here.
bOOze, my first attempt at writing an OS kernel, which never got past the basic MM and scheduling parts due to insufficient thinking on my part. Ah well. I was going to give it another try but had a few problems compiling the lastest version of Bochs, which led me, well, here.
The brown matter is bound to hit the revolving, airflow-generating implement.
Re: What does your OS look like? (Screen Shots..)
Nice, like the alcohol-related versioning scheme
Re: What does your OS look like? (Screen Shots..)
Hydrogen OS v0.0.236
example, the taskbar control contains two other controls.
The GUI architecture has been rewritten. It is now possible to add a control inside a control. In thisexample, the taskbar control contains two other controls.
"Open source seems to embrace the dark side of human nature." - Ville Turjanmaa
- Alexis211
- Posts: 14
- Joined: Mon Sep 14, 2009 9:19 am
- Libera.chat IRC: lxpz
- Location: France
- Contact:
Re: What does your OS look like? (Screen Shots..)
Hi everyone !
Here are a few screenshots of my Melon
Here are a few screenshots of my Melon
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: What does your OS look like? (Screen Shots..)
As always, Tommy, you produce screenshots made of pure unadulterated awesome. Nice work, can't wait to be able to write programs for it
Nice OS, there, Alexis. Is your ramfs a custom one?
Nice OS, there, Alexis. Is your ramfs a custom one?
- Alexis211
- Posts: 14
- Joined: Mon Sep 14, 2009 9:19 am
- Libera.chat IRC: lxpz
- Location: France
- Contact:
Re: What does your OS look like? (Screen Shots..)
Yes. It's very basic but it has support for subdirectories.Troy Martin wrote: Nice OS, there, Alexis. Is your ramfs a custom one?
I have a header with a magic number and the number of files, and then for each file a header with it's name's length and it's content's length. A file with no content is considered as a directory.
Re: What does your OS look like? (Screen Shots..)
Thanks!Troy Martin wrote: As always, Tommy, you produce screenshots made of pure unadulterated awesome. Nice work,
Be patient! The version 0.1.0 will be published when it will be ready.Troy Martin wrote: can't wait to be able to write programs for it
"Open source seems to embrace the dark side of human nature." - Ville Turjanmaa
Re: What does your OS look like? (Screen Shots..)
I like it, it has this authentic feeling to it.Alexis211 wrote:Hi everyone !
Here are a few screenshots of my Melon
When the chance of succeeding is 99%, there is still a 50% chance of that success happening.
Re: What does your OS look like? (Screen Shots..)
Cool look, it would be nice to see an 800x600 background photo to bring out the full efect It looks very win. 7Tommy wrote:Hydrogen OS v0.0.236
Cool, I like how you set that up by putting the workspace into the grayboxAlexis211 wrote:Here are a few screenshots of my Melon
My hero, is Mel.
Re: What does your OS look like? (Screen Shots..)
It's true that it looks like a little.Coddy wrote: Cool look, it would be nice to see an 800x600 background photo to bring out the full efect It looks very win. 7
When my OS will be able to load files, it will be possible to use a picture as wallpaper. Because a wallpaper included into the
kernel binary is not the best solution!
"Open source seems to embrace the dark side of human nature." - Ville Turjanmaa
- Alexis211
- Posts: 14
- Joined: Mon Sep 14, 2009 9:19 am
- Libera.chat IRC: lxpz
- Location: France
- Contact:
Re: What does your OS look like? (Screen Shots..)
Yeah, I have a concept of Virtual Terminal that has a fixed dimension (here 15 lines and 76 cols) that I can map anywhere on the screen. The VT is the one that does all the text formatting, scrolling, etc.Coddy wrote:Cool, I like how you set that up by putting the workspace into the grayboxAlexis211 wrote:Here are a few screenshots of my Melon
Re: What does your OS look like? (Screen Shots..)
And another screenshot of Hydrogen OS:
I started writing full applications, including a small calculator."Open source seems to embrace the dark side of human nature." - Ville Turjanmaa