Testing OS reports

[mr. xsism]

Let me start by saying this: this. Ok, i've been thinking a lot about doing something like this and now i see this thread. This is great! But I have a question and I want your opinions: would you guys register as members to a website and offer your PCs as test beds for other fellow dever's OS projects? A rating system would be used so you get higher stats for testing other kernels and you can test your own code. You would just register yourself and then register each of your test bed PCs that you will allow to be tested on. You would post the specs and restrictions like HD access or not.

After each test you fill out a template and send it to the user. Each of these would be viewable by all members for reference and compatability. Osdevers could readily say whether their OS works on AMD with xxx BIOS or intel with abc BIOS etc. You could browse the tests results by each user or OS project.

I know that this has been done before at OSV's site, but it seems that no one actually tests there and it is all doe with email. I think it would be better to just have templates filled out and posted back to the user who wanted it. Not only that, but I think it would be more successful with a hosting site that has higher traffic.

KJ and I are updating BonaFide Osdev and have a new url and whatnot. This would be part of our addition to the site. What do you guys think??

Replies much appreciated

Regards,
mr. xism

[Pype.Clicker]

Pype-Clicker (c32-0-8-0 because that was the most recently update):
The debug mode is annoying as hell, but all initilisation stages went ok.

The early initialisation stage should be saying "press SHIFT+SPACE to skip debug messages" or something like this. I think due to the large amount of people that report this problem, i'll make the "wait debug key" skipped by default.

There were a few warning about missing symbols in one of the consoles

If you could tell which ones, send me a private message

and the consoles themselves had a nasty tendency to overwrite one anothers top lines. Aside from that it seemed to work. Didn't do much but sit there, but it sat there happily .

this should be fixed in 0.8.8

thanks for your reports.

[Adek336]

Hi everybody! Can you check for me panaLiX 0.04? It has got task switching, two tasks run each writes a text to console. It works here, so I wanted to test it elsewhere.

Cheers,
Adrian.

PS change name to kernel32.x and run with grub:

kernel /kernel32.x
boot

[attachment deleted by admin]

[mr. xsism]

I don't use BRUB, i have my own bootloader. And I don't know if i could jsut load an ELF like a i do my binary kernel, so could you provide a bootloader? Or just give me an floppy image that i can copy to disk and boot up?

Thx,
mr. xsism

[Adek336]

Thank you for your interest! The current bootloader is @ http://adek336.republika.pl/panalix/grub.ima

The current snapshot reads the bootsector biosless (I finally made it!). I would be very grateful for any replies.

Cheers,
Adek

[mr. xsism]

Bochs didn't like it. Said HD BIOS ints weren't implmented yet. I also tested it on my Pentium MM with 32MB RAM and like 1MB VRAM. It ran ok. Printed out jibberish, probably the floppy data. Then i pressed a key, and it rebooted. Here's some JPEGs of it.

http://www.osdever.net/temp/penixShots.zip


Regards,
mr. xsism

[Adek336]

Thank you! That is exactly the way it runs on my bochs - dumps a dirtree of a dummy vfs and reads a sector off floppy. Actually I've disabled interrupt handling so the kboard's irq gets a triple fault.

Thanks,
Adrian

[Tim]

There's a new Mobius build available, for what must be the first time in ages.

What's added:

• Lots!

What's removed:

• Bugs which cause it to crash during boot (hopefully)

Known showstoppers:

• If you don't have a PS/2 mouse connected, there's a chance that the keyboard won't work. If you have a USB mouse, try enabling DOS support for it in the BIOS (this causes the BIOS to emulate the USB mouse as PS/2). Otherwise, remove the ps2mouse line from system.pro, making sure the numbers for the following lines are correct
• If you enter the kernel debugger (through F11), the kernel switches to text mode. Once you leave the debugger (e.g. by typing go or kill) graphics mode is not reset. If you were at the command line when you entered the debugger, you can reset graphics mode by typing /Mobius/vidtest. Otherwise, you can press Ctrl+Alt+Del and reboot.
• The shutdown command in the kernel debugger (which switches off the system power) probably won't work, although the shell's off command will. The debugger's shutdown reboot command will also work.

Try it, and see what you think:
http://www.themobius.co.uk/sdk/mobius-f ... -27.img.gz

Source code is on the way, as soon as I can find a way of uploading 6MB of code on my modem connection.

Edit: after a long and painful upload, the source code is at:
http://www.themobius.co.uk/sdk/mobius-s ... -27.tar.gz

[BI lazy]

a cool thing Mobius is. Lots of features and a very professional manner of starting up. It is also very impressive because of the many nifty functions which are available for it.

I have found some not so nice things:

If you cd to system directory, it isn't possible to say cd .. . instead it says file not found (ENOTFOUND)

Further, Mobius has some problems with usb-emulation of a ps2 mouse. So, it doesn't recognize the usb-mouse hanging on my machine.

