OSDev.org

zenzizenzicube wrote:

octacone wrote:it is one big failure.

There's always a tomorrow

I guess so.

digo_rp wrote:May I have a question, please?
How many times do you think that " the most engineer in the world " failure before the sucess?
do not give up!!!
keep calm...
try to code day by day... line by line... and ...
Lot of coffee...

I am not giving up, am I just disappointed, sure.

catnikita255 wrote:Really lots of times. Even me (12-year old child with sh*t instead of lots of things in my OS) failured lots of times. What about the most experienced engineer in the world? Of course he failured more times.

He failed, but he managed to fix his problems.

sleephacker wrote:

octacone wrote:everything I need (double buffering, transparency, repainting areas) I can't code because I suck. Basic OS is pathetic. We should have a topic called "When your OS sucks". I guess I will have to stick around with my buddy terminal for a WHILE, yeah no multitasking. *cough *cough, no user mode *cough *cough, no system calls *cough *cough, it is one big failure.

Patience, you must have...

Patience = time++; that is the problem, when you want to do something but want to do it in a short period of time..

omarrx024 wrote:octacone, we all as OSdevers have gone through the same feelings you are having. We all have our "aww yeah!" moments and our "I suck" moments. We've all once or twice (many times, really) tried to do something and failed. IMHO, taking up the hobby of OS development and not giving up after "Hello, world!" in itself is an achievement.
jojo beat me to this one; but this is called learning and it's how you teach yourself; by learning from your mistakes.
There are two things you need in this field, patience and persistence.

I remember my first hello world, I was so happy but sometimes that is not enough. Getting deeply into this really messes you up sometimes.

jojo wrote:octacone, I understand the feeling. I really do, and I'm sorry you're there. But this is what we call learning -- you're not going to be great at everything instantly. And, unfortunately, you're still not going to be great at everything after a year of study. Mastery takes time. But it does happen, slowly but surely.

There's also the important question of what mastery actually is. If you define your goals too wide all at once, you're never going to meet them and you'll never feel like you accomplished anything, even if you've accomplished amazing subtasks that you're not giving yourself credit for. In particular, if you're trying to write an operating system, you're talking about trying to gain mastery in basically every single domain of computer engineering short of actually doing the electrical engineering. All at once. You've given yourself a task that is basically humanly impossible for a single person, given the number of disparate disciplines and man hours that go into even a relatively niche and unpolished group project like Haiku.

So, what I'm saying is that you have to realize the scope you've set yourself and give yourself credit in light of that. You will make progress. You will learn things. You will get better. I started playing around with this junk when I was fifteen, and now here I am, twelve years later, and I'm still even barely off the ground with my project still myself.

You rock. Just the fact that you've been willing to take on such a hardcore hobby -- and very seriously, I might add -- and gotten as far as you have to this point is incredible. I mean, do you have any idea how many people in the world can even just say they've booted custom code on the bare metal of their PC? Just by doing that, you've accomplished something that the vast majority of the public never will.

That's impressive.

Thank you for saying such nice words. That is right, I have too many goals that I have to meat. There are things that I have no idea how to do, they take tries and tries before you can understand them. "Brute force" method is not really helpful, when you want to do something that you are not capable of and you fail that really lets you down. This hobby is hardcore for sure and it's only purpose is to have fun and LEARN. Learning is important but takes time before you understand something. Giving me a manual won't really help me because without really seeing an actual code I can't get the feeling I need. Reading manuals can be helpful to gain some theoretical knowledge but not to gain skills and abilities. Btw you just remembered me how bad Basic OS is, it can't even boot of an USB, it only works in of emulators. Basic OS had some really well written parts and I am proud of them, but also there are parts that I am really angry about.

catnikita255 wrote:

