OSDev.org

earlz: A lot of time and work went into Pure64. At some point it will most likely be open sourced but for now I'm just releasing it in binary form.

quanganht: What file system would you like it to support? I mentioned earlier about the possibility of FAT12 but that was a mistake on my part. Pure64 will not work with floppy disks. ext2/3/4? Or something more custom?

ReturnInfinity wrote:earlz: A lot of time and work went into Pure64. At some point it will most likely be open sourced but for now I'm just releasing it in binary form.

quanganht: What file system would you like it to support? I mentioned earlier about the possibility of FAT12 but that was a mistake on my part. Pure64 will not work with floppy disks. ext2/3/4? Or something more custom?

Just dropping idea's here but ISO9660 might be a good idea for another file system; most people that have moved on from floppies are either using CD-Roms/DVD-Roms (Blu-Rays?) or hard drives (AFAIK at least).

Creature wrote:Just dropping idea's here but ISO9660 might be a good idea for another file system; most people that have moved on from floppies are either using CD-Roms/DVD-Roms (Blu-Rays?) or hard drives (AFAIK at least).

That's one of the FSes need to be supported. About HDD, I'm planing to make my own file system, which should increase my control and have less overhead.

v0.4.7 is out now. 100% more open-source too!

Mainly bug fixes from the last release.

Ooh! What a good news! The code is very well commented. It is an excellent tutorial for anyone
who wants to write a 64-bit operating system. Maybe in next days, we will see some new OS projects
which use Pure64 as a bootloader, or an improved version of it. Or why not some forks of BareMetal...

Keep up the good work!

Superb!!! It is exactly what i want! I hope that the support for iso9660 will come with the next release!

I've tried to load the example image in qemu using the -hdd argument but it doesn't work. If i use the -hda argument it works.. The screen say: "Initializing the system..." but nothing more. In the right corner there is the number 26 if it can help..

Srowen wrote: I've tried to load the example image in qemu using the -hdd argument but it doesn't work. If i use the -hda argument it works.. The screen say: "Initializing the system..." but nothing more. In the right corner there is the number 26 if it can help..

Works on my qemu (it is the one provided in the BareMetalOS distribution). For information, that number '26' is displayed before 'call hdd_setup'. So, it is possible that the OS hangs here.

I use the following command to simulate a 16-core machine under Windows: Make sure the path (if required) and image name are correct after the "-hda" option.

I literally cried when I found the Return Infinity website. I have been looking for 64-bit OS resources for what seems like an eternity, so finding complete source code is like being touched by the noodly appendage of the flying spaghetti monster . I LOVE YOU!!

Tompaliito wrote:I have been looking for 64-bit OS resources for what seems like an eternity, so finding complete source code ...

You may like to check Cute! ‒ the 64-bit SMP kernel. Per-CPU areas and SMP scheduling are to be committed soon.

Darwish, I think I have spotted a small error in your boot code:

You seem to be setting es twice

Kieran wrote:Darwish, I think I have spotted a small error in your boot code: You seem to be setting es twice

Thanks; added it to my TODO file

Version 0.4.8 was released today. SMP initialization has been completely re-worked (mainly from Brendan's suggestions) and well as general bug fixes.

There is also code for slip-streaming your kernel into the pure64.sys binary (as long as your kernel binary is 22,528 bytes or less). This way you don't need to worry about the file system on the disk.
Testing and comments would be appreciated.

ReturnInfinity wrote: There is also code for slip-streaming your kernel into the pure64.sys binary (as long as your kernel binary is 22,528 bytes or less). This way you don't need to worry about the file system on the disk.

Why 22,528?

Edit: I see, it's 32768 - 10240. Now the question is why does it have a 32kb limit?

Currently pure64.sys is limited to 32KiB since it is loaded at 0x8000 in the first segment.

In the next version it is planned that the boot sector will switch to "unreal" mode before loading pure64.sys into memory.

If "unreal" mode doesn't work out then we could switch to loading pure64.sys into a different segment which would result in a max size of 64KiB.

Either way 22KiB should be enough to add your own file system code if FAT16 is not ideal for your project.