61–70 of 101 posts
Earlier quoted context omitted.
"Unefined" refers to the spec, not the hardware. https://en.wikipedia.org/wiki/Undefined_behavior This case appears to be "undocumented scenario" or "unsupported use-case", though.
Do we know that the developers didn't confirm this hack with the hardware people? It could be "defined by e-mail".
Earlier quoted context omitted.
"Unefined" refers to the spec, not the hardware. https://en.wikipedia.org/wiki/Undefined_behavior This case appears to be "undocumented scenario" or "unsupported use-case", though.
Do we know that the developers didn't confirm this hack with the hardware people? It could be "defined by e-mail".
Earlier quoted context omitted.
I believe that's one of the reasons that games such as Super Mario Bros 3 used additional hardware in the cartridge to do the y scrolling. The memory mapper had special support for just y scrolling and scanline counting. http://wiki.nesdev.com/w/index.php/MMC3
Oh, you don't need special hardware to do y-scrolling correctly. It's just a strange set of writes: $2006, $2005, $2005, $2006. MMC3 is for the scanline counter, which allowed SMB3 to have the score bar on the bottom of the screen.
The counter is based on the following trick: whenever rendering is turned on in the PPU, it fetches nametable and BG pattern tiles from dots 0-255 and 320-340 of a scanline and fetches sprite patterns from dots 256-319, even if no sprites are visible. Because of this, if BG uses the left pattern table ($0000), and if sprites always use the right pattern table ($1000), A12 will remain low during all nametable and BG pattern fetches, and high during all sprite pattern fetches, causing it to oscillate exactly one time per scanline and 241 times per frame.
Earlier quoted context omitted.
Do we know that the developers didn't confirm this hack with the hardware people? It could be "defined by e-mail".
You are playing semantics to try to justify it. If it's not in the official spec, it's undefined behavior.
The one playing semantics is you, since your apparent concern is the definition of the term "undefined behavior" and whether something falls under that definition.
My point is about how well an engineering decision is justified, not what term applies to it according to some document.
Earlier quoted context omitted.
"Unefined" refers to the spec, not the hardware. https://en.wikipedia.org/wiki/Undefined_behavior This case appears to be "undocumented scenario" or "unsupported use-case", though.
Do we know that the developers didn't confirm this hack with the hardware people? It could be "defined by e-mail".
Of course, if you don't have cloners immediately nipping at your heels, you might end up releasing a smash hit that takes advantage of UB in a way that forces you to define the behavior as "it works however it needs to work to keep that game working", because eventually you yourself (the original console manufacturer) will tape out later revisions of the CPU, and you'll want to make sure they can run that game, given that it's "officially licensed" by you.
If you had the right static analysis tools in play, though, you might have wanted to run them over the game, notice the use of UB, and thus fail the game at the QA stage, before things need to escalate to that point.
Earlier quoted context omitted.
Do we know that the developers didn't confirm this hack with the hardware people? It could be "defined by e-mail".
The best definition of "undefined behavior" is: "if some other company created a clone of this console by following the spec to the letter, but otherwise making all their own decisions... would this game run?" Of course, if you don't have cloners immediately nipping at your heels, you might end up releasing a smash hit that takes advantage of UB in a way that forces you to define the behavior as "it works however it…
Vertical scrolling, and emulating the weird side-effects of the registers being written to, was the hardest part of recreating the NES using 3D meshes. It took me a few weekends to get Zelda 2's intro working reliably. I wrote about it a bit myself (probably got a few details wrong or simplified them) here: http://n3s.io/index.php?title=How_It_Works
Earlier quoted context omitted.
This is true, and I don't mean to trivialize the work of today's programmer. However, I suppose somewhat subjectively in reviewing or writing any of this glue or logic layer code using modern web frameworks I've never had the sort of WOW response that I do when I see what the programmers of yore were coming up with.
I think the real reason for this might be that clever hacks using current technology are looked on with disdain, whereas yesterday's hacks are seen as impressive ways of making the most of limited hardware and tooling.
This doesn't preclude compromising readability for hacks when you need to squeeze performance out of some logic (just look at Tensorflow code), but you'd expect a maturing computational environment and engineering culture to reduce the number of clever hacks needed or present.