57 bytes (36 days ago): https://news.ycombinator.com/item?id=42348294

61 bytes (2024): https://news.ycombinator.com/item?id=38962792

67 bytes (2023): https://news.ycombinator.com/item?id=38060165

85 bytes (2023 - Popular, 134 points, 24 comments): https://news.ycombinator.com/item?id=36999463

89 bytes (2023): https://news.ycombinator.com/item?id=36940010

100 bytes (2023): https://news.ycombinator.com/item?id=36933804

134 bytes (2023): https://news.ycombinator.com/item?id=36733256

Very cool that these are all iterations on the same idea by the same person, over a span of a year and a half. The one that had one byte more than today's version was 36 days ago. I really admire their persistence.

Repo has 400+ commits, granted a lot of them are for web demo etc, but this just highlights that sometimes doing really small amount of anything (world limit on peer reviews, anyone?) is often a lot of work

For example, this commit seemed like a lot of work to save a single byte: https://github.com/donno2048/snake/commit/bd6bcb1a1477f28130...

I think it's actually a modest change, the diff looks much longer because registers have been renamed and swapped all over the place.

Has anyone gotten this to work on an actual PC? It runs way too fast, even on an original XT (I'm guessing the keyboard controller isn't the same as js-dos).

Adding in a 100k iteration or so busyloop to the beginning of the food segment should do the trick and only add a few bytes. You could do something fancy with the clock interrupt, which is a bit more portable and stable, but might cost a few more bytes.

Could add a single byte 'hlt' instruction, assuming interrupts are enabled. This would delay until the next timer tick (55ms) or key press/release.

This is ridiculous. So many clever tricks.