Thanks for the font changes. Seems a bit fuzzy but much easier on the eyes. This is great. Reminds me of when I was hired to write a mini OS to test out hardware on an Intel 386 single board computer some company had built back in the day. I swear it took me a month to write the couple of dozen lines of assembler required to get the thing from 16 bit 8086 mode into 32 bit protected mode after reset.
You're welcome! Could you make sure that you're in fact watching on 1080p because for me it looks normal? But maybe I'm just too used to this font and don't notice it because of that. Yeah getting there on x86 seems quite the ordeal from what little that I know about that architecture. I started with actual OSdev in the middle of last year, before that I was only reading about things here and there and looking under the hood for things that interested me mostly on freebsd or linux.
@@arryndoestech Oh, you are right, I have my quality set to "auto" and it switches your vids to 360p. I'm out in the forrest of Finland, 30Km from Helsinki and my mobile network connection only operates at about 5Mbs. It does actually play very nicely at 1080p. I cheated on my 386 OS. I did not use memory mapping, just a single 4GB flat memory space. All "application" code and OS was linked into a single binary. I did get multi-tasking going though. I had the luxury of an In Circuit Emulator (ICE) to debug the thing. Which turned out to be a major pain. For example single stepping through that switch from 16 bit to 32 bit protected mode would always fail under the ICE. But when I let rip at full speed it worked fine! I'm tempted to follow along with you and get adt_os working on a Raspberry Pi or other ARM board I have here.
@@Heater-v1.0.0 That sounds like a cool project! For now I don't want to deal with parsing device trees because it's more involved than I like and there are other things to do first. But I do plan to abstract most of the hard coded addresses into a separate file to be easily changeable before compiling The SMP initialization will most likely be different though I assume because the PSCI stuff will most likely not work. On most boards that I saw cores are brought up by firmware and put into a spin table (core bring up method is usually in the device tree).
@@arryndoestech Ah, I had not though of the device tree thing. That is a complication to far... I'm old school, just let me hit the IO registers as I please :)
@@Heater-v1.0.0 Which is fine if you intend to run your code only on a dozen of platforms. There is nothing wrong with that approach. Linux only adopted device tree so that you do not have to recompile the kernel for every single device on earth, instead we're able to ship generic aarch64 builds that run on a huge number of boards.
I'm not really following his tutorials since they're a little old and for x86-64. I've read a little bit into them but didn't read all of them, so I don't know everything he did in his tutorial. Most of my inspiration comes from my old kernel called "salmon_salad" and is mostly based on self study, reading documentation, testing, reading some source code (specifically xv6-riscv) etc. My goal for this project is to have something that resembles an operating system so things on my todo include: - Virtual memory - Scheduler - User processes - Microkernel style message passing So my approach is to include the bare minimum in the kernel to run user space processes and possibly user space drivers so that I later can continue development in user space.
I was anxious for a new video. Great one. Please don't abandon us haha. Just kidding. Take your time I am looking forward to the scheduler part. Do you plan on testing on real hardware? Not that it is mandatory, but it would be really cool
I won't abandon you guys :) What I could think about is to run this on my M1 macbook air, since I started this journey with the goal of playing around with that hardware. But that's a little away, but I've done this before and know how to get something basic going and display things on the screen of it though :) It was not planned to put it on real hardware though, so we will see when we get further with the project.
Thanks for the font changes. Seems a bit fuzzy but much easier on the eyes.
This is great. Reminds me of when I was hired to write a mini OS to test out hardware on an Intel 386 single board computer some company had built back in the day. I swear it took me a month to write the couple of dozen lines of assembler required to get the thing from 16 bit 8086 mode into 32 bit protected mode after reset.
You're welcome!
Could you make sure that you're in fact watching on 1080p because for me it looks normal?
But maybe I'm just too used to this font and don't notice it because of that.
Yeah getting there on x86 seems quite the ordeal from what little that I know about that architecture.
I started with actual OSdev in the middle of last year, before that I was only reading about things here and there and looking under the hood for things that interested me mostly on freebsd or linux.
@@arryndoestech Oh, you are right, I have my quality set to "auto" and it switches your vids to 360p. I'm out in the forrest of Finland, 30Km from Helsinki and my mobile network connection only operates at about 5Mbs. It does actually play very nicely at 1080p.
I cheated on my 386 OS. I did not use memory mapping, just a single 4GB flat memory space. All "application" code and OS was linked into a single binary. I did get multi-tasking going though. I had the luxury of an In Circuit Emulator (ICE) to debug the thing. Which turned out to be a major pain. For example single stepping through that switch from 16 bit to 32 bit protected mode would always fail under the ICE. But when I let rip at full speed it worked fine!
I'm tempted to follow along with you and get adt_os working on a Raspberry Pi or other ARM board I have here.
@@Heater-v1.0.0 That sounds like a cool project!
For now I don't want to deal with parsing device trees because it's more involved than I like and there are other things to do first.
But I do plan to abstract most of the hard coded addresses into a separate file to be easily changeable before compiling
The SMP initialization will most likely be different though I assume because the PSCI stuff will most likely not work.
On most boards that I saw cores are brought up by firmware and put into a spin table (core bring up method is usually in the device tree).
@@arryndoestech Ah, I had not though of the device tree thing. That is a complication to far... I'm old school, just let me hit the IO registers as I please :)
@@Heater-v1.0.0 Which is fine if you intend to run your code only on a dozen of platforms.
There is nothing wrong with that approach.
Linux only adopted device tree so that you do not have to recompile the kernel for every single device on earth, instead we're able to ship generic aarch64 builds that run on a huge number of boards.
No problems taking a break! This is a marathon not a sprint. What are you going to do when you overtake Philopp? :)
I'm not really following his tutorials since they're a little old and for x86-64.
I've read a little bit into them but didn't read all of them, so I don't know everything he did in his tutorial.
Most of my inspiration comes from my old kernel called "salmon_salad" and is mostly based on self study, reading documentation, testing, reading some source code (specifically xv6-riscv) etc.
My goal for this project is to have something that resembles an operating system so things on my todo include:
- Virtual memory
- Scheduler
- User processes
- Microkernel style message passing
So my approach is to include the bare minimum in the kernel to run user space processes and possibly user space drivers so that I later can continue development in user space.
I was anxious for a new video.
Great one.
Please don't abandon us haha. Just kidding. Take your time
I am looking forward to the scheduler part.
Do you plan on testing on real hardware? Not that it is mandatory, but it would be really cool
I won't abandon you guys :)
What I could think about is to run this on my M1 macbook air, since I started this journey with the goal of playing around with that hardware.
But that's a little away, but I've done this before and know how to get something basic going and display things on the screen of it though :)
It was not planned to put it on real hardware though, so we will see when we get further with the project.