octacone wrote:Basic OS should be called Pathetic OS!
Basic OS sucks, it will never be good, it will always have broken graphics... I tried to implement double buffering (again) and failed, for the 5th time... I really don't have any hope, everything I need (double buffering, transparency, repainting areas) I can't code because I suck. Basic OS is pathetic. We should have a topic called "When your OS sucks". I guess I will have to stick around with my buddy terminal for a WHILE, yeah no multitasking. *cough *cough, no user mode *cough *cough, no system calls *cough *cough, it is one big failure.

If you want some graphical stuff, check out Surface. I developed it with my second developer for U365, there's drawing functions, transparency and it's just easy to code stuff with it, especially for me
Porting it isn't a problem, the only OS-specific stuff is initalization: you will need to get your framebuffer info and provide it in initialization. Then run init_surface_screen() in your OS initialization routine. After that you can fully use Surface. I attached the archive with the code.

If I were the creator of (the) Surface, I would be proud. It has some really helpful bits and pieces. Although I have like 80% of all the things that (the) Surface has, my problems are: transparency, double buffering and screen updating when dirty. Providing a framebuffer is not a problem, I can do that easily. Thank you for giving me a change to use this stuff. I guess I can try to implement and see what I can do with it. Don't worry the header will be included, I just hate to use other peoples code because that makes me feel like a looser.

In general, thank you guys for this massive support, I really really appreciate it. Also I am going to take a break from GUI and move onto things like file systems, executing programs and making a better shell. I wasn't really going to cancel Basic OS but I really felt like it was pathetic. Can you please tell me what is your favorite part of Basic OS and what part you hate the most. Sorry for any potential mistypes or grammar related stuff, I was in a hurry.

Why don't you post a compiled binary or something so that we can try it out?

I love your command line, it looks pretty good. I don't know about your internals though.

After some lengthy debugging of my get and idt setup and getting the keyboard working, my os looks like this:
(time is just the number of times the IRQ0 was triggered)
(brainOS was supposed to interpret brainfuck code but it turned out to be more advanced)

Looks like a nice start.

bauen1 wrote:(brainOS was supposed to interpret brainfuck code but it turned out to be more advanced)

Welcome to the rabbit hole

I wish I could post a screenshot, but My OS isn't quite there yet
EDIT: My OS is called 'MajickOS'

On the way to a working kernel. I've achieved elf loading (from the initrd provided by the boot loader), run-time linking, virtual mapping, thread switching, idt + ISRs (with PIC, APIC, x2APIC wrappers). All parts of my microkernel loaded in separate threads, although they are just "while(1);" stubs for now. I also have a nice kernel panic function in case something goes wrong: My short term roadmap is as follows: an effective messaging system, IRQs, pre-emption timer.

VFS Implementation

Here is something that I am really really really proud of. It even works on the real hardware.
I would like you to meet my first very own bootloader. It is not really as advanced, but recently I started understanding how it all works.
Now, I know all the steps I need to make in order to make it boot my kernel. Also: assembly is really really tough to learn, but I am making some progress.

Just implemented dir change

Finally, IRQs are routed to device drivers, and ps2 driver sends scancode messages to the user interface task If you wonder what has the frame buffer driver do with cascade IRQ: it's never raised for real, so I've reused it. UI sends a fake IRQ2 message to the framebuffer whenever it wants to flush it's screen buffer to video memory.

Where to begin...

A few pages ago, I showed a Python 3.6 port. That port is now stable and has bindings for my window manager.



I now have a full package manager of cool ports that I've built over the years, in fact.



I wrote a blog post about that stuff on my site.

On top of that, I spent the weekend upgrading my toolchain from gcc 4.6.4 to gcc 6.3.



I've also built a new netboot version of my OS - it uses a local kernel and modules and downloads a compressed RAM disk over the network.



You can find out more about the netboot image here. It'll work in VirtualBox and a properly configured QEMU - obviously it relies on network support.

You have been one very, very busy man Kevin, nice work!

Finally bothered to fix the actual rendering code. This shows a png being loaded from an initrd as if it was a proper file, decoded and sent to the display.