The earliest revisions of the NES CPU do remnants of a buggy and disabled programmable interval timer on the die: https://www.nesdev.org/wiki/RP2A03_Programmable_Interval_Tim.... This was fully removed in later revisions. Perhaps this was enabled on a dev kit or something — relying on functionality that never worked on consumer units certainly would have led to Nintendo rejecting it during testing.
But even if released consoles had a PIT, it would only be very useful for sub-frame measurements for e.g. timing precise raster effects. Counting NMIs would be by far the most sensible way to measure real time. The NMI fires at the start of each video frame, which is extremely consistent at 60.0988 Hz, and not affected by in-game processing (i.e. game engine may run at a slower/variable framerate if it can’t keep up, but nothing that happens CPU-side can affect the timing of the video signal in any way; the rendering process runs off a fixed timer in hardware).
(FWIW, the audio hardware also has the ability to generate timer interrupts, and many expansion chips have scanline counters that can generate timer interrupts if you need fine-grained synchronization to the rendering process. There’s no shortage of ways to measure time on the NES if you need it).
Wouldn’t that be different on a PAL NES? The parent mentioned that they wanted "to keep track of real time [...] regardless of the frame rate, which varied".
Instead there's an NMI counter (nmiTimer) that counts every VBlank and wraps around every 50 ticks, so it's effectively a seconds counter on the 50Hz PAL version. And in the NMI handler, they keep a running total of cycles spent so they know when VBlank has finished and can stop sending data to the PPU, picking up where they left off in the next VBlank (see the NMI routine in bank 7).
They also use sprite 0 collision detection to flag when the screen redraw has reached the icon bar, so it can force the PPU to nametable and pattern table 0 (as the icon bar's tiles are only in table 0, with table 1 being used for the vector graphics). This is not unlike the original BBC Micro version's split-screen mode, just without any hardware timers (instead, the whole source is littered with macros that check the collision flag - not very elegant, but it works).
Having hardware timers would have made things a lot easier!
What a fun era of development.
When they were trying to get approval for Nintendo for some game, it turned out that one specific version of the USA NES wouldn't work, or the game was making the system overheat (I don't remember exactly). Andrew told me that they had to fly all the way to the Nintendo's HQ to deal with this since they were on a tight window to release. It also turned out that there were fewer than a hundred of that specific version of the NES in circulation.
Ah, I found the note in my (unpublished) book:
Tests for games were not exclusive to gameplay either. Games had to be tested in each possible NES console they would be played on. Beam Software’s Andrew Davie recalls flying to Nintendo’s offices in Washington, in response to the game “The Three Stooges” causing problems on a NES system that they were testing it on. He recalls there being “something like 23 variations of the machine, with different chip manufacturers, etc.” that the game had to be tested on to pass Nintendo’s tests. Once the problem was diagnosed (the way Davie had programmed the game, due to the lack of official documentation, made the NES run too hot, which caused flickering sprites throughout the game; instead of writing the sprite data into RAM as the official documentation called for, Davie wrote the data every two seconds), the game was fixed and accepted for release; after this, the problematic NES console was removed from Nintendo’s testing line-up, with Davie being told that only around 5 consoles with that combination of chips was in circulation in the entire USA."The software development was chaotic. The chaos provided a lot of freedom and opportunity but caused some serious problems too."
Love this insight.
... but then you realised that anyone bright enough to work it out was unlikely to have accepted the promise or the job? :)
> I still don't understand.
Mr Braben's company Frontier didn't own the Elite franchise. You were amongst many deceived e.g. "Elite: Dangerous Role Playing Game" [1]. This company ceased its false claim to own the Elite franchise some years back.
Another problem facing Mr Braben's attempts to get a publisher for another space game under his name was his reputation in the industry. His previous attempt, "Frontier: First Encounters", was notably characterised by PC Zone magazine as a bow-wrapped turd [2]. After Mr Braben's repeated patches, a recall, a reissue and another recall, the game's long suffering publisher gave up and sued him for damages of £722,834.63 plus interest [3].
[1] Elite: Dangerous Role Playing Game (ED RPG) is the subject of an intellectual property dispute https://web.archive.org/web/20170303095150/https://www.kicks... [2] Frontier Worst Encounters, PC Zone https://web.archive.org/web/20231007232510/http://www.eliteh... [3] Gametek V Braben https://www.pdf-archive.com/2017/10/20/gametek-v-braben-writ...
Looking at the source github, it appears I misremembered, or likely didn't even understand what Braben was saying. elite-source-bank-7.asm has a comment saying, "Update the NMI timer, which we can use in place of hardware timers (which the NES does not support)". It looks like they somehow implemented their own real time (ish) clock by counting non-maskable interrupts.