OSDev.org

The Place to Start for Operating System Developers
It is currently Tue Mar 19, 2024 12:38 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 11 posts ] 
Author Message
 Post subject: Spartan OS - 1.0
PostPosted: Sat Apr 21, 2018 1:20 pm 
Offline

Joined: Mon Apr 18, 2011 5:25 pm
Posts: 11
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.

Image


Top
 Profile  
 
 Post subject: Re: Spartan OS - 1.0
PostPosted: Sat Apr 21, 2018 3:27 pm 
Offline
Member
Member
User avatar

Joined: Fri Aug 07, 2015 6:13 am
Posts: 1134
Nice Trojan Horse! [-X Windows won't let me download it.
A false positive?

_________________
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader


Top
 Profile  
 
 Post subject: Re: Spartan OS - 1.0
PostPosted: Mon Apr 23, 2018 12:36 pm 
Offline

Joined: Mon Apr 18, 2011 5:25 pm
Posts: 11
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.


Top
 Profile  
 
 Post subject: Re: Spartan OS - 1.0
PostPosted: Mon Apr 23, 2018 5:34 pm 
Offline
Member
Member

Joined: Wed Mar 30, 2011 12:31 am
Posts: 676
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.

_________________
toaruos on github | toaruos.org | gitlab | twitter | bim - a text editor


Top
 Profile  
 
 Post subject: Re: Spartan OS - 1.0
PostPosted: Mon Apr 23, 2018 11:44 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
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.:
Code:
copy /b m.dat + z.dat + program.dat program.exe

Where m.dat and z.dat contain the removed bytes.


Top
 Profile  
 
 Post subject: Re: Spartan OS - 1.0
PostPosted: Tue Apr 24, 2018 6:55 am 
Offline

Joined: Mon Apr 18, 2011 5:25 pm
Posts: 11
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.


Top
 Profile  
 
 Post subject: Re: Spartan OS - 1.0
PostPosted: Tue Apr 24, 2018 3:28 pm 
Offline
Member
Member
User avatar

Joined: Sat Dec 27, 2014 9:11 am
Posts: 901
Location: Maadi, Cairo, Egypt
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.

_________________
You know your OS is advanced when you stop using the Intel programming guide as a reference.


Top
 Profile  
 
 Post subject: Re: Spartan OS - 1.0
PostPosted: Tue Apr 24, 2018 6:00 pm 
Offline
Member
Member

Joined: Sun Nov 05, 2017 2:29 pm
Posts: 31
Location: Middleboro, MA
Looks great! Good job with the GUI, I really like it.

_________________
I'm a contributor to BareMetal OS. View it at https://github.com/ReturnInfinity/BareMetal-OS


Top
 Profile  
 
 Post subject: Re: Spartan OS - 1.0
PostPosted: Fri Apr 27, 2018 8:51 am 
Offline

Joined: Mon Apr 18, 2011 5:25 pm
Posts: 11
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.


Top
 Profile  
 
 Post subject: Re: Spartan OS - 1.0
PostPosted: Sat Apr 28, 2018 3:25 am 
Offline
Member
Member
User avatar

Joined: Sat Dec 27, 2014 9:11 am
Posts: 901
Location: Maadi, Cairo, Egypt
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.

_________________
You know your OS is advanced when you stop using the Intel programming guide as a reference.


Top
 Profile  
 
 Post subject: Re: Spartan OS - 1.0
PostPosted: Sat Apr 28, 2018 6:11 am 
Offline

Joined: Mon Apr 18, 2011 5:25 pm
Posts: 11
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.
Code:
800x600 @60Hz (600 scalines x 60 fps = 36000)
PIT base freq of 1.193182 MHz reduced to 36.157 KHz
3.2 GHz vs 36.157 KHz (3200000000/36157) = 88,503

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: kerravon and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group