I think one great way to do this is to get a Commodore 64 emulator (or Atari 2600 etc) and start writing and learning 6502 assy. Arguably its one of the last instruction sets that was designed with humans writing code in assembly (and not in some higher level language) making it excellent learning language. You can readily run your code in emulators and for not too much $$$ you can pick a real hardware from EBay to really run it on HW.

And once You think you’ve run hw to its limits there are plentiful demos and examples around to blow your mind watching what people have been able to do with these machines (often in obscure ways).

Does anyone know how to circumvent UEFI?

When the CPU starts, it will start reading instructions from a hard-coded address on the memory bus / EPROM somewhere, right? How can I directly control these bytes?

I don't want some proprietary firmware sit between me and the CPU.

If it's not possible on hardware because "secure boot", or whatever, this should at least be possible in emulators like QEMU.

Does anyone know how to do that? ... or clear up my misconceptions? :)

Not exactly bare metal when you've got UEFI in there.

In the embedded world, Bare Metal means you control the first byte executed by the CPU when it comes out of POST, and aren't using any kind of operating system or proxy loader in between. But it gets kinda fuzzy, because RToS is still "bare metal" and you have full access to the source-code.

If you want to go down a different rabbit hole than being "bare-metal" while still being in UEFI, take a look at EFI Byte Code: it's a strange and arcane little virtual machine that you can use to write cross-platform UEFI drivers. Here's a simple emulator for it: https://github.com/yabits/ebcvm

I recommend anyone just starting with bare-metal assembly to get an STM32F0 board and write assembly programs for it. I'm just gonna plug my super small toy RTOS I wrote for Cortex-M0 a while ago.

https://github.com/kahlonel/rt0s

Just an aside, but it always felt weird to me that we call is bare-metal while the actual code runs on mostly semiconductors.

I am very glad that in my bachelor program our microcontrollers class actually made us hand enter hex codes in a kit. It got tedious after a while (maybe it should have been for only a few weeks not the whole semester), but it gave me a weird sense of being one with the machine. And it has as awesome ice breaker when talking with older programmers. For some of them I am the only one of my age that they have met who has ever done this. Another thing is it helped me sort of see the flow of it and encouraged optimization.

(I don't want to give too much credit to my college, they did it not as some great pedagogical trick but to save money and laziness)

A couple of years ago, I was learning PDP-11 assembly on 2.11 BSD and enjoying it, but then the old textbook got to the point of system calls. I couldn't get anything working properly, so eventually I found something else to do. I did very much like it though.

Also, TIS-100 from Zachtronics (the assembly language game you never asked for!) I think made assembly type programming less intimidating.

There's a bunch of people doing bare-metal work on Ben Eater's two projects right now:

https://eater.net/

It used to be way easier. Something like this:

    debug hn.com

    a 100
    mov dx, 200
    mov ah, 9
    int 21
    mov ax, 4c00
    int 21

    a 200
    db "Hello, World$"
    
    w 300
    q

Edit: Geezus. It's just an example of how accessible getting something running in assembly language was compared to all the qemu, UEFI stuff in the article.

If this interests you I suggest Michael Abrash's Graphics Programming Black Book.

I have a copy I'd sell, although you can find it for free, legally, online. It's about a thousand pages....

You can explore the same world easily in AVR, ARM M0/4, or PIC. And really be running on bare metal.

Does anyone know if qemu and OVMF can be made to work in plain text mode? I just tried but qemu wants GTK by default, and when I pass -curses I get a message that the screen is in 640 x 480 graphics mode. Is UEFI really that complex that it doesnt allow for plain console access?

At first I thought this would be a story about DIY metalwork projects during quarantine.

I always wanted to do this stuff, but classes just never taught it. I think some of the ECE students got some classes which taught some assembly, but not us lowly CS people.

FYI if you're trying to follow along - it appears that QEMU doesn't (for some reason) run on a headless workstation. You'll have to have X installed.

Any instruction to run this under macOS. Qemu can run of course. But ovmf.fd (or install from edk2) seems no clear instruction under macOS.

Is there another level of assembly than bare-metal?

Love playing with Assembly and bare-metal :)

Why are assembly related topics so popular on Hacker News? I don't see pursuit of this topic happening in my anecdata of programmers I interact with in day to day life.

I am not sure if using heavily microcoded CPU instructions qualifies as "bare metal programming."