5 ms·

Many years ago, when I worked at Frontier, David Braben told me a fun anecdote about NES Elite. He said they initially got the game working using the hardware t

Many years ago, when I worked at Frontier, David Braben told me a fun anecdote about NES Elite. He said they initially got the game working using the hardware timer in the NES to keep track of real time so that the in-game physics progressed at a constant rate regardless of the frame rate, which varied. When they submitted the game to Nintendo for pre-release checks, Nintendo said they couldn't use the hardware timer because a few of the earliest NESs didn't have working ones. So Bell/Braben had to make the functions in the game maintain their own estimate of how many clock cycles they each took that frame. At the end of the frame they were all added up and used as an estimate for how much real time had elapsed. 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.

NobodyNada 3y ago
Yes, I bet you’re misremembering something — no released NES has a “hardware timer”, in any revision. 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_Timer 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).
- layer8 3y ago
  > The NMI fires at the start of each video frame, which is extremely consistent at 60.0988 Hz 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".
  - MarkMoxon 3y ago
    It is indeed different on PAL vs NTSC. The code relies on the NMI being called at 50Hz - as a result a number of timings are wrong on the NTSC version, so the music is too fast, the combat demo auto-play doesn't work properly, the time reported for completing the combat demo is wrong, and so on. The NTSC version is unfinished, and this is just one area where it shows.
- MarkMoxon 3y ago
  Yes, no hardware timers are used in NES Elite, as there aren't any. 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!
- abainbridge 3y ago
  Interesting stuff. I'm going on a 20 year old memory of a conversation I probably didn't understand at the time, so I'm very fuzzy on the details.
