In this context, 32-bit means the minimal requirement. You can absolutely run even the 16-bit version on a 64-bit PC, provided it has BIOS/legacy-boot mode.

It only won't work on modern pure-UEFI systems because that would require writing full stack of USB drivers for keyboard and mouse, and that would be a huge task.

“Vintage” 64 bit PC’s aren’t a thing.

> Edit: I understand a motivation if it is on simplicity choosing one or the other, but other than that I don't see why that should ever be a goal worthy to be pursued. Software should really "just work" no matter the number of bits and bytes.

Not really how software works.

x86 boots in 16-bit real mode. Then you need to specifically transition into 32-Bit, and from 32-Bit it can be transitioned to 64-Bit Architecture...

The last step (32-bit to 64-bit) can a bit of a can of worms especially on older platforms where 64-bit implementations can differ greatly and 32-bit "just works tm". 32-bit is quite well supported and has enough resources to make some interesting programs work without much hassle.

I think the author has made the decision not to support 64-bit mode due to needing to balance the complexity and usability of the project. It is a hobby project after all.

Since the author maintains a 16-bit and 32-bit for this project I suppose if you wanted you can always fork and maintain a 64-bit version if you wanted to.

Don't worry, this is portable to both vintage word sizes: 32 and 16.

32 is vintager vintage