OSDev.org

MessiahAndrw wrote:

bubach wrote:Wow, thats awesome for text mode!
The amount of time you must have put in just to get "transparent" windows, and redoing the font to get "graphic" details out of it, and the palette manipulations. Just pure kick-@$$!

I've always wondered if you could modify the font during the horizontal refresh, and effectively get per pixel control over the screen in text mode.

Anyway, great work turdus!

Thanks. Yes, you can modify fonts on the fly, that's how I draw pixel correct mouse pointer on character screen. Horizontal refresh is not mandatory, but you have to switch planes to modify fonts so you must be careful not to blink the screen. If you take a look on ASCII table on my screenshot, you can see 4 characters making up the pointer on the bottom left.

Hi there.
Publishing first screens of my KernelX Project, a 32bit Protected Mode Kernel/OS aimed to be a learning project and to run linux applications later, too.


well then, bye ..

My OS's prototype's bootloader

to m12
*scratch*
it doesn't look much informative, does it?

At the point I have showed you, I have successfully done everything except reenable interrupts and load the kernel (I have enabled A20, PMode, etc.). However, the graphics subroutine I wrote for 32-bits isn't working for some reason, so the proggress bar doesn't update. I might ask for help in another post.

Wow, I couldn't believe it. I've just removed the dust from an old CD, and I've found a copy of my first OS written in the 90's.
(Strictly it wasn't an OS as it was built on top of DOS. So I've installed DOSBox quickly and gave it a try. It worked! Not as fast as on real hardware, but no errors.)
Most notable features:
- real mode
- vesa compatible
- copy'n'paste for all DOS programs (via TSRs)
- user authentication
- user rights DOS extension to FAT (TSR)

Here are some screenshots of the GUI, sorry not being in english. I'll give you a translation.

This is the setup, a separate executable. If no configuration found, the GUI will start in 640x480 grayscale (those old days). Beállított felbontás=resolution in use, ikonok=icons, fekete fehér=grayscale (black and white), hibaablak=show error window, karakteres kép=freeze character display, kép ablakban=show in window

Here comes the startup splash: minden jog fenntartva=all rights reserved

And finally, GUI in work. You can see several window types on this screen. It's also has 3 mouse pointers (a busy one over C DRIVE, normal in drag'n'drop in the middle, and one at bottom left that popped up menubar (normally it's hidden)). elérhető meghajtók=available drives, lemez=disk, hálózati meghajtó=network drive, hosszú név=long name (LFN), nincs=none, fileméret=filesize, futtatás=execute with
új könyvtár=new directory, aktív ablakok=active windows, szerkesztő=editor, munkakönyvtár=working dir, mozgatott ikon=icon under the pointer in movement
forrás másik ablak=source another window, elérési út=path

It was written in SPHINX C--

berkus wrote:Cool stuff, turdus!

Yeah. And nice to see the localization .

Made some tweaks and fixed some bugs on my friend's BlackBox OS



Wah! I wish he is active and continue this OS!

What? The wallpaper of the OS was just to test out if the system can handle other graphic files than . Jpeg

Didn't he posted the working file system before? I will put that up here soon

Some new screen-shots from the performance analysator running on a 2-core AMD portable:

When this screen-shot is taken the payment terminal is already running. At 16.45 the GUI test application starts with some easy tests. A little before 16.46 it goes unresponsive and behaves like "I want to have as much CPU-time as possible:



This is a contiunued screen shot taken a little later. At 16.48 another test app is started that also tries to use as much CPU time as possible, but this one sends IPC-messages between threads. There are 8 senders that does local IPC, and 8 senders that does IP-based IPC, all loading the same receiver:


Even if load is 100% on both cores at the end, the system is still responsive. The animation in the payment terminal appears to proceed as if the machine were unloaded.

Some more performance logs, now from a 6-core AMD and the Intel Core Duo:

The first one is when the 6-core AMD is loaded from a local network with 6 remote IPC senders from the Core Duo:



Here is how the load looks like on the Intel Core Duo:



Here is the 6-core AMD loaded with two "I want as much CPU time as possible" GUI test apps and one IPC receiver with 8 + 8 senders:



Here is the 6-core AMD loaded with three "I want as much CPU time as possible" GUI test apps and two IPC receiver with 8 + 8 senders:



It is possible to increase load to 100% on all 6 cores, but then more unresponsive apps must be loaded.

Just for a comparison with a machine that executes RDOS much slower than the above, here is the same load from the network (IPC over IP) on an dual core Intel Atom portable (4 cores as it has hyperthreading):

@berkus: I added a built-in recorder and a working clock



@rdos: That is sick! Great work man!

Before the Linux crash (and my subsequent porting to MSVC, yes, I want to be different):




Currently working to get to a further state than this with the MSVC build. Have already implemented a full toolkit for MSVC builds (including an advanced bin2hex for converting the kernel PE into a header file, and a PE->binary blob converter), just need to implement the features. The build is currently automated: upon hitting "build project", it will build the toolkit, build the kernel, b2h the kernel, build the loader, b2bb the loader, mound the VHD, copy to the virtual drive, unmount. Then it's just starting up VirtualBox or whatever emulator .

Written entirely in C++ with very, very little assembly - most work is taken up by intrinsics.

berkus wrote:

vincelawrence wrote:@berkus: I added a built-in recorder and a working clock

Perfect, what does the recorder do?

Off-topic(i don't think so?) but i had too,

Hey vince, you are not authorize to create any distro of my OS!