Super Mario Bros 3 Controller handling timing

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
User avatar
displacedgamers
Posts: 3
Joined: Thu Oct 31, 2019 6:25 pm

Super Mario Bros 3 Controller handling timing

Post by displacedgamers » Thu Oct 31, 2019 6:52 pm

Hey NESdev,

I have been scoping controller reads with SMB3, and it looks like the Player 1 controller read happens during the first three non-black scanlines after vblank.

Could you tell me where the acquired input is handled in code relative to the screen draw? Is it processed during the current frame already being drawn or used during the next vblank prior to the next frame?

User avatar
Quietust
Posts: 1492
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Super Mario Bros 3 Controller handling timing

Post by Quietust » Fri Nov 01, 2019 4:58 am

We would have to analyze that particular game in order to definitively answer your question - there is no universal standard by which NES games handle controller reads, but in this particular case I'm guessing that the code structure is probably something like this:
  • NMI
  • Sprite DMA
  • Do any palette updates
  • Do any nametable updates
  • Play music
  • (End of VBLANK somewhere around here)
  • Read controllers
  • Handle controller input
  • Wait for the next frame
Why do you ask?
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

User avatar
Fisher
Posts: 989
Joined: Sat Jul 04, 2015 9:58 am
Location: -29.794229 -55.795374

Re: Super Mario Bros 3 Controller handling timing

Post by Fisher » Fri Nov 01, 2019 7:21 am

Interesting.
I recently noted some random "pauses", just like someone had pushed start on player's 1 controller when playing SMB3 with the kids on a NES clone.

Probably in this case there's something odd going on with the clone.
I tried a pirate version of SMB3 and a original one with similar results.
I don't think there's an easy way to investigate this, does it?
Do it happens with legit NES consoles too?

User avatar
displacedgamers
Posts: 3
Joined: Thu Oct 31, 2019 6:25 pm

Re: Super Mario Bros 3 Controller handling timing

Post by displacedgamers » Fri Nov 01, 2019 12:42 pm

Quietust wrote:We would have to analyze that particular game in order to definitively answer your question - there is no universal standard by which NES games handle controller reads, but in this particular case I'm guessing that the code structure is probably something like this:
  • NMI
  • Sprite DMA
  • Do any palette updates
  • Do any nametable updates
  • Play music
  • (End of VBLANK somewhere around here)
  • Read controllers
  • Handle controller input
  • Wait for the next frame
Why do you ask?
I am doing some research on NES controllers and took note of when the controller was being read on a couple of games. I used Kunio-kun hockey first and saw it was being read after the first few scanlines drawn to the screen. SMB3 kicks off a little earlier and takes a bit longer as it has the double reads for handling potential DPCM corruption. SMB3 also has 4 consecutive latch signals. The second pair is for controller 1. I therefore assume the first pair is for controller 2.

I thought perhaps the controller read would happen closer to the end of a frame just before the start of VBLANK so all handling could be done prior to the next (or rather "current") frame being drawn.

User avatar
tokumaru
Posts: 11466
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Super Mario Bros 3 Controller handling timing

Post by tokumaru » Fri Nov 01, 2019 2:20 pm

Reading the controllers near the end of the frame doesn't make much sense on the NES, because there won't be much time left to process that input before vblank starts and VRAM has to be updated. Moving the player, testing for collisions against the map and other objects, reacting to those collisions, making the camera follow the player (potentially triggering background updates), etc. can take a lot of time, so most games will read the controllers with enough time left in the frame to do all that.

User avatar
rainwarrior
Posts: 7677
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Super Mario Bros 3 Controller handling timing

Post by rainwarrior » Fri Nov 01, 2019 2:24 pm

displacedgamers wrote:I thought perhaps the controller read would happen closer to the end of a frame just before the start of VBLANK so all handling could be done prior to the next (or rather "current") frame being drawn.
Vblank is when the new frame's graphics data are uploaded to the GPU, but that data has to be prepared first.

So if you took input at the very end of the frame before vblank, there would be no time to actually "draw" anything new.

