OSDev.org

Spartan OS is a final year project which I have been working on as part of an undergrad in Software Development. Spartan OS is a multi-tasking, single user OS which features a Graphical User Interface and file associations. Device support is very limited and this gives rise to the project name (Spartan of meagre needs).

The repository contains both the software and the supporting documentation and is available at
https://github.com/collinsmichael/spartan

and the CDROM iso can be found here
https://github.com/collinsmichael/spart ... /cdrom.iso

The code base is a little over 10KLOC and the documentation is a little over 23K words. I ran out of time and much of the features I had planned never got implemented, as a result this may be the first operating system announced here which does not interpret command lines, at any rate I am very proud of the result and wish to thank everybody who put the time and effort into maintain this wonderful resource.

This site truly rocks and I personally owe many of you my deepest and most sincere thanks.

Nice Trojan Horse! Windows won't let me download it.
A false positive?

I have executables all over the repository. There are custom build tools for authoring a CD ISO and the Ram Disk folder contains pre-built binaries. There's not a whole lot I can do about this until after its been graded. I'll take them out soon. But thanks for showing interest.

I've noticed something peculiar which is that your UI performs reasonably well in Bochs, but in QEMU with TCG or KVM it is incredibly slow, which is paradoxical as these environment should be significantly faster than Boch's software emulation.

clns wrote:I have executables all over the repository. There are custom build tools for authoring a CD ISO and the Ram Disk folder contains pre-built binaries. There's not a whole lot I can do about this until after its been graded.

Hackers have spoiled it for everyone and there doesn't seem to be a sane fix to the problem of false negatives in malware detection.
I ended up hosting Windows executables with their two first bytes ('M' and 'Z') removed.
They can be restored in DOS/Windows using e.g.: Where m.dat and z.dat contain the removed bytes.

klange wrote:I've noticed something peculiar which is that your UI performs reasonably well in Bochs, but in QEMU with TCG or KVM it is incredibly slow, which is paradoxical as these environment should be significantly faster than Boch's software emulation.

Most likely due to how it synchronizes to the refresh rate. I've seen VM's struggle with simulating timer behavior obviously this is significantly more difficult problem then it appears. On real hardware (circa 1998-2003) it supports up to 3 applications each capable of 60Hz at 800 x 600.

alexfru wrote: I ended up hosting Windows executables with their two first bytes ('M' and 'Z') removed.

Perfect, simple fix for the pre-built images, my loader doesn't acknowledge those signatures anyways. I don't mind leaving out the deployment utilities, I may just add in the code for building them.

I've tried it and it looks nice actually. The only weird thing I've noticed is the way it's slow with KVM and fast without it. Maybe you should redraw the screen when it needs to be redrawn, and try not to sync with the refresh rate. I haven't done that myself, but IIRC it is non-standard and you shouldn't use it unless you have a real graphics driver, which is out of scope for most of us.

Looks great! Good job with the GUI, I really like it.

Thanks for the positive feedback, I'm glad for the feedback.

@omarrx024 I entirely agree, the compositor (renderer) uses the dirty regions concept and will yield time back to the system at every opportunity. It does not directly sync to vertical blanking (say by querying port 0x03DA). Instead it calculates how many scanlines need to be drawn within a second. 800x600 @60Hz works out at 36000 scanlines it programs the PIT to meet this (36157 Hz) and will skip some intervals to synchronize and updates only dirty scanlines. This approach assumes two things
1) that the electron beam will always be somewhere else on the screen,
2) that the processor is capable of completing a scanline within 1/36000th of a second.
And this second point is where VM's typically disagree with my assumption. This has the effect that by the time a scanline is completed most VM's feel that multiple PIT intervals have passed. This is only true in reality if the processor is incapable of that throughput. With this approach there is little that can be done to help this and a user will have to endure a less responsive experience.

clns wrote:Instead it calculates how many scanlines need to be drawn within a second. 800x600 @60Hz works out at 36000 scanlines it programs the PIT to meet this (36157 Hz) and will skip some intervals to synchronize and updates only dirty scanlines.

I seriously doubt the PIT on real HW can do frequencies that high in practice. Hell, I seriously doubt even the HPET can do it.
Besides if you have such a high frequency on a somewhat slower CPU, you'll waste more time handling IRQs rather than doing actual work, which will give your final system a slow and sluggish feel.

Its not so black and white. Its less efficient for gui apps which only redraw in response to events. But it is a better approach for multimedia applications, such as demoscene apps. Which often are capable of reaching high frame rates. By silently dropping frames (say app throughput is 80fps but display is 60fps) you actually avoid a lot of effort. The overhead of interrupts is not obvious (you are correct that it is there) when displaying gui apps as redrawing is event initiated and driven by human speed throughput.

Edit
There is enough bandwidth at least on my test machines
3.2 GHz Single Core Pentium 4 Windows XP generation (2002-ish)
this gives a ballpark figure of 88,503 clock cycles per scanline to output at most 800 pixels. I admit it doesn't leave a lot of room but it is enough for 3xapps in 400x300 windows to max out their framerates with highly optimized software rendering.