The submitted file in2war64.com shows only the blue "background" when run from bare-metal booted DOS floppy on a Pentium D (x64 based on dual x86) with its associated Intel graphics hardware. No sound either.
Your file "war" is a nice binary, works natively as sector 0 of a floppy disk, with a traditional FDD plugged directly into the legacy FDD parallel connector.
On the same hardware.
Also works with USB floppy drive, even on a UEFI PC as long as the Legacy/CSM is enabled and Secure Boot is disabled.
To use a common USB Flash Drive (UFD) natively instead of a floppy, legacy BIOS can require a partition table to be also present on sector 0 of the removable UFD. This can be effectively added by partitioning (format not needed) after copying "war" to sector 0 of the UFD:
from Linux command line:
First copy "war" to sector 0 of the UFD, where X is the identifier of your unmounted UFD:
This overwrites any MBR and partitontable that may already be on sector 0 of the target X UFD; with the functional "war" replacing the MBR, and zeroes replacing the partition table.
Only sector 0 is replaced, all other sectors remain unchanged.
At this point sector 0 of the UFD is no different from sector 0 of the working floppy disk.
Then create a partition on the target X UFD using cfdisk:
(sudo) cfdisk /dev/sdX
make it primary, full size, bootable, type 0C
Only the final portion of sector 0 is altered (leaving the "war" binary intact at the beginning of sector 0), all other sectors remain unchanged.
Then the UFD boots natively just like the floppy.
Still for UEFI need Legacy/CSM to be enabled and Secure Boot disabled.
I was there at Function when it was shown on the big screen, we brought something for c64. At first I expected something else to show up, but then I remembered it was 64 bytes. Sixty four bytes! 256byte scene is insane. I've noticed recent 256b releases are high res. Not sure how they do it, definitely not 13h. Anyways, this 256b still takes the cake: https://youtu.be/eYNoaVERfR4
My cynicism about the widespread disregard for software bloat in the industry is tempered whenever I see stuff like this. Ask a javascript developer to do this and they'll end up with 1500 npm dependecies with an oddball collection of incompatible React plugins, 3d visualisation frameworks, and a codebase that'll be incompatible with the latest and greatest versions of all of these six months from now.
Yeah I know assembly language isn't a sensible choice for all but a tiny specialized niche of projects, hardware/bandwidth is far cheaper than developer time and so on but it's still refreshing to see people doing this kind of thing just out of pure passion.
A little OT but this is why I fell in love with Go (Golang) I think. There's something about the elegance of concise programs written in simple languages.
The 1500 npm dependencies problem you speak of is exactly what I expect to never even see, let alone have to deal with, in the Go ecosystem. It's not exactly surprising coming from one inventor of UNIX and C (Ken Thompson) and Rob Pike, two greats from Bell Labs, but when I heard that the creator of NodeJs had ditched that to go work in Go, now that I registered loud and clear.
After seeing for myself, I can understand. Go is a wonder, truly, and such a treat for systems (from sysadmin to CI/CD passing by performance, readability and safety). Something like Js can only eventually collapse on itself, when there's a better alternative. I mean, we could just as easily bundle a Python interpreter in browsers (to name just one candidate), Js is the frontend bible written in stone only because we keep it this way. Progressive apps are already showing a way between browsers and OS and I expect this line to get ever more blurry as virtualization (containers etc) continues its re-imaging of the entire computed infrastructure.
Oh indeed. And how enriching it is to the programming and systems ecosystem at large.
I'm so thankful that computing evolved so fast that we can be here now, from there/then, and yet still have relatively young giants walking among us. The program-star hall of fame of very alive and active pioneers / creators is honestly humbling and inspiring.
Same here, GUI is a secondary concern in the Go ecosystem. But it only takes one big project, right...
Tbh, I don't know how or why the language wouldn't be suited to very elegant front-end design, I feel the biggest obstacle is general framework fatigue: people are tired of seeing every language under the sun try to do everything, so they stick with what's existing on the frontend (convergence around a few Js frameworks over the last years for instance), while Go devs keep it to server/infra mostly (unrelatingly, just doing their thing). These being just two examples.
Thus GUI options are the same as anything else afaik, provided you can interface with your Go backend. Note that I've heard bad experiences with code injection so I wouldn't try that first nor without extra care.
The solution depends on your use-case, and what platforms you are targetting. I'm partial to KDE on Linux desktop thus Qt is a strong candidate for me; however I dislike non-native apps in most situations so I'm not sure I'd recommend Qt for a wider project in target OS scope. Again, use-case, design specs should preside over this debate. Embedded, sure.
Thanks for reporting! What's your browser? I've only tested with a recent Firefox and Chrome on Windows. I know iOS doesn't work but I don't have a means to debug it.
This is where small embedded devices come handy. Any small cheap board with video output can be turned into a powerful demo (and games) playing machine, at 1/50 or less the cost of hardware in the demoscene era.
