Thanks for working that out -- I had looked into using a JS x86 emulator of some sort to put up a demo when I wrote this, but ran out of time last Christmas :-) Happy to hear it works with that emulator!
Excellent, these are four good sectors in this floppy-sized IMG.
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
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.
You're right, it started as an attempt to fit into 512 bytes but right now it's 4 sectors (2KB). Of course, on a modern hard drive with 4KB sectors, we might stretch our definitions a bit :-) (Though the BIOS still only loads 512 bytes in such a case)
... and now there's a true 512-byte version as well (removing the text and shifting some of the variables to other memory did it) -- `make floppy_1sector.img`. Anyway, thanks for the prompt/challenge!
I got some serious deja vu reading that source code by the way. 24 years ago, as my senior year project I decided I would try to build a DOS-like OS that could boot from a floppy. I didn't get very far beyond a rudimentary CLI, some fun builtin commands and the beginnings of a FAT-like file system...
"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?
In a recent Advent of code (Night 23) I back ported my pascal Solution to Turbo Pascal 7 in DOSBOX... I had to use a file of longint because I couldn't fit 1,000,001 elements in RAM (4 megabytes)... but used a temp file instead. It took 10 minutes instead of 0.25 seconds, but it worked.
No. In fact in one of his recent videos Andreas talked about some of the challenges he and other Serenity developers have had getting it to run on real hardware. QEMU, it turns out, is very "forgiving" even when emulating real HW (i.e. not virtio). That can make it challenging when the code meets real clock-synchronized circuits for the first time.
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.
Fun, reminds me of some similar holiday-themed DOS executables I made back in the day. They were drawn using a program called TheDraw and then could be dumped onscreen with Turbo Pascal or C. Add a few batch commands to check the date in the login script and you’ve got some holiday cheer.
Believe I converted some of them into ansi and was trying to get the old encoding into utf8 last Christmas.
Parent comment was correct at time of posting :-) This was a project from last Christmas that I was encouraged to post again; after inspiration from another thread here I added a new version that fits in a single sector.
It won't work in 2015 and later models because they're UEFI only—anything before that supports BIOS and should run this just fine, and anything later is UEFI class 3, which is starting to become more and more popular in other x86 computers as well.
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.
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!