OSDev.org

finally i completed the alpha version of my operating
system. now it has a complete kernel, filesystem and an
uncomplete gui. the attachment is the diskette image
of "Cemre" ( the name of my operating system ) the
source code of some part of the gui is available inside
the demo diskette, just winimage it ( or whatever ) to
a diskette and run it by rebooting your PC ( vmware
is also possible but PLEASE PLEASE DONT USE BOCHS,
gui in bochs it is god-damn SLOW ).

Some keys
F1 = exit ( form the gui )

F5 = refresh screen ( gui is still under test, if the screen
goes crazy or something, just refresh it using F5, just one
thing more, i never needed this F5 key upto now ).

F2 = if the mouse goes crazy, press this key, if it doesn't
just forget it. ( for advanced guys : it reinitializes mouse
packet retriever state machine ).

---------------------

The GUI is still under development and i personally
would welcome any code writers ( C++ ), GUI designers,
Graphics related helpers, enthusiasts ( i need people
to THINK ( just think, no code ) how it can be made better ),
to join together a team ( at the moment, I am the only
one to write this OS )

----------------------

FINALLY:
i need feedback... just tell me your thoughts.
[email protected] ( NO SPAM PLEASE !!! )

have fun...


dowload the image ( 1.44 MB ) from:
http://www.ug.bcc.bilkent.edu.tr/~engino/cemre.img

turkish version is also available at:

http://www.ug.bcc.bilkent.edu.tr/~engino/cemretr.img

1.44 MB

Cemre: in future use the OS Testing Forum which is especially for these kinds of posts. Also you may want to register your OS in the OSID

Pete

Runs fine on Bochs (A bit slow, but not unusable for me), fails to run on Qemu.

Tested on real hardware (AMD Athlon XP 1600+, Geforce 3 Ti)

Everything works fine as far as I can see.

Graphics modes I tested worked (Tried 640x480, 800x600, 1024x768).

No problems with the mouse (P/S 2).

Only grip is that redraw on move/resize is pretty sluggish (Can see the individual updates), but I'm sure you'll optimise that in later versions.

Nice work.

I've ever not used Qemu ( don't even know it ), does it
support VESA? and how does it behave on unreal mode,
cause "Cemre" temporarily switches to unreal mode to
read the diskette to upper memory before PM gui is loaded.



i know, i tried to optimize the draw sequence , and tried to
develop rectangle invalidation/validation tecniques etc...
this is one reason why i need a graphics programmer
( i am not ).



sorry about that, i didn't know.

Apologies, that wasn't a very good bug report, but I didn't think you were interested in the emulator results.

Qemu halts at 'Initialising memory...'

Only reason I mentioned it is because I've only rarely seen something work on Bochs and not on Qemu. Qemu doesn't emulate the MMU so I'm guessing you're correct with your unreal mode diagnosis.

i tried it in vmware (v 4.5.1), and it seems to work fine up until it changes resolution at which point the screen becomes very garbled until i hit (i think) F1 to exit.

proxy

It worked well, one question:
How do you get it to two screens displayed ?
I get it in the output screen, and the so-called "debug" screen...
And what really is suspicious:

Weird.... maybe a possible hint in your next release ?

I dont understand,

do you mean two ( or more ) windows inside the gui being displayed at the same time? if this is your question then the windows are just seperate objects in the gui subsystem ( instanciated from GuiWindow class )

or if you mean that the output "also" goes to BOCHS debug screen then -> any byte written to port 0xE5 goes to bochs debug screen ( of course only in BOCHS ), i did it and didn't remove it for these reasons, it was hard at first to get debug output inside the gui, the printf ( cout, cdbg ) function just sent chars to text mode screen and didnt work in gui, and sometimes when the gui crashed, i had to figure out a way to find where it crashed, so when i do a printf, the chars go to screen and to port 0xE5 at the same time, this makes debugging possible even in gui by watching the back bochs debug window, second, as far as i know, port 0xE5 is free at IBM machines, and it doesn't harm the real hardware if run on.



this is normal, whenever you task switch ( using hardware ), BOCHS gives you this message, the processes and context switches are implemented using TSS and hardware in Cemre, and the threads are just TSS's with same CR3 value ( of its process of course ) , if you want to get rid of it, you may do this in bochsrc.txt file, just ignore the debug action.

panic: action=ask
error: action=report
info: action=ignore
debug: action=ignore

sorry the port is "0xE9" not "0xE5"



is it possible that you are setting a refresh rate supported by the graphics card but not by your monitor? or try pressing F5 if the screen is garbled, I'm using vmware too, ( actually doing most of the debugging there ) and i didn't get this problem. try giving at least 16 or 32 megs of ram in vmware.

iirc, the 'T' bit in a TSS has some meaning about traps (possibly to be generated each time the TSS is switched to ? i should check back the Intel Manuals ... )

Yes, you're right....

T bit in CR0 is set every time a hardware task switch occurs. the FPU checks this bit before every operation and if it is set, it sends an FPU-fault interrupt to the CPU to enable the OS change the FPU context which 386 hardware doesn't do automatically ( nor 486, pent. or any )

after a task switch, the FPU content st0, st1 ... st7 and fpu control registers are all invalid like CPU eax, ebx etc and they have to be switched too, the cpu doesn't do fpu switch automatically, combined with the task-switch debug interrupt, you have to switch this context yourself by hand using FSAVE and FRSTORE ( in mmx cpus you use FXSAVE and FXRSTORE to save MMX context ). if you want, you must also switch the SSE and SSE2 context by hand. i implemented FPU and MMX switch but i didn't implement SSE and SSE2 switch in Cemre upto now.

to clear the T bit you use CLTS instruction or you read CR0, reset the bit and write it back.. ( CLTS is faster ) if you do not do this, FPU keeps interrupting even if you FRSTORE'd it

Hi,
I just checked it out in vmware:


I've given vmware 32megs of ram!

this is a vmware bug, it unexpectedly reports a 0xFFFFFFFF
on a memory megabyte boundary, it doesn't happen in
real hardware, i have also encountered this when i was
using vmware for linux. I use vmware 4.5.1 for windows ( XP )
and it doesn't do that...