- ndiddy 3y ago
  I believe what Braben was referring to is the IRQ the APU sends when it's done playing an audio sample. This can be used as a hardware timer by playing a silent sample (all zeroes) and varying the sample length and pitch to adjust the amount of time before the IRQ happens. There's a Twitter thread (https://togetter.com/li/753345 https://togetter.com/li/753345) from the programmer of Guardian Legend (a game that uses the APU IRQ for measuring when to switch from displaying the main gameplay to displaying the HUD) that mentions something similar to Braben's story. After the game came out, he started getting reports that it wasn't working correctly on a small number of consoles. It turned out out that Guardian Legend was the first game to use the APU IRQ and Nintendo had never tested that feature at manufacture. After this, Nintendo started instructing developers to not use the APU IRQ.
mmsc 3y ago
I heard the same thing from Andrew Davie of BEAM Software (Melbourne House), who developed Super Glove Ball. Since Nintendo refused to provide the company with any meaningful documentation, they had to come up with various hacks for framerate calculation or something similar. 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, it was a bit different. 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.
throw156754228 3y ago
Curious, what was it like working at Frontier, did you want to share? I almost took a job there recently, but things didn't work out in the end.
- abainbridge 3y ago
  This was a long time ago, when I was only a baby programmer. It's changed beyond all recognition since I was there. It was sort of lovely. The "office" was a farm house in the Fens. There were two dogs in the office. One was a big soft greyhound called Tigger on account of his stripes. The other was a whippet that had to be kept away from people because it was a nervous creature that would occasionally snap at people. I think there was probably about 15 people there when I started. The software development was chaotic. The chaos provided a lot of freedom and opportunity but caused some serious problems too. Suffice to say that when I left after three years to go and write Darwinia with Chris Delay, we wrote a game engine of our own over about 3 months and once we had that, I'd say we were 20x more productive at creating game content than was possible at Frontier on the Dog's Life team. That said, the Frontier tech at the time did have a nice animation system capable of relatively convincing quadruped animation. It could blend walk/trot/canter/gallop animation loops, do inverse kinematics for foot placement and I think it did vertex blending for polys near skeletal joints. And the engine worked OK on a PS2. Darwinia could do none of those things.
  - lttlrck 3y ago
    I had a lot of fun with Dog's Life!! "The software development was chaotic. The chaos provided a lot of freedom and opportunity but caused some serious problems too." Love this insight.
mattlondon 3y ago
Any other insights about working at Frontier? Did you work on Elite 2 or 3 at all?
- abainbridge 3y ago
  Elite 3 (aka First Encounters) was before my time. Braben kept wanting to get another Elite project going, but there was barely enough resource to do a decent job of the two games that were already in development at the time (Dog's Life and Wallace & Gromit in Project Zoo). Most of the staff had been promised that another Elite game was imminent when they were hired. None of us could quite understand why we were making two games about dogs when we owned the Elite franchise. I still don't understand. Probably something to do with Money and Business Deals.
  - chrisjj 3y ago
    > Braben kept wanting to get another Elite project going ... Most of the staff had been promised that another Elite game was imminent when they were hired. None of us could quite understand why we were making two games about dogs when we owned the Elite franchise. ... 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 did not 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 a further space game under his name was his reputation in the industry. His previous attempt, "Frontier: First Encounters", was famously 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.kickstarter.com/projects/edrpg/elite-dangerous-role-playing-game/ https://web.archive.org/web/20170303095150/https://www.kicks... [2] Frontier Worst Encounters, PC Zone https://web.archive.org/web/20231007232510/http://www.elitehomepage.org/archive/b5090002.jpg 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-1996/ https://www.pdf-archive.com/2017/10/20/gametek-v-braben-writ...

NobodyNada 3y ago

Yes, I bet you’re misremembering something — no released NES has a “hardware timer”, in any revision. 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_Timer 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).

layer8 3y ago
> The NMI fires at the start of each video frame, which is extremely consistent at 60.0988 Hz 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".
- MarkMoxon 3y ago
  It is indeed different on PAL vs NTSC. The code relies on the NMI being called at 50Hz - as a result a number of timings are wrong on the NTSC version, so the music is too fast, the combat demo auto-play doesn't work properly, the time reported for completing the combat demo is wrong, and so on. The NTSC version is unfinished, and this is just one area where it shows.
MarkMoxon 3y ago
Yes, no hardware timers are used in NES Elite, as there aren't any. 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!
abainbridge 3y ago
Interesting stuff. I'm going on a 20 year old memory of a conversation I probably didn't understand at the time, so I'm very fuzzy on the details.
ndiddy 3y ago
I believe what Braben was referring to is the IRQ the APU sends when it's done playing an audio sample. This can be used as a hardware timer by playing a silent sample (all zeroes) and varying the sample length and pitch to adjust the amount of time before the IRQ happens. There's a Twitter thread (https://togetter.com/li/753345 https://togetter.com/li/753345) from the programmer of Guardian Legend (a game that uses the APU IRQ for measuring when to switch from displaying the main gameplay to displaying the HUD) that mentions something similar to Braben's story. After the game came out, he started getting reports that it wasn't working correctly on a small number of consoles. It turned out out that Guardian Legend was the first game to use the APU IRQ and Nintendo had never tested that feature at manufacture. After this, Nintendo started instructing developers to not use the APU IRQ.

mmsc 3y ago

I heard the same thing from Andrew Davie of BEAM Software (Melbourne House), who developed Super Glove Ball. Since Nintendo refused to provide the company with any meaningful documentation, they had to come up with various hacks for framerate calculation or something similar. 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, it was a bit different. 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.

throw156754228 3y ago

Curious, what was it like working at Frontier, did you want to share? I almost took a job there recently, but things didn't work out in the end.

abainbridge 3y ago
This was a long time ago, when I was only a baby programmer. It's changed beyond all recognition since I was there. It was sort of lovely. The "office" was a farm house in the Fens. There were two dogs in the office. One was a big soft greyhound called Tigger on account of his stripes. The other was a whippet that had to be kept away from people because it was a nervous creature that would occasionally snap at people. I think there was probably about 15 people there when I started. The software development was chaotic. The chaos provided a lot of freedom and opportunity but caused some serious problems too. Suffice to say that when I left after three years to go and write Darwinia with Chris Delay, we wrote a game engine of our own over about 3 months and once we had that, I'd say we were 20x more productive at creating game content than was possible at Frontier on the Dog's Life team. That said, the Frontier tech at the time did have a nice animation system capable of relatively convincing quadruped animation. It could blend walk/trot/canter/gallop animation loops, do inverse kinematics for foot placement and I think it did vertex blending for polys near skeletal joints. And the engine worked OK on a PS2. Darwinia could do none of those things.
- lttlrck 3y ago
  I had a lot of fun with Dog's Life!! "The software development was chaotic. The chaos provided a lot of freedom and opportunity but caused some serious problems too." Love this insight.

mattlondon 3y ago

Any other insights about working at Frontier? Did you work on Elite 2 or 3 at all?

abainbridge 3y ago
Elite 3 (aka First Encounters) was before my time. Braben kept wanting to get another Elite project going, but there was barely enough resource to do a decent job of the two games that were already in development at the time (Dog's Life and Wallace & Gromit in Project Zoo). Most of the staff had been promised that another Elite game was imminent when they were hired. None of us could quite understand why we were making two games about dogs when we owned the Elite franchise. I still don't understand. Probably something to do with Money and Business Deals.
- chrisjj 3y ago
  > Braben kept wanting to get another Elite project going ... Most of the staff had been promised that another Elite game was imminent when they were hired. None of us could quite understand why we were making two games about dogs when we owned the Elite franchise. ... 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 did not 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 a further space game under his name was his reputation in the industry. His previous attempt, "Frontier: First Encounters", was famously 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.kickstarter.com/projects/edrpg/elite-dangerous-role-playing-game/ https://web.archive.org/web/20170303095150/https://www.kicks... [2] Frontier Worst Encounters, PC Zone https://web.archive.org/web/20231007232510/http://www.elitehomepage.org/archive/b5090002.jpg 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-1996/ https://www.pdf-archive.com/2017/10/20/gametek-v-braben-writ...