4016=1 blocks auto-read, not emulated?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

4016=1 blocks auto-read, not emulated?

Post by rainwarrior »

I discovered by accident that if I write 1 to $4016 and leave it that way, automatic controller reading fails to work. I haven't found any emulator that replicates this behaviour, so I made a test ROM:

ROM: ctrltest_unstrobe.sfc
Source: github

This ROM displays a continual report of the auto-read result.

Press A on controller 1, and $4016 will be set to 1 for 4 seconds, then it will return to 0. During this time, you should notice that your controllers will only report 0000 or FFFF (if pressing the B button).


Has anyone observed this in the past? Has this just gone unnoticed because it's an odd thing to try, or maybe this is an "only on some machines" kinda thing? Please give the ROM a try and report back, if you're able.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: 4016=1 blocks auto-read, not emulated?

Post by dougeff »

Why would you want to write 1 and leave it that way?

Are you trying to make reads fail on purpose?


Edit, I couldn't find any mention of this behavior in any documents, official or otherwise.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: 4016=1 blocks auto-read, not emulated?

Post by rainwarrior »

Yes, demonstrating the failure on purpose is the point of the test.

If you're asking how I accidentally discovered it, I had a bug in my multitap-detection code (which involves manipulating $4016 and reading stuff in between), which in one path branched out without returning $4016 to 0. I didn't notice the problem right away, because no emulator appears to duplicate this behaviour, and for the past few days I've had my mouse in port 2 which prevented the bug in the affected program (the mouse would be detected and had its own read which would toggle $4016 manually).
Kingizor
Posts: 24
Joined: Sat Jun 18, 2011 10:50 am

Re: 4016=1 blocks auto-read, not emulated?

Post by Kingizor »

It's mentioned in Fullsnes. I thought it was rather well known but apparently not?
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: 4016=1 blocks auto-read, not emulated?

Post by rainwarrior »

Well, after checking, apparently NO$SNS emulates it perfectly. :)
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: 4016=1 blocks auto-read, not emulated?

Post by creaothceann »

You could report it to the ares guys; SNES9x also seems to be still in development.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: 4016=1 blocks auto-read, not emulated?

Post by Fiskbit »

Sounds like the auto-read strobe and $4016.0 are OR'ed together.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: 4016=1 blocks auto-read, not emulated?

Post by dougeff »

No, the Fullsnes doc seems to suggest that you get the B-button read over and over (instead of all buttons)
nesdoug.com -- blog/tutorial on programming for the NES
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: 4016=1 blocks auto-read, not emulated?

Post by Fiskbit »

Right, that's consistent with what I said. When OUT0 remains high, you will get the current state of the first button on every read instead of a latched report of all buttons.

Edit: And this also means that the result isn't necessarily 0000 or FFFF, if the B button state changed during the auto read.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: 4016=1 blocks auto-read, not emulated?

Post by rainwarrior »

Fiskbit wrote: Sat Oct 08, 2022 12:56 pmAnd this also means that the result isn't necessarily 0000 or FFFF, if the B button state changed during the auto read.
Technically yes, though it's such a short window that it's very tedious trying to make this happen in my test ROM. The difference probably shouldn't matter to any PC emulator, but maybe an FPGA clone could pick it up.

Like dougeff suggested, there's basically no reason to do it intentionally, and it's not going to affect any correctly made existing games, but it seems like I pretty easy/minor thing to add to an emulator and it can catch homebrew bugs.

Maybe you could use it as "Press B to detect whether you're using an emulator." (Until emulators get an update 5 minutes later.)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 4016=1 blocks auto-read, not emulated?

Post by tepples »

"5 minutes later"? You'd be surprised. I get the impression that a lot of emulator developers aren't interested in correcting obscure behaviors just to pass test ROMs if the behaviors don't affect a bona fide game. The lack of a sense of urgency in response to Telling LYs for Game Boy, NES, Super NES, and GBA shows this.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: 4016=1 blocks auto-read, not emulated?

Post by rainwarrior »

That one is particularly problematic to support in an emulator, which the thread discussion bears out.

This one isn't at all. At least 1 emulator has already been updated, and noca$h already has it.

The hypothetical was suggesting using it in something that isn't merely a test ROM... but really I was saying that there's not really anything particularly interesting you can do with this. Mostly just useful for developers to keep in mind.
KungFuFurby
Posts: 275
Joined: Wed Jul 09, 2008 8:46 pm

Re: 4016=1 blocks auto-read, not emulated?

Post by KungFuFurby »

This sounds like a detail that carried over from reading a standard NES controller, citing the wiki. Even though I didn't realize it wasn't emulated, I think I recall reading the NESDev wiki one day in order to solve a question of mine regarding controller reads (and, though I forgot the source, recall hearing about some NES functionality being ported over to the SNES, of which the old-style controller reads being one of them).
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: 4016=1 blocks auto-read, not emulated?

Post by rainwarrior »

Yes, holding the strobe high also will hold it on the first button output on an NES. I think that's emulated by some emulators but I haven't checked. It's also probably less error prone on the NES, because you tend to set and clear it before the controller read, so if you accidentally left it on earlier there probably wouldn't be much consequence.

On the SNES, mostly it's only needed for controllers with extended report (e.g. mouse, multitap) and if you're using autoread, you let the autoread do the strobe and you just finish up the report later in vblank. In this case accidentally leaving it on might leave it set forever, blocking out the autoread which can never clear the strobe on its own.
Post Reply