Both are command line programs, no GUI.
64 bit exe 215,850 bytes
16 bit DOS 5,632 bytes
The bloat is real.
I believe you could make it significantly smaller at least by tweaking the linker settings and building in release mode, if this wasn't it already.
Grab the floppy.img file here: https://paste.c-net.org/CannotCursing
Then head over to: https://copy.sh/v86/
Set the "Floppy disk image" to the above-downloaded file, and click "Start Emulation"
Cheers & Best wishes!
Copy verbatim bitwise to a floppy and it boots bare metal in 5 seconds to the animated graphic.
You only need the first four sectors; 0, 1, 2, & 3, or about 2K.
Sector 0 is a working MBR/bootsector which continues with sectors 1, 2, and finishes with 3.
On a USB flash drive most BIOS will want to treat it like a HDD rather than a large floppy so you will need to add a partition table on sector zero before it will boot from a HDD.
So write zeros to the USB drive[0] then eject, reboot and copy the first four sectors (or the whole 2880) from treeosFloppy.img to the blank USB drive[1].
[0] dd if=/dev/zero of=/dev/sdx
careful with dd at the Linux command line, make sure /dev/sdx is the exact USB drive you want to wipe
[1] dd if=/mountedlocation/treeosFloppy.img of=/dev/sdx bs=512 count=4
Then partition the USB drive using CFDISK at Linux command line, in MBR layout, marked bootable, as type 0c FAT32.
-this simply adds a partition table to its designated empty space still remaining on sector 0, the treeOS MBR bytes are still there on sector 0 after this too. The USB drive should now boot directly to the animated graphic not much differently than the floppy.
--treeOS MBR does not actually utilize the partition table bytes, but when it's not a floppy, BIOS will not normally load & run sector 0 unless an active marked bootable partition table of some kind is found in its proper place on the physical sector 0 to begin with.
Reboot to Windows then quick-format the USB drive FAT32 using Windows. Do not repartition, just quick-format.
-the USB drive should now work normally for storage
--but when properly selected as a boot device, will go directly to the graphic
Alternatively using a regular HDD you can copy sector 0 of treeosFloppy.img to a new file on NTFS like c:\treeos.mbr then Windows BOOTMGR and/or NTLDR can be configured to put treeOS on its built-in Windows bootmenu alongside Windows by correctly referencing c:\treeos.mbr as a bootsector entry. As long as Windows is installed on a MBR-layout HDD for BIOS booting. With sectors 1, 2, & 3 of treeosFloppy.img in place on the corresponding (otherwise unused by BIOS) 1, 2, & 3 positions on the HDD, when c:\treeos.mbr is selected you can get the treeOS graphic from a Windows bootmenu even while Windows occupies sector 0 with its own regular Windows MBR.
Plus then you're already multibooting Windows the factory way.
Merry Christmas!
> that uses the BIOS to load data from the boot disk
That's not a bootsector demo (it's larger than 512 bytes). From reading the source: It's a hybrid bootloader + demo, in a pragmatic manner.
Here's an eclectic selection of other nice, not widely known christmas themed demos I found earlier (merry christmas!):
https://www.youtube.com/watch?v=6X74bhXltFo (BBC Micro)
> Bitshifters - Xmas 19 Demo
---
https://www.youtube.com/watch?v=1t02TvLbQec (PC, CGA)
> Una simpatica demo natalizia datata 1986 per l'amato PC. Quante volte l'ho guardata quand'ero più giovincello:o)
---
https://www.youtube.com/watch?v=hDitgPGh_MQ (Atari 8-bit)
> christmas collection demo for Atari 8-bit
"hey, I made something that could boot from a 1981 PC, from scratch, and I understood it all the way.".
That's a pretty nice feeling - I think you probably felt the same way?
I do like the VM-based OS approach for hobbyist OS's, though. Unless one is specifically interested in the challenge of supporting actual hardware, I think the "QEMU first" approach is the way to go. It simplifies the otherwise-vast problem space and encourages other hobbyists to try out your system or join your development effort.
My first hobby OS project (~2000) was done by repeatedly writing a floppy image to 3.5" disk and booting it on an old junk laptop I had. It was painful and since then any hobby bare metal programming that doesn't involve microcontrollers I will happily do from the comfort of my modern machine and a VM.
> Show HN: TreeOS – A 16-bit bootsector Christmas tree demo (2019)
... as there are no new commits since 25 Dec 2019.
For M1, this obviously won't work because it's a different architecture. I'm not sure exactly what standard they use to boot, but nothing's stopping you from disabling secure boot and booting whatever you want. Their GPU may not support VGA, though.
Believe I converted some of them into ansi and was trying to get the old encoding into utf8 last Christmas.
