Thanks for an interesting project! I have also written some bare metal OS projects before and I have a few suggestions for you.
First of all, I recommend using a multiboot capable bootloader (GRUB is one, QEMU and Bochs have built in multiboot bootloaders). This will allow you to skip some of the arcade initialization code required. In particular, loading the code from a floppy is painful because most PCs these days don't have a floppy drive. So while you'll be able to test the code on emulators, running on real hardware require getting a floppy drive. With GRUB, all you need to do is put the binary image in your /boot and you can boot on it with real hardware.
When using multiboot, the bootloader will set up 32 bit identity mapped protected for you.
Many bootloaders also support setting up a graphics mode, which will save a lot of trouble, because you'll have to drop back to 16 bit real mode to access the BIOS interrupts to change the graphics mode.
I do understand the appeal of not using a bootloader and doing things from scratch but when it comes to getting things done, that's just not a good way to go.
I also recommend staying in 32 bit mode, it's just a lot easier. In 64 bit mode you'll need to deal with paging (no identity mapping is available) and this becomes a burden very early in the project when you will need to access memory-mapped i/o devices (in particular the APIC interrupt controller) and Intel Multiprocessor configuration, which are scattered around the physical memory address space.
When you have something that actually works, it is easier to go to 64 bit mode than it is to start from scratch with 64 bit long mode. I found this out the hard way and my hobby OS project[1] stalled because it was just too much work to get anything done in long mode.
In addition, I would recommend emitting debuggable elf files instead of flat binary files. Using the QEMU/Bochs monitor will take care of your most basic debugging needs but to go further, remote debugging with GDB is going to be very helpful.
First of all, I recommend using a multiboot capable bootloader (GRUB is one, QEMU and Bochs have built in multiboot bootloaders). This will allow you to skip some of the arcade initialization code required. In particular, loading the code from a floppy is painful because most PCs these days don't have a floppy drive. So while you'll be able to test the code on emulators, running on real hardware require getting a floppy drive. With GRUB, all you need to do is put the binary image in your /boot and you can boot on it with real hardware.
When using multiboot, the bootloader will set up 32 bit identity mapped protected for you.
Many bootloaders also support setting up a graphics mode, which will save a lot of trouble, because you'll have to drop back to 16 bit real mode to access the BIOS interrupts to change the graphics mode.
I do understand the appeal of not using a bootloader and doing things from scratch but when it comes to getting things done, that's just not a good way to go.
I also recommend staying in 32 bit mode, it's just a lot easier. In 64 bit mode you'll need to deal with paging (no identity mapping is available) and this becomes a burden very early in the project when you will need to access memory-mapped i/o devices (in particular the APIC interrupt controller) and Intel Multiprocessor configuration, which are scattered around the physical memory address space.
When you have something that actually works, it is easier to go to 64 bit mode than it is to start from scratch with 64 bit long mode. I found this out the hard way and my hobby OS project[1] stalled because it was just too much work to get anything done in long mode.
In addition, I would recommend emitting debuggable elf files instead of flat binary files. Using the QEMU/Bochs monitor will take care of your most basic debugging needs but to go further, remote debugging with GDB is going to be very helpful.
Best of luck for your project!
[1] https://github.com/rikusalminen/danjeros