Hacker News Reader

Comment by modernerd | Hacker News Reader

“In the 1980s with things like the Amiga computer, for example, every game was a boot disk. It booted into its own customized version of an operating system that ran what it needed to run to make its game work well and be performant and reliable. … We know that in the past, hardware that was very capable and very interesting made it so easy to create an operating system that literally everybody did it. Not a few people. Not even most people. But literally everybody.”

– Casey Muratori in “The Thirty Million Line Problem” https://youtu.be/kZRE7HIO3vk?t=1205

View on HN

> It booted into its own customized version of an operating system that ran what it needed to run to make its game work well and be performant and reliable

Most bootdisk-based games did not have any kind of "customized version of an operating system". They were running on bare metal. For 99% of the games, there was no abstraction/management layer between the application (the game) and the hardware nor any kind of framework that would impose a certain structure on your application. Of course, game code was structured and you could often find subroutines for recurring tasks (clear screen, wait 100ms, read track from floppy,...) but even those were sometimes directly inlined in higher-level code (e.g. game AI) where it gave a performance advantage.

Only complex games had some kind of very thin abstraction/management layer that you could call an OS (often MUCH thinner than embedded micro-OS like RIOT or Contiki). As an example, Carrier Command had a quite general GUI system.

Also if you take 1 generation step back into the 2600 or intelivision there was a very simple API they did use that was built in. It was usually little more than fill out some memory in a particular way and flick an interrupt or particular instruction and it would either run something in bios or hardware. Also many did not need much in the way of an OS as they usually just either memory mapped themselves into the address space or copied themselves there. At that point if you keep your memory in order you do not need much and can toggle the registers yourself or call into bios routines yourself.

The newer machines use APIs to abstract. Where companies used to conform to particular HW standards (VGA,EGA,etc) with extensions. Now HW companies see their drivers as a differentiator. While the programmer writes to the abstraction API. Technically you could still write bare metal but few companies want to say what their real API looks like. So you are stuck with the OS or if you are lucky what someone else has noodled out.

The Atari 2600 has no BIOS or any other built-in ROM. Maybe you're thinking of the 5200 or 7800?

I was thinking more along the lines of fill in this memory set these registers and stuff happens. Which is not really bios but from a programmer POV it kinda acts like it (just in hardware). Like I pointed out it was a very simple API. Not even sure you could call it that. Re-reading what I wrote yeah I probably should have made that more clear. Intelivision did have a BIOS which they had to have because of the lack of chips they could get their hands on (mostly due to atari buying the capacity for locking out compettors).

I think Carrier Command (at least the PC version) was not a bootdisk game but a normal .EXE.

It should be again like this. I only truly understood C after I wrote my own fully functional Operating System (e.g. paging, interrupts, user mode, multitasking and multicore etc.) and got it running on bare metal. Programming other things in C now often feels like when you beat the final level in recent Mario games ("Champions Road") and replay the core game again, it just flows is easy and highly enjoyable.

I'd recommend every serious programmer to write their own OS.

>I'd recommend every serious programmer to write their own OS.

Um, I do extremely well working exclusively with higher level languages like Python and JavaScript. If we're talking about pure salary, a senior web dev will probably make more than the vast majority of embedded engineers.

I'm totally nitpicking here, but I don't like the gatekeeping of saying you need to be able to use a low level language to be a programmer

Without passing judgement on either side, I think the wording of your comment and the wording of the comment you're replying to speak for themselves. You mention you're talking about “pure salary”, while the comment you're replying to speaks about the enjoyment and knowledge brought about by understanding what's going on under the hood.

You may well have very different yardsticks. Programming means different things to different people.

How are we defining programming. As far as I'm concerned if I can create a small game using Unity, even if I don't really understand what's going on, that is programming.

If an intern writes a small Python script to format CSV contacts, that's programming. Programming can be completely visual as well, such as Unreal blueprints. I don't suggest going that route because it doesn't open up many career opportunities, but it still is programming.

Personally I've never been able to use a lower level language to get anything done. And I still have a fantastic career.

That was a recommendation, not a gatekeep.

I've wanted to do this but had some trouble finding a good reference. Do you have any resources you can share? Thank you! :)

The resource that got me started on this topic was: https://wiki.osdev.org/Main_Page

There's some decent tutorials available on here that provide a good introduction to the topic.

> It should be again like this.

OTOH the time of jumpers and dip-switches for configuring hardware state is over; I am not sure I want to give any gaming company any chance to persist not only in some management layer of my computer but also in peripherals.

Yet many of these self-booting disks would quite happily work when copied to a reboot-persistent RAM drive (the RAD: drive), which showed that although it was claimed that they did all the OS-ey things themselves, actually there was still quite a lot of the original OS still running there.

At the core of it, the AmigaOS exec was tiny and helpful, and things like device drivers were just separate processes that you sent messages to, so it would make sense to make use of them, but just not bother loading all the other stuff that makes up an OS.

Doesn't WHDLoad do that?

Yep.

https://en.wikipedia.org/wiki/Self-booting_disk

He seems to forget that the Amiga had the OS in a ROM (or, in the case of the A1000, in a separate Kickstart disk to be loaded at power-up).

Boot-loaded Games disposed of the GUI (Workbench) and some other things, but the OS was not included in them.

Truly everything old is new again.

Reply on news.ycombinator.com