Hacker News new | ask | show | jobs
by paulcole 915 days ago
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.
2 comments

> 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
But why specifically 999,999? That's not an overflow or anything...
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.

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