OSDev.org

Hi people,

I've redesigned and reimplemented my os after I couldn't make a server system that worked with the old design.

Below is the direct link to the RAR compressed file for a 1.44 image file. You can use rawwrite or winImage to copy it to a floppy disk.
(it works also as an image file for Bochs and co Note: Qemu and VmWare do not run it well. Bochs works fine)

http://www.freewebs.com/fuzionstudio/Protos-test1.rar

Would like tests on real machines. Please state specs of machine used.


How to run :
In console 0 you will see the RTC clock in the top righthand corner and a table of delayed processes in the bottom lefthand corner. This is to ensure that the RTC is also updating the delayed process queue.
The line "TICKS-> x" - is the counter for the number of PERIODIC interrupts (ticks) that have fired from the RTC.
Press
* ESC - this clears console 0 of al texts. Handy while Delay table is being updated. As entries reduce you will see multiple lines for the bottom entry because screen is not cleared during update of table.

* F1 - to cycle through the consoles (0 - 7).Some consoles will have information in them.For instance the VESA server prints all available graphic modes(that support a Linear frame buffer) in your pc starting from console 1. This information might overflow into console 2 and so on, if you have alot of modes.

* crtl+F1 then type a line of text and press ENTER key - to test keyboard server

* F3 - tests the console driver by printing a line of text. Cursor position should be updated.

* F4 - gives you the mode number for 640 x 480 x 16 bits graphics mode (this is a call to the VESA server)

* F5 - calls VESA server to switch to graphics mode 640 x 480 x 16 bits Note:Once this is done, you will need to reboot as I've not implemented the GUI server. Os is running but you can't see any changes) Do this last after doing other tests

* F6 - Calls Floppy server to read the boot sector of the floppy disk. The code in the boot sector is then displayed on console 2.

Let me know how it goes. This is just a test release so that i know it works on other computers other than the 4 I've tested it on.

Thank!

Hi,

I just tested your OS on my test pc. Specs:

Celeron 333 mhz, 32 mb ram
4 mb 3d video card (ATI)
3.5" fd.

All worked pretty well. I didn't encounter any bugs so far. The multitasking worked well, your floppy driver worked also well and your VGA test did too. Good job!

DennisCGc.

No problems here.

the only (little) confusing thing is that when you want to print text it goes to console 0 and not to the current one.

Test boxes: (Too lazy to copy specs)
Io, Uranus

Thank you DennisCGc and Combuster for the test runs. Happy to know that it worked fine on your systems ;D

@ Combuster :
The system app that prints texts is assigned console 0, thats why the text appears there.
Combuster, could you please test it with one or more of your 486 computers? I'd like to know if my code is responsive on older computers i.e not slow compared to the pentiums.

Everyone else, Keep testing please. It is very appreciated!

Thanks.

Apparently not on a 486DX2-66 box called Mercury...
(Tried the other 486 but it has technical issues and i'm not even getting to the bios screen - trying to fix that)

result:
screen goes blank
cursor goes green
the floppy rattles for two seconds
triple fault.

If i get the other 486 box up i'll test it and let you know

On another note - i managed to lock up the shell or whatever it is on the 686: trying to read from floppy hangs it for as long as there's no disk in the drive (scheduler seems to continue functioning though)

Success bugfixing

Thanks a lot!

I'm using CPUID to get information about the cpu. I think is it available on some 486 machines(have to check that)

The 686 should work,maybe it's the way I'm getting floppy controller setting from a fixed memory adress instead of calling bios to report it.(will implement the bios call to get the floppy settings)

More to come as I make changes ;D

Some constructive thinking

CPUID is only available on the latest produced series of 486s - If you call cpuid without checking if it works, you probably struck a "Undefined Opcode" exception on this one.

if you use NASM, try putting in "CPU 486" and see what code is pentium-based - i was surprised i had to rewrite quite a few parts when i decided to add "CPU 386" in my code.

For CPUID, you can test the ID bit in eflags - if you can change it you can issue a CPUID. (if you can't you either have a older 486 like mine, a 386 or a Cyrix)

As for the floppy bug, have it return an error instead of dying trying.

Hope this helps

There are checks for the CPUID bit. I already have them implemented. (I'll revise it anyway)

The floppy code need error checks, at the moment not using the results from the status registers(being implemented)

Will have to think of a work around for the cyrix cpu(the one I have it not with me at the moment

Thanks a lot Combuster.

Everyone if you can, please keep the information coming