It's actually in 510 bytes; the MBR requires a two-byte signature to indicate to the BIOS that it's bootable / that it is a MBR, so you lose the ability to use/work with those two bytes¹.

You can see this in the original code on the line that reads,

          db 0x55,0xaa            ; Make it a bootable sector

So, 1% more impressive. (The original submission calls it "in 512 bytes" too.)

Now, what I'm curious about is the filler before the signature. You have to pad the binary to 510B prior to emitting the signature, s.t. the signature is in the right place. The author pads with 0x4f … but why that octet, and not, say, 0x00?

¹Unless, I suppose, you realize you need a 0x55 0xaa in your code somewhere, and re-use the signature. But that is not the case here. But I wouldn't put it past some of these tiny code challenges, as the authors tend to be quite clever.

If you're going to be pedantic enough to mention the 2 byte signature, I think you need to be more precise than '1% more impressive' when its less than 0.5% length differential. Or are you suggesting a non linear relationship between size and impressiveness??? I suppose a 1 byte pacman would be more than 100% more impressive, so that fits?

Everyone arguing this isn't "technically" 512 bytes... come on. That goes against the spirit of this post. I feel it was merely an illustration. I mean, at some point just enjoy life and stop being so "technical".

This is HN. I guess being so technical is what makes HN fun for many of us! :-)

People (me included) are just pointing out how bad of an illustration it is.

Technically, it is 512 bytes, but it does not give me any sense of scale. "There's a lot of pacmans in there, so 512 looks like a lot".

Granted, I looked at it from my phone, so that probably biases me towards long- or short-looking text (I even had to scroll).

4 times more RAM than the Atari 2600 has.

True, but let’s not forget that the game code is usually in much bigger ROM on the Atari 2600 (and I forgot whether bank switching hardware and similar cartridge extension hardware was common there). Still mind boggling how little RAM you had for game state. And that you actually did not have a framebuffer at all, meaning that you essentially had to draw each pixel (or scanline?) when it came up!

I'd say about 10% of games had some sort of bankswitching. I think about 2 or 3 games even had a 256-byte expansion RAM.

Not only was there no framebuffer and only 128 bytes of RAM, but the graphics chip didn't generate any interrupts (it could halt the CPU until the start of the next scanline though). You had to wait and spinlock on a timer for the proper amount of time after finishing your frame and processing game state to start drawing the next frame.

You also manually had to tell the graphics chip to output VBLANK lines so you had to do that at the right time as well. If you got the timing wrong on that the vertical hold on your analog TV would lose sync and the screen would jitter or roll.

Oh, interesting. Do you happen to know how that bank switching and, more so, the RAM expansion was implemented? I heard before that this wasn’t common, because of a fatal omission in the cartridge connector. And indeed, looking at the pin out, it seems to lack a Write Enable line, or really anything else besides Address and Data lines! https://old.pinouts.ru/Motherboard/AtariCartridge_pinout.sht...

Are the Data lines still bidirectional? Or was this achieved by strobing the Address lines in a certain pattern?

All I know is the majority of carts with it had a few specific addresses that triggered the bankswitch when written, toward the top of memory right before the 6502 vectors. I'm unsure how they were implemented electronically.

At least one chip (the FE device for Decathlon) is sniffing the 6502 instruction stream because it triggers on JSR/RTS being executed.

http://blog.kevtris.org/blogfiles/Atari%202600%20Mappers.txt

http://www.classic-games.com/atari2600/bankswitch.html

There are a lot of games where you could represent state inside 10 bytes.

Imagine candy crush for example - just just need a level counter (1 byte) and a bitmap of which candies have been collected (8 bytes).

The 2600 was such an interesting machine for its lack of video RAM. Developers "raced the beam" to draw things just in time for them to be displayed, changing colors and sprites partway through a line to make all the cool (for the time) effects.

Funny, my smallish ARM Cortex-M / VGA DIY video console also works like that, with less RAM than needed for a framebuffer. There are framebuffer modes, but with less pixels/bpp than natively output by the video signal output.

Still cool.

But it only used RAM for things that changed. It used the much bigger ROM for code and static data. Consoles of the era could get away with very small amounts of RAM because of that.

This is slightly misleading. the "pacmanpacman..." example is based on the alphabet "pacmn\n", which consumes 6 bytes of ASCII space but actually utilizes only log(6) bits (less than 3 bits) of entropy for its alphabet. A more realistic visualization of 512 bytes would be something like this comment, which utilizes more of the range of ASCII encoded bytes. An interesting comparison would be to write a text description of the pillman game as implemented, and see how many bytes are needed.

It's not misleading at all. It could have been 512 of the same character. It's not about how it can be stored more efficiently, it's just to visually demonstrate 512 bytes, which requires 512 characters (in straight ASCII anyway).

I'd counter and agree it's misleading. Repeating a word "pacman" int(512/len(word)) times does not give me the idea of how small 512 bytes is. It actually looked like a lot of text to me (whereas my description of that comment fit in ~45 characters).

If the original code was 512 (well, 510 if you deduct the signature, 446 if you also include the DOS partition table) bytes of asm source code, then the analogy might make sense.

Yet your whole refutation, which is quite a small comment, a couple of lines is 432 characters.

512 characters isn't a whole heap. It's more than some, but not a lot, and less than the kind of binary most languages do produce today.

A visual demonstration doesn't need to be nitpicked. (293)

As you say yourself, my comment not saying much being almost 500 bytes tells me more how tiny 500 bytes is, than the "visual demonstration".

The fact that it is so, tells me that the visual demonstration is off. I am not the only one who feels that way, so while it's definite that any visual demonstration will fail with some, this one seems to fail with many.

That, to me, is a bad visualisation, and defeats the purpose of the visualisation: you may call it nitpicking, I just call it bad use of a tool (visualisation and analogy). I even feel it confuses the scale, instead of clarifying it, which means that it should be called out.

Note that at no point was I claiming that 512 bytes is a lot, which you seem to also be arguing against. FWIW, I've written bootloaders in my high school days in 446 bytes, so I understand how little that is, even if one uses BIOS to drive the keyboard and the screen.