I posted in Discord before but not here.
Anyway, here it is: The shortest "Hello, world" UEFI app, bypassing various structure.

EDIT: Thank you @revolution for the suggestion of "du" instead of "dw".

You can use du instead of dw.

Looks familiar ...
https://github.com/bitRAKE/UEFI_playground/blob/master/examples/amd64/0_hello.asm

Nice, I thought it required include file from "encodings". Just now I tested, it doesn't need one. Thank you for the suggestion.

Yes! Actually I referred to your this particular example before doing my own similar one. I use the offset in EFI_SYSTEM_TABLE and EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL directly, skipping the need of include files.

By declaring constants, and expanding the rsp value, this code can be made more reader friendly.

Posted merely as some members may find this video as minor interesting.

Youtube Video may be better described as,
'using the UEFI spec to build a game', i.e., 'seems like we wrote Assembly
using an OS, that we compiled using an OS, that we executed in EFI as a game
without an OS. An impressive result for sure, just not quite the (Video) title.'
https://www.youtube.com/watch?v=ZFHnbozz7b4

Seen random Youtube comments;
"This is not really bare metal programming. You're not banging hardware
registers directly but using the UEFI services. Still cool, though."
----
"What I appreciate about this is the proof of concept - actually interfacing
directly with the UEFI to initiate a boot."..."almost all of this is done with UEFI
commands, not 'actual x86 instructions' - but as an example of how to read
instruction references and develop them into a working solution, it covers all
the main bases - timing and a for-while loop, input and output, and parallelization."
..."Basically anything you would need to initiate on boot is covered here or at
least the door to it pointed out."
----
"Only one CPU (core) is active at boot (power up) time. The application
activated the rest on start up as needed. This should make sense. The only
reason why all CPU's are active here is the author of this atrocity decided to abuse
them I assume. Cores can easily be put into an idle state by executing the halt
instruction which will make them 'sleep' until a hardware interrupt occurs or some
other conditions these days."
----
"The fans kick in cause there is no code to put the cores to sleep, resulting in
the entire CPU being 100% busy at all times."
----
"Pretty sure they just used the easiest way to render to the screen within UEFI
and it just so happens to be horrifically inefficient"
----
"also calling the UEFI blit service for every pixel you want to upscale is insanely
inefficient. Do the upscaling in a memory buffer manually and blit the whole
screen once. This game with upscaling does not need more than a single core
to run at hundreds to thousands fps on a modern processor."
----
"They can get the framebuffer address and do the integer upscale in their own
blit routine. The upscale is a blit after all."

----
"When the game says: 'Loading...', it means: counting tics for 1 full second to
calculate how long a tic is. Definitely one of the stranger reasons for a load screen."
----
"(Timestamp)5:06 Caveat: C structs are padded so that 64-bit pointers are
qword aligned. If you neglect that you'll end up with wrong field offsets."
----
"You have to preserve (if you overwrite them) rbx, rsi, rdi, rbp, r12, r13, r14, r15,
xmm4-xmm7 in your efimain, and restore them before returning. The stack pointer
must be aligned to 16 byte boundary before you call any function. You have almost
no ABI comformance in your code at all."
----
"(timestamp)6:20 You can create an image file containing your EFI partition
and add it to QEMU with `-drive format=raw,file=/path/to/image.img`, no
need for a physical USB drive to forward to the VM."
----
"You don’t actually need a real flash drive to test your app in qemu! The
drive option can also accept a folder path, which it will then treat as a drive
image. So all you have to do is create the EFI folder structure, pass -drive
argument, obviously also pass in paths to ovmf, and voila! It’s very helpful
to run this in qemu since you get integrated gdb support meaning you can
very easily step through the code and figure out what’s happening when
something goes wrong"
---
REPLY youtube comment to above comment,
"I recommend creating a disk image rather than executing an EFI application
directly, because it seems to make some of the image (as in, the loaded
executable image) not work properly. I don't remember what didn't work, but
something did.
Also, gdb cannot read symbols in EFI or PDB files, so you need to compile an
ELF file as well to get the symbols. But I guess that doesn't matter much if
you're already writing in assembly."

lol'd when he said, "... the C language - much too rich for my blood." The way he communicates his progress of understanding is very relatable. Very basic use of MASM - the syntax is mostly generic/plain x64, imho. The Zaxxon clone looks really good. Thanks for sharing. (btw, two replies over 10 years apart might be a record - see you in another ten, lol.)