Hacker News Reader

Comment by internetter | Hacker News Reader

The author and the AI video describes some very interesting bugs arisen from assumptions made by the original developers. I'm curious on the technicality of it – what were these assumptions? These are some fascinating bugs. There are some surface explanations here but I have no doubt somebody could write hours worth of content on this, like the other video [0] in the article that discusses real maths.

[0]: https://www.youtube.com/watch?v=BpEcjdr_YDo

View on HN

The Tetris board is 10 blocks wide, so to be able to play the full field, you need to be able to tap left or right at least 5 times before the block lands. Without tapping at super-human speeds, the fastest way to move the blocks that fast is by holding the left or right button down and letting key repeat take over. When that’s someone’s approach, level 29 becomes fast enough that the pieces can’t reach the edges of the board, so it was traditionally called the “kill screen”, since it wasn’t practical to make progress from there. While it’s possible to get to 999999 before reaching level 29 with that play style, it just didn’t happen all that often, and only by the most elite players.

The last few years have seen people learn how to “roll”, effectively lightly pressing left or right and then drumming their fingers on the back of the controller, getting discrete taps far faster than typical. That lets modern players continue playing at level 29 speeds, and since the speed never increases again, they can play until the game gets to situations that could reasonably be ignored as impossible in the 80s.

The essence of this trick being that one can move multiple fingers to hit successively with time intervals impossible for a single finger; the same mechanism is also how fast typists work.

Another comparison is a scratch DJ tapping the crossfader with 3 fingers in quick succession - the 'crab scratch': https://www.youtube.com/watch?v=oUQ7MviIaL8&t=34

Btw, rolling is a relatively new technique. Before that you had hypertapping, where players would hold the controller normally and just press the d-pad obscenely fast. IIRC the fastest hypertappers were capable of 16 presses per second.

I think the assumptions are pretty simple: Almost nobody’s going to get past 999,999 points and nobody’s going to be able to play at the speed of level 30, so we don’t need to worry about what happens in level 30 or what should happen when somebody gets 1,000,000 points.

But why specifically 999,999? That's not an overflow or anything...

I’d have to double check a screenshot but it’s likely the largest number that can be displayed in the area given for the score.

It's likely it's 3 bytes of BCD (binary coded decimal). It's a handy way of storing things like scores, especially on 6502 processors which have built-in BCD handling support.

No BCD support on the specific chip used in the NES, though.

Looks like it might be doing the bcd by hand. See, e.g., L93C7 (and following code) in the disassembly here: https://github.com/CelestialAmber/TetrisNESDisasm

I'm not familiar with Tetris specifically, but for a score display it was rather common to store each individual digit as a tile ID, which helped to speed up drawing that score into the nametable. I wouldn't be surprised if the algorithm that handles score addition was a simple loop that doesn't check the bounds of the highest digit; this would cause it to eventually corrupt adjacent memory in RAM.

Edit: the article covers much of this! Based on the 3 byte display I'm guessing it is indeed BCD as others have noted, with slower software routines to get around the 2A03's lack of a decimal arithmetic mode. The slower operation may be part of why the crash is possible, but the mechanism is simple unguarded lag: NTSC isn't going to wait around forever and the program wasn't prepared for this.

> level 30

This is also an interesting one...

Thought 1 - is this a result of the limitations of assembly coding? Is it more efficient (either computationally or memory-wise) to store 29 constants rather than doing it computationally? This would make "29 levels" a conscious assumption and I'm assuming there must be some kind of technical hardware limitation that makes it 29.

Thought 2 - is this a result of game coding logic?

Game code runs on a game loop. So there is a "minimum" logical number of frames that things could possibly happen i.e. 1 frame. So, the "max speed" is set at 1 frame. You can't go any faster than that. So if they just made (e.g.) 1 frame less per next level, they just decided that 29 frames was a nice starting speed.

This makes "29 levels" less of an assumption, and more a consequence of other decisions.

there's a disassembly here, it looks like: https://github.com/CelestialAmber/TetrisNESDisasm

NES level 29 is a drop per frame, yes

Reply on news.ycombinator.com