In most NES games, input is taken often shortly after vblank, and then work it done to simulate the game based on that input, and then finally "draw" everything by preparing all the graphics data to be uploaded. Then after all that is done, it will wait until vblank to upload the new data to the GPU.


There is not really much mechanism where it would be sensible to delay reading of input until later in the frame. Most of the work has to be done after input but before vblank, and you also don't normally know in advance how much work that is. If you could accurately predict how long it takes to simulate the game and build the next frame's graphics upload data, sure I guess you could put some wait at the start of the frame and reduce input latency (by a couple of milliseconds at most), but fixed timing like that puts a ton of constraints on a game. Not very practical at all. I doubt any NES games would attempt this. (All of that possibility is even assuming the game even has a significant amount of leftover wait time... which often there is not much of anyway.)

No, the normal input latency for an NES on a CRT is more or less 1-2 frames minus a vblank. Top of the screen starts ~1 frame later, bottom of screen is reached less than 2 frames later. (In theory on a CRT you could lower effective latency by putting the important gameplay visuals near the top of the screen, if you really wanted to.)


All of what I said above is generically applicable to all NES games, but I'm sure it applies to SMB3 as well.

User avatar
tokumaru
Posts: 11466
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Super Mario Bros 3 Controller handling timing

Post by tokumaru » Fri Nov 01, 2019 3:02 pm

rainwarrior wrote:[There is not really much mechanism where it would be sensible to delay reading of input until later in the frame. Most of the work has to be done after input but before vblank, and you also don't normally know in advance how much work that is. If you could accurately predict how long it takes to simulate the game and build the next frame's graphics upload data, sure I guess you could put some wait at the start of the frame and reduce input latency (by a couple of milliseconds at most), but fixed timing like that puts a ton of constraints on a game. Not very practical at all. I doubt any NES games would attempt this.
The best thing one can do to minimize input lag is probably to process all the stuff that's not affected by input first, such as timed events and the like, but I can't think of many tasks that fall in that category. Once those are done, there's no reason to delay input handling any longer, or the game might miss the vblank deadline, and end up with a full extra frame of lag.

User avatar
Memblers
Site Admin
Posts: 3770
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Super Mario Bros 3 Controller handling timing

Post by Memblers » Fri Nov 01, 2019 3:09 pm

Fisher wrote:Interesting.
I recently noted some random "pauses", just like someone had pushed start on player's 1 controller when playing SMB3 with the kids on a NES clone.
Weird, that sounds almost just like the DPCM clock glitch. Maybe other games that use the DPCM channel will have problems? SMB3 (and any other game that uses DPCM) will read the controller port multiple times to make sure it wasn't affected. On a real NES it's only ever seen in homebrews that were made before people were aware of the glitch. It results in phantom button presses.

User avatar
displacedgamers
Posts: 3
Joined: Thu Oct 31, 2019 6:25 pm

Re: Super Mario Bros 3 Controller handling timing

Post by displacedgamers » Sat Nov 02, 2019 12:08 am

Thanks tokumaru and rainwarrior. The NES's itinerary and necessary time for the various steps it has to take to process the input, prepare graphics, etc. does help validate why the input read would be done right at the start of the current frame's scanlines.

User avatar
Fisher
Posts: 989
Joined: Sat Jul 04, 2015 9:58 am
Location: -29.794229 -55.795374

Re: Super Mario Bros 3 Controller handling timing

Post by Fisher » Sun Nov 03, 2019 10:01 am

Memblers wrote:
Fisher wrote:Interesting.
I recently noted some random "pauses", just like someone had pushed start on player's 1 controller when playing SMB3 with the kids on a NES clone.
Weird, that sounds almost just like the DPCM clock glitch. Maybe other games that use the DPCM channel will have problems? SMB3 (and any other game that uses DPCM) will read the controller port multiple times to make sure it wasn't affected. On a real NES it's only ever seen in homebrews that were made before people were aware of the glitch. It results in phantom button presses.
I really would like to have a little more time to dig into this.
Another iten to my "want to-do" list. :roll:

Post Reply