Guest post by “Itsy-OS v0.1 is a small 8086 operating system kernel providing two basic services: a simple preemptive task switcher and memory management. If necessary, simple IPC and task management can be added to provide the features of a traditional microkernel. Weighing in at about 380 bytes, Itsy should port well to tiny architectures.”
Thats a tiny kernel…. A kernel smaller than a inode… A kernel smaller than a 4kb demo…. A kernel smaller than my already small manhood….
OS is written in 8086 asm. So basically its not going to port well to tiny hardware.
Since to port will be basically a complete rewrite so the OS will be named something different.
A complete rewrite of 380 bytes?
The entire thing is like ~200 lines of asm… It is also using fairly bog standard ops for the most part, nothing weird really. A complete rewrite probably wouldn’t take very long, assuming the target platform has similar characteristics.
That said, I don’t know how much sense it would make to port this. Its probably most useful for doing something on an 8086 compatible micro-controller or something.
But man, this thing is begging to be implemented directly in the MBR on a PC (which is 512 bytes) – tack on another 100 or so bytes to load your app code from disk and you have what would essentially be a boot loader and a rudimentary OS all-in-one. Probably not all that useful but its certainly a neat idea.
“But man, this thing is begging to be implemented directly in the MBR on a PC (which is 512 bytes)”
Technically only 440 bytes are available for the standard PC MBR bootloader code.
Typically it just needs to be able to relocate itself, read the partition table, find an active partition, and load/execute the first sector in the partition.
This is the operating system’s bootloader, which is responsible for actually loading the OS.
If you don’t care about partitions, then you can ignore the partition table all together, but you still need to last two bytes to equal 0x55AA for the bios to load it.
I’ve created a bootloader recently which searches for and boots the next hard drive. Annoyingly I have systems which have unpredictable boot sequences depending on what’s plugged into them (external esata drives). I can manually override the settings in the bios, but anytime I changed the configuration the bios got confused and reverted to booting esata drives before internal ones. I placed my “skip” MBR on the ESATA drives and problem fixed.
Before anyone suggests I zero the MBR or set partitions to inactive on the ESATA drives, I tried these, but the bios *only* checks for the 0x55AA signature, and without the signature, linux considers the partition invalid.
The next problem is grub, of all things, which insists on identifying drives by their order in the bios, which is obviously very fragile. Maybe this changed recently, but I am disappointed to find grub2 still depending on disk order instead of UUID. It’s insane to guess the correlation between bios partition order and linux since both of those are dynamic between configurations…what a flawed design!
Extlinux solves that problem nicely, loading off of the disk passed to it by the bios in the DX register.
Once the linux kernel loads, it can identify drives using UUID, which is fine so long as the disks are not cloned.
Really that is the issue. Mips, avr, pic and arm don’t have similar characteristics.
It bog standard for x86 but not bog standard for other platforms.
The 200 lot of asm is basically what is in Linux x86 only section of code. Basically 90 percent + non portable.
Separation between platform code and cross platform code has not been done.
8086 chips are normally not used embedded either.
Basically its a experiment in how small can we go. Does not mean it will make any practical sense.
Hence why I said “porting” it in the conventional sense of the word probably doesn’t make much sense.
I don’t at all understand what the rationale would be to actually make something like this truly portable. The conceptual design could be reimplemented on other platforms, tweaking/changing as necessary, but it is very 8086 centric. It is after all only 200 lines or so and it is all ASM – in my mind it is more or less like a small HAL with rudimentary task/memory management completely contained in it. You could certainly write something like this on other platforms, but you would almost certainly want to do virtually everything different as far as implementation details go…
Might be good for some of TI’s old MCs…
Completely agree.
At this point, I spent two hours diving back into 6502 assembly, intending to write a full translation of Itsy into 6502 assembly just to prove a point.
Don’t code after midnight, friends.
I miss coding in ASM. Might have to pick it up again and see what havoc I can cause.