the last thing I recognized, but this is the same with BlueIllusion: On my toshiba satellite 1700 it can't go into graphics mode via vm86. It simply stops and doesn't continue.

Stay safe and continue this cool work!

[Tim]

Thanks for trying it and giving your feedback!

If you cd to system directory, it isn't possible to say cd .. . instead it says file not found (ENOTFOUND)

Yep, there's no validation in the FsChangeDir function. So cd .. doesn't work to the root directory (though cd / does), and cd dasjdkajlk will work until you actually try to run anything there.

Further, Mobius has some problems with usb-emulation of a ps2 mouse. So, it doesn't recognize the usb-mouse hanging on my machine.

That's unfortunate, although I'm not sure what I can do about USB mice short of supporting them fully. Serial mice should work, though.

the last thing I recognized, but this is the same with BlueIllusion: On my toshiba satellite 1700 it can't go into graphics mode via vm86. It simply stops and doesn't continue.

Hmm, it shouldn't be trying to use V86 mode for graphics. Everything is a normal VGA mode, unless you happen to have an S3 Trio card installed (which it uses natively).

[mr. xsism]

6MB!!!! That's crazy!!! How do you manage that? Even your floppy image has to be extracted on bootup, that's big. You seem to have a good amount done though.

i couldn't switch between shells or use the GUI. Couldn't get to debugger either. That's in VMware. :-\

worked a tad better in bochs since i didn't have to ask myself, "What are the shell commands?" as there were no working commands in vmware. Anywho, oyur debugger gave a pretty page fault. I uploaded a screenshot for you. Hope it helps. Bye.

-mr. xsism

[attachment deleted by admin]

[distantvoices]

Here comes the next report on M?bius the Cool

I am testing it now on a computer in office: It starts up, finds the ps2 mouse attached to the machine and does fine.

then I switch to mobius-directory and execute winmgr:

A window manager starts up. It has one menu offering two choices: gconsole.exe,wincli.exe. starting gconsole.exe leads to a fault. wincli.exe results in a window saying hello world ).

Hint: when I invoke the menu and click onto another place outside menu-borders, the menu should vanish. Instead, the instance remains and confuses the winmgr.

The mouse redrawing: cute little box thou your mouse pointer is (mine is a box too), the redrawing of it should be done after some wait_for_vertical_retrace()-function.

indeed cool work ... I for my part am far far away from invoking a menu with the mouse. I 'm happy to have one text console control for system messages and command input...

[Tim]

mr. xsism: 6MB is only the source code. The OS itself is inside mobius.tar.gz, which is about 500MB. It's compressed to make it quicker to load. The GUI is a bit of a work in progress so far -- there's still a lot of work to be done -- and it still crashes regularly. The crash in your picture is, unfortunately, expected sometimes.

BI: I saw your post on mouse pointers. Currently I erase the old one then draw the new one; and there's no transparency, so you can only have square pointers. I think what I should do is:

If the old pointer rectangle and the new one intersect:

• Create an in-memory bitmap big enough to span the two rectangles
• Copy from the screen into the bitmap
• Copy the saved "underneath the pointer" bitmap to the bitmap, to erase the pointer image
• Copy the bitmap to the "underneath the pointer" bitmap
• Draw the new pointer to the bitmap
• Draw the bitmap to the screen

If they don't intersect then I don't think there will be any flicker problem.

[BI lazy]

@tim:

I use the trick with the area spanned by two "displacement rectangles" to move window boxes around the screen with a small amount of flicker - this you just can't avoid.

for the mouse: to get it transparent, I use the same mechanism like for drawing font: where a pixel is set in a valid colour in the bitmap, there I draw a pixel. If naught is to draw, then the area remains unchanged.

I too erase the pointer before redrawing it - animation requires it, no help from that. either you redraw the area underneath from a double buffer or from some kind of "what's beneath" bitmap owned by the mouse pointer. But which ever method I use, I have to do a "wait-for-vertical-retrace()" call to avoid flickering whilst moving the pointer.

that's how I do a normal mouse-movement without dragging some window-box around:

1. wait for vertical retrace
2. restore what's beneath the mouse pointer - old location
3. paint the mousepointer to the new location and meanwhile save what's beneath.

Code: Select all

buffer[bmp_offs]=vid_mem[offset+x];
            if(bmp[bmp_offs]){
              vid_mem[offset+x]=bmp[bmp_offs];
            }
  

that's roughly my mouse painting thing. this way is described on some website I remember as www.brackeen.com.

[Tim]

I see what you're saying. I seem to have overlooked that. I wonder how I could integrate waiting for vertical refresh (into the kernel-mode driver) without using too much CPU time.

It would be useful to provide a generic rubber banding mechanism to apps, not just for dragging windows. The window manager could keep a list of them; when one was to be moved, it could wait for the vertical blank interval. It could also prevent them from being drawn over by other programs. Windows seems to do this for window rectangles, but not in a general case: if you drag a dockable toolbar in an MFC app, it locks the display until you release the mouse button.