OSDev.org

jal wrote:

kubeos wrote:This could be mistaken for DOS. Maybe I should add some colors to my shell.

I had colours in DOS! ANSI.SYS FTW!

Very refreshing to see a non-POSIX like CLI though.


JAL

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".

Creature 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".

I doubt anyone on this forum will ever get that far

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.

That is damn awesome. Congratz!

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.

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...

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

Just starting work on a gui for my os

http://img10.imageshack.us/img10/5444/32671322.jpg

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...

then use lower res lower color
i wish people would stop writing this vesa $hit and stick to VGA 320x200x8 and 640x480x4

smeezekitty wrote:then use lower res lower color
i wish people would stop writing this vesa $hit and stick to VGA 320x200x8 and 640x480x4

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?

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.

In other words: Make it run fast in bochs and you're set

Combuster wrote:In other words: Make it run fast in bochs and you're set

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].

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.

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.

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 well

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?

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).

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.

QEMU is very fast compared to Bochs because it is not a pure emulator.

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.

I think Bochs is comparable in speed to an old, late 80s/early 90s ISA card.


JAL

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].

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.