Pandora My Suro-v3.5b (an Assembler Os) Will Be Ported To Pandora

[quantenmagier]

I started porting my self written OS from x86 to amd64 and just came to the idea not only to make it run on amd64 but also on ARM and write some drivers for the Pandora.
I'll rewrite the code to make it more portable and then i'll write the amd64 spezific code till i get my andora1:.

Some basic features:
-written in Flat-Assembler (will port it to a self written Meta-Assembler later...)
-Multitasking (with special keyboard-driver for controlling lots of tasks at the same time)
-editing complete RAM/HDD directly
-special GUI-Window Manager called HyperEbenenProjektionsTreiber (trans: HyperPlaneProjectionDriver)
-boots within a second
-APM (just for poweroff at the moment / ACPI in work)
-libc-interface (not finished yet)
-small stage1-bootmanager (will probably not run on pandora)
-USB in work..
and most important:
-Tetris inside the Kernel

I just found one old photo [0] of the OS in the Net showing the work on a webcam driver [1] for linux:
to the right it shows the binary of a bayer picture in ASCII and to the left you see the unbayered picture and the crosshair-mousecursor at the bottom.

I thought perhaps someone finds it interessting so i post it here, but SurO is one of my lifetime projects so dont expect to use it as standard-OS on the Pandora, but who knows, if i get it managed to write a network and audio-driver for the p&|a...

greets
Simon

[0] http://homepages.uni-paderborn.de/neuron/p...terpolation.png
[1] http://www.reactivated.net/weblog/archives...60-driver-code/

 

[sindbad]

-Tetris inside the Kernel
For that alone, it is not useless anymore

 

[fusion_power]

"self written OS" wow, not bad. How many OMAP specific Hardware Features could it support? (SGX, 2D, 3D acceleration, Video/Audio encoding etc...)

Na dann, viel Erfolg damit.

 

[quantenmagier]

How many OMAP specific Hardware Features could it support? (SGX, 2D, 3D acceleration, Video/Audio encoding etc...)

I dont know yet, first it needs to just run on an ARM, the acceleration-part will follow later, I thought about using DSP for 2.5D-Graphics-Acceleration because it'll probably be easier, but of cause the features you mentioned would be greater, so this depends on how good they are documented and how much time i have in spare for reverse engineering it.. h34r:

Na dann, viel Erfolg damit.

Besten Dank. - ( da fällt mir ein ich überleg ob ich auch noch im deutschen Forum posten sollte... vielleicht in nen par wochen wenn ich erste resultate für ARM habe...)

 

[Squidge]

-Tetris inside the Kernel

as long as we know the kernel isn't bloated

 

[quantenmagier]

-Tetris inside the Kernel

as long as we know the kernel isn't bloated

well its asm so the assembled tetris-modul has just 1.6 kiloBytes, i think thats bareable for such a great feature :lol: - off cause it would be easy to exclude, its a relict from the beginnings, when it was difficult to load progs from hd, so i put it in the kernel, now the OS has FAT32-support and syscalls so this wouldnt be a prob anymore, but it would feel like a sin excluding it, even if i like to be a sinner sometimes B)

 

[j.pickens]

While I know nothing about the specifics of this proposed OS (other than Tetris, inside!), this posting is the kind of thing which makes the Pandora so unique.
The unlocked, open nature of this project is and will attract developers of all kinds.
I am very excited...
/endfanboy.

 

[quantenmagier]

ok i figured out its not only porting it, lots of things are different, i'll have to completely abstract the asm to make a meta-asm-code running efficient on x86, amd64 and arm.

btw does anyone already know a bit about arm-asm/-arch and can answer me questions like these?:
-is there something separating kernelland and userland like the privelege-rings 0-3 in x86 to prevent userprogs from doing everything?
-is there some kind of hardware-support for multitasking or at least something showing me which registers/registerfamilys are dirty?

thx&greets
Simon

 

[Exophase]

ok i figured out its not only porting it, lots of things are different, i'll have to completely abstract the asm to make a meta-asm-code running efficient on x86, amd64 and arm.

The only real way to do that in general terms is to pick the least common denominator of the three, which is not pretty. A C compiler would probably produce much better code.

btw does anyone already know a bit about arm-asm/-arch and can answer me questions like these?:
-is there something separating kernelland and userland like the privelege-rings 0-3 in x86 to prevent userprogs from doing everything?

There's user mode, system mode, and various interrupt modes.

-is there some kind of hardware-support for multitasking or at least something showing me which registers/registerfamilys are dirty?

thx&greets
Simon

No, there's no hardware support for multitasking, there isn't a lot of support on most platforms (and what's on x86 goes largely unused). I don't see how marking registers as dirty is a good idea, since it'd take more cycles to check if they're dirty than to write them out blindly. I'm not aware of x86 having anything like what you're describing either (what's a register family anyway?).. I'm kind of wondering if you mean to be referring to something else, like cache lines.

 

[quantenmagier]

ok i figured out its not only porting it, lots of things are different, i'll have to completely abstract the asm to make a meta-asm-code running efficient on x86, amd64 and arm.

The only real way to do that in general terms is to pick the least common denominator of the three, which is not pretty. A C compiler would probably produce much better code.


yes picking the least denominator was my first thought too, but as i mentioned its not really efficient, so i thought about writing an meta-asm code looking more like arm, because it will be more easy to produce effiecient subroutines and jumps out of conditioned commands then the other way around, but i will need to write it 2dim to also write which commands can be executed in parallel and whom depends on each other, so that the code is completely abstract... i'll also use new registernames and define the bit-lengths (like variables) for different parts of code so perhaps this will not really be asm anymore but a higher language looking like asm, so my project turns out to be writing a special compiler.. lol
But of cause there will also be a lot of architecture specific asm code perhaps i start with this when i have my pandora and make the abstraction later...

There's user mode, system mode, and various interrupt modes.

Ahh thanks a lot i didnt find this, i'll check it out

No, there's no hardware support for multitasking, there isn't a lot of support on most platforms (and what's on x86 goes largely unused). I don't see how marking registers as dirty is a good idea, since it'd take more cycles to check if they're dirty than to write them out blindly. I'm not aware of x86 having anything like what you're describing either (what's a register family anyway?).. I'm kind of wondering if you mean to be referring to something else, like cache lines.

registerfamily.. MMX registers or normal purpose registers for example are different "familys".
well on x86+ there is the TS flag in the CR0-Register, so if it's set you can switch to a new task without saving the FPU/MMX/SSE+ registers and when a new task wants to use it an interrupt is raised that the OS can save them... and yes it is an overhead to save them at every task-switch B)
yes poorly most people didnt use the task-switching on x86, but i used it and now on amd64 it is gone, so i've to rewrite it completely. h34r:

thx&greets
Simon

 

[___]

Sounds like one heck of a project. Impressive. I always admire people who know asm to this extent. Good luck and hopefully something interesting and useful will emerge from this.

Hehe, wie wäre es mit ein bisschen Quanten Magie für unsere Pandora?