OSDev.org

All hail my mighty tutorial following skillz!
Hey, it's only 2 days of work! I'm sure by next week I'll be in 64 bit mode running Chrome.

jbanes wrote:All hail my mighty tutorial following skillz!

Hey, it's only 2 days of work! I'm sure by next week I'll be in 64 bit mode running Chrome.

Dude OS development is not just copying and pasting code. You must know what are you writing and you must understand it. In future if any errors happen you will lose yourself in your copied codes and will never find the source of the error. Its better to write your own OS.

Good luck my friend

MadZarx wrote:Dude OS development is not just copying and pasting code. You must know what are you writing and you must understand it. In future if any errors happen you will lose yourself in your copied codes and will never find the source of the error. Its better to write your own OS.

I hope you realize I was kidding? I stop to write an OS every few years to see how much farther I can get before I lose interest. What you see on the screen is me sharpening my skills. It's heavy on implementing info I've found on OSDEV, but plenty of the code is my own.

I'll be proceeding into an interactive system shortly. Already solved an issue with GRUB 2.0 on Windows, so I'm feeling pretty good about this go-round.

Good luck my friend

Thank you much, sir!

jbanes wrote: I hope you realize I was kidding? I stop to write an OS every few years to see how much farther I can get before I lose interest. What you see on the screen is me sharpening my skills. It's heavy on implementing info I've found on OSDEV, but plenty of the code is my own.

I'm so sorry if I misunderstood But I like your text UI and that table

MadZarx wrote:I'm so sorry if I misunderstood But I like your text UI and that table

No worries. Completely my fault. I should have been more clear on the status. That's what I get for trying to be funny.

'Nother screenshot is attached if anyone is interested. Not that much more to see. Still, quick breakdown:

• There's a huge decode of the multiboot header that's already scrolled off screen. (It's really not that interesting.) The "Command line arguments" is the last chunk of the decode. Which is, predictably, blank.
• You can see a decode of some BDA information I kinda-sorta care about.
• Used the "float" trick to identify used ATA busses
• Yeah, I just realized that VBE3.0 isn't supported by any virtualization software. That's ok, though. I really way too lazy to try linking in 16-bit segments. Better to put the code in a separate file and load it dynamically anyway. Or just skip the idea entirely and write some basic graphics drivers.
• Scanned the master and the slave in PIO mode. You can tell the master in this case is actually a CDROM drive. (I love the CD-Boot idea for the tutorial, BTW. I expect it will be much better than the old virtual floppy disk days. Tons more space to work with!) The slave is a dud 122MB drive I attached to VirtualBox.
• Fixed the cursor routine so you can see the cursor at the end there. Turns out one does need to be careful about what you write in the VGA color information byte when clearing a line. Doh!
• I had totally forgotten about all the HEX code jokes developers put in this stuff. 0x2BADB002? 0x8086 as Intel's vendor code? 0xCAFE & 0xBEEF for VirtualBox PCI drivers? These guys would be really funny if I wasn't smacking my forehead so hard. (Well, ok. The Intel one is REALLY cool. )

I'm currently working on getting everything in place for reading from the CDROM drive. If I can get file-accesses going, I'll have everything in place to move on to Stage #2. i.e. An interactive session that can load/link/execute programs.

jbanes wrote:

MadZarx wrote:I'm so sorry if I misunderstood But I like your text UI and that table

No worries. Completely my fault. I should have been more clear on the status. That's what I get for trying to be funny.

'Nother screenshot is attached if anyone is interested. Not that much more to see. Still, quick breakdown:

• There's a huge decode of the multiboot header that's already scrolled off screen. (It's really not that interesting.) The "Command line arguments" is the last chunk of the decode. Which is, predictably, blank.
• You can see a decode of some BDA information I kinda-sorta care about.
• Used the "float" trick to identify used ATA busses
• Yeah, I just realized that VBE3.0 isn't supported by any virtualization software. That's ok, though. I really way too lazy to try linking in 16-bit segments. Better to put the code in a separate file and load it dynamically anyway. Or just skip the idea entirely and write some basic graphics drivers.
• Scanned the master and the slave in PIO mode. You can tell the master in this case is actually a CDROM drive. (I love the CD-Boot idea for the tutorial, BTW. I expect it will be much better than the old virtual floppy disk days. Tons more space to work with!) The slave is a dud 122MB drive I attached to VirtualBox.
• Fixed the cursor routine so you can see the cursor at the end there. Turns out one does need to be careful about what you write in the VGA color information byte when clearing a line. Doh!
• I had totally forgotten about all the HEX code jokes developers put in this stuff. 0x2BADB002? 0x8086 as Intel's vendor code? 0xCAFE & 0xBEEF for VirtualBox PCI drivers? These guys would be really funny if I wasn't smacking my forehead so hard. (Well, ok. The Intel one is REALLY cool. )

I'm currently working on getting everything in place for reading from the CDROM drive. If I can get file-accesses going, I'll have everything in place to move on to Stage #2. i.e. An interactive session that can load/link/execute programs.

Its better to display information in a serial console. That way you can scroll up and see the logs. I prefer qemu serial console. Its much easier than others and just needs to write some bytes to a port to get it working

For graphics, it's better to forget about it until you have arrived to user land and you are able to load drivers. Then you must think about writing a native video card driver. Doing this in early stages (Writing a native video card driver or using VBE) is just waste of time. You must add support for resolutions and bit depths and must write a scalable font. So its better to just use text mode. Nothing is easier than copying 2 bytes to memory for displaying a character with nice colors

I'm currently working on a memory manager. Then I will write ATA drivers to be able to read from CDROM or HDD to load the other stuff.
But now I'm stuck in a physical memory manager

And yeah I love that hex numbers. They are funny specially the multiboot magic boot number, 0xbadb002 (bad boot )

Love the Intel code, but can't help feeling a twinge of disappointment, that it isn't 0x4004, or even 0x1101. A bit more obscure (especially 0x1101), but for people who know the history, infinitely more satisfying.</offtopic>

New feature in My OS.
It's called Night Mode and Day Mode.
Night Mode is activated after 6:00 P.M
Day Mode is activated after 6:00 A.M
I plan to add evening and afternoon mode.
No OS has this feature!

sid123 wrote:New feature in My OS. :D
It's called Night Mode and Day Mode.

You mean, you actually use a computer when it's light outside? And you have windows in your room that let light shine through? Oh my...


JAL

You mean, you actually use a computer when it's light outside?

And you have windows in your room that let light shine through?

Vitamin D is good for health......... Although the latest Windows have square and opaque Windows, which don't let light go through. However I have 7 Windows which are transparent.. (Try to look at the near the window buttons of the QEMU window in my screenshot, you can see light passing)
As for the picture I faked the time.

sid123 wrote: It's called Night Mode and Day Mode.
Night Mode is activated after 6:00 P.M
Day Mode is activated after 6:00 A.M
I plan to add evening and afternoon mode.
No OS has this feature!

Well, you can use f.lux for something comparable. http://justgetflux.com/

sid123 wrote:New feature in My OS.
It's called Night Mode and Day Mode.
Night Mode is activated after 6:00 P.M
Day Mode is activated after 6:00 A.M
I plan to add evening and afternoon mode.
No OS has this feature!

Actually my Garmin GPS has this feature.

I think Tom Toms also have it. And my built-in navigation even has a light sensor, used in combination with detection of car lights on/off. But I disgress...


JAL

I'm honestly not sure if this is great or stupid, but this is what is being done.

I meant to post some of these last year, but then I hopped the Pacific and didn't have any time until I got back.

It's been a while since I've posted a screenshot that included elements of my development environment, but with a bunch of work I did over the past month or two I reenabled a serial console and hooked it up to my PTY interface (which I previously posted some shots of here). With that, I can now get a native shell in my host terminal - useful for those odd instances where my compositor crashes! Next on the docket is a new debugger so I can attach to frozen compositor sessions and see what went wrong, but in the meantime, here's the screenies (click for full size):


The serial console actually opens to a special kernel shell. Unlike my old shell, it actually uses a hash table for command lookup, so it should remain rather speedy regardless of the commands I add. Since my kernel is still monolothic, this is all built-in to the kernel; maybe I'll get around to modules at some point, but it's not a pressing matter at the moment. From the kernel shell, a userspace shell (running /bin/sh) can be started, and from there you have basically the same environment as a terminal in the GUI. We can export the compositor endpoint name and start GUI apps from this shell. There are also functions to force a particular UID for the userspace shell, so I could run as a regular user instead of root, as well as some standard convenience functions. It's very reminiscent of my old kernel shell - I might even slap in some tab completion at some point.


There is one minor problem with the userspace shell launched from the kernel serial console: It doesn't set some standard environment variables... particularly ones like $HOME, which things like Python kinda expect or they'll fall back to... well, functions I don't have in my Python `os` module. Meanwhile, the terminal in the GUI was a descendent of `glogin`, which sets those variables, so it can run Python just fine.


Finally, the serial console also does some magic screen size detection on startup, so we can run curses/terminfo apps like vim and they'll show up properly. I had to export TERM=xterm-256color to get colors to show up, but that's expected.

It's not all that much more over what I showed last time, but it means that when I get a network stack, things like telnet or ssh should be fairly simple. It also means I have (potentially) a much better interface for debugging. As an added bonus, I added some configs to run "headless", booting straight into a shell without an active GUI, which is useful for when I just want to quickly test a command line app or new piece of kernel functionality.