Indeed. IMHO far too many OS' here are "imitating" Linux (I don't really know how to put it, it's just that a lot of people seem to want to use the /usr/src way of structuring directories and such). There's nothing wrong with that, it's a matter of choice after all. I guess you create your OS mostly after the OS you're working on (or like most) and try to improve on the points that you think are "bad" or that "could be better".jal wrote:I had colours in DOS! ANSI.SYS FTW!kubeos wrote:This could be mistaken for DOS. Maybe I should add some colors to my shell.
Very refreshing to see a non-POSIX like CLI though.
JAL
What does your OS look like? (Screen Shots..)
Re: What does your OS look like? (Screen Shots..)
When the chance of succeeding is 99%, there is still a 50% chance of that success happening.
- Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
Re: What does your OS look like? (Screen Shots..)
I doubt anyone on this forum will ever get that farCreature wrote:I guess you create your OS mostly after the OS you're working on (or like most) and try to improve on the points that you think are "bad" or that "could be better".
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]
- 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..)
That is damn awesome. Congratz!kubeos wrote:FINALLY!!!! Self-hosting is so close.. just need to port unzip or something so I can archive up my kernel sources and give them a fresh native compile.
EDIT: This could be mistaken for DOS. Maybe I should add some colors to my shell.
I also like the DOS-ishness. Way easier for some people than POSIX crappage. Sort of why I've opted for somewhere between bashness and DOSness.
Re: What does your OS look like? (Screen Shots..)
Well, I finally got around to getting a console in graphics mode working:
It's still pretty buggy though, and scrolling is very slow in Bochs (but pretty fast in VirtualBox, so I guess the speed isn't too bad ).
I also used to have scrolling (with PageUp and PageDown) in text mode, but I decided to leave it out for now because a buffer would be huge. I used a buffer for saving 1000 lines, making a 1000 * console_width * sizeof(word) = ~156 kB in 80x25 text mode, but saving pixels is extremely slow (even on a double-buffer) and the buffer would be around 1000 * screen_width * bytes_per_pixel size, which would give me a buffer of approximately 4 MB on 1024x768x32!
Maybe a good idea would be to save the individual characters, with their colours, and then implement something that uses 1 byte for the character and up to 4 bytes for the RGBA colour. It would still be pretty slow, though...
It's still pretty buggy though, and scrolling is very slow in Bochs (but pretty fast in VirtualBox, so I guess the speed isn't too bad ).
I also used to have scrolling (with PageUp and PageDown) in text mode, but I decided to leave it out for now because a buffer would be huge. I used a buffer for saving 1000 lines, making a 1000 * console_width * sizeof(word) = ~156 kB in 80x25 text mode, but saving pixels is extremely slow (even on a double-buffer) and the buffer would be around 1000 * screen_width * bytes_per_pixel size, which would give me a buffer of approximately 4 MB on 1024x768x32!
Maybe a good idea would be to save the individual characters, with their colours, and then implement something that uses 1 byte for the character and up to 4 bytes for the RGBA colour. It would still be pretty slow, though...
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..)
Here some screenshots of my last version. Now I'm working on the resource files to have a better (and real) GUI
I'm going to upload the new screens with the pit driver working, and some basic commands to use the floppy controller
P.S The page has not yet been translated
I'm going to upload the new screens with the pit driver working, and some basic commands to use the floppy controller
P.S The page has not yet been translated
- lonesamurai5
- Posts: 3
- Joined: Sun May 11, 2008 4:19 am
-
- Member
- Posts: 50
- Joined: Sat Mar 21, 2009 9:42 pm
Re: What does your OS look like? (Screen Shots..)
then use lower res lower color
It's still pretty buggy though, and scrolling is very slow in Bochs (but pretty fast in VirtualBox, so I guess the speed isn't too bad ).
I also used to have scrolling (with PageUp and PageDown) in text mode, but I decided to leave it out for now because a buffer would be huge. I used a buffer for saving 1000 lines, making a 1000 * console_width * sizeof(word) = ~156 kB in 80x25 text mode, but saving pixels is extremely slow (even on a double-buffer) and the buffer would be around 1000 * screen_width * bytes_per_pixel size, which would give me a buffer of approximately 4 MB on 1024x768x32!
Maybe a good idea would be to save the individual characters, with their colours, and then implement something that uses 1 byte for the character and up to 4 bytes for the RGBA colour. It would still be pretty slow, though...
i wish people would stop writing this vesa $hit and stick to VGA 320x200x8 and 640x480x4
Re: What does your OS look like? (Screen Shots..)
Why? Not even mobile phones have colour depths that low and no desktop display is designed to run at those resolutions. Why limit yourself to thoroughly antique/obsolete technology?smeezekitty wrote:then use lower res lower color
i wish people would stop writing this vesa $hit and stick to VGA 320x200x8 and 640x480x4
The cake is a lie | rackbits.com
Re: What does your OS look like? (Screen Shots..)
Well, to answer your question: I implemented VESA support in order to have a console on higher resolution modes (I guess I got inspired by Pedigree's look). Decreasing the colour also doesn't increase performance a lot for me. I also restricted the video resolutions to colour depths of at least 24 bpp, because I wanted to implement alpha-blending. In theory, alpha blending should be perfectly possible in 16-bit too, I guess (I'm using unsigned hex colours for every bit depth, which are converted anyway). Do old-new computers that have support for VESA (and monitors) usually have support for at least 24 bpp or are some older ones (~3 - 4 years old?) still limited to 16 bpp or lower?
Anyhow, I re-implemented scrolling and did some more optimizations. I also noticed that it is VERY fast in QEMU and VirtualBox, it's just Bochs being very slow with it apparently.
The speed of a standard on-board graphics controller (on real hardware), to what emulator would it be most comparable? QEMU? Bochs? I'm mostly referring to some older computers.
Anyhow, I re-implemented scrolling and did some more optimizations. I also noticed that it is VERY fast in QEMU and VirtualBox, it's just Bochs being very slow with it apparently.
The speed of a standard on-board graphics controller (on real hardware), to what emulator would it be most comparable? QEMU? Bochs? I'm mostly referring to some older computers.
When the chance of succeeding is 99%, there is still a 50% chance of that success happening.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: What does your OS look like? (Screen Shots..)
In other words: Make it run fast in bochs and you're set
Re: What does your OS look like? (Screen Shots..)
Exactly what I was thinking! Only I've already run out of optimization idea's and I don't know any "uber-advanced" optimization techniques . I also haven't tried setting the MTRR to write-combine yet. Using an SSE-memcpy gives me about the same performance as my current memcpy (which plainly uses MOVS* routines) [maybe because I haven't properly set it up yet].Combuster wrote:In other words: Make it run fast in bochs and you're set
When the chance of succeeding is 99%, there is still a 50% chance of that success happening.
- NickJohnson
- Member
- Posts: 1249
- Joined: Tue Mar 24, 2009 8:11 pm
- Location: Sunnyvale, California
Re: What does your OS look like? (Screen Shots..)
That's probably because Bochs doesn't accurately emulate the amount of time needed to do each operation, so SSE ops might run closer in speed to string ops. I think you can make it more accurate by setting "clock: sync=slowdown" in bochsrc. Whichever way you cut it, Bochs emulates a very slow machine, at least by today's standards, so if it runs fast on Bochs, it should run fast anywhere.
-
- Member
- Posts: 2566
- Joined: Sun Jan 14, 2007 9:15 pm
- Libera.chat IRC: miselin
- Location: Sydney, Australia (I come from a land down under!)
- Contact:
Re: What does your OS look like? (Screen Shots..)
More precisely, Bochs emulates each instruction (which is why it's so great for debugging), meaning each virtual CPU cycle can be several thousand host cycles. But yes, if it runs fast in Bochs, you've done very wellWhichever way you cut it, Bochs emulates a very slow machine, at least by today's standards, so if it runs fast on Bochs, it should run fast anywhere.
Re: What does your OS look like? (Screen Shots..)
I think that computers limited to 16 bit (i.e. not having 24 or 32 bit) are limited to the mid-90s. Anything more recent has at least 24 bit support. Note however, that 24 bit is usually very slow on the earlier cards that supported it (still talking 90s here), and usually 16 bit was chosen for speed (and resolution, because of the limited memory of these cards). 3-4 years old means cards from 2005-2006. That's so very recent, that's not old(er) in any way (except perhaps when talking about the version of shaders supported).Creature wrote:Do old-new computers that have support for VESA (and monitors) usually have support for at least 24 bpp or are some older ones (~3 - 4 years old?) still limited to 16 bpp or lower?
QEMU is very fast compared to Bochs because it is not a pure emulator.Anyhow, I re-implemented scrolling and did some more optimizations. I also noticed that it is VERY fast in QEMU and VirtualBox, it's just Bochs being very slow with it apparently.
I think Bochs is comparable in speed to an old, late 80s/early 90s ISA card.The speed of a standard on-board graphics controller (on real hardware), to what emulator would it be most comparable? QEMU? Bochs? I'm mostly referring to some older computers.
JAL
-
- Member
- Posts: 153
- Joined: Sun Jan 07, 2007 9:40 am
- Contact:
Re: What does your OS look like? (Screen Shots..)
I threw together a gui on my kernel and tested with bochs, found a couple thing. It's of course implementation dependent, but in my case the UI code writes to a buffer and a separate thread copies the buffer to video memory in a loop. (http://wiki.osdev.org/GUI) It got at least a 200% improvement in the memcpy using MMX and got nearly 15 fps on bochs. Googling 'mmx memcpy' gave several good results.Creature wrote:Using an SSE-memcpy gives me about the same performance as my current memcpy (which plainly uses MOVS* routines) [maybe because I haven't properly set it up yet].