4016=1 blocks auto-read, not emulated?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
4016=1 blocks auto-read, not emulated?
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.
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.
Re: 4016=1 blocks auto-read, not emulated?
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.
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
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: 4016=1 blocks auto-read, not emulated?
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).
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).
Re: 4016=1 blocks auto-read, not emulated?
It's mentioned in Fullsnes. I thought it was rather well known but apparently not?
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: 4016=1 blocks auto-read, not emulated?
Well, after checking, apparently NO$SNS emulates it perfectly.
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: 4016=1 blocks auto-read, not emulated?
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Re: 4016=1 blocks auto-read, not emulated?
Sounds like the auto-read strobe and $4016.0 are OR'ed together.
Re: 4016=1 blocks auto-read, not emulated?
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
Re: 4016=1 blocks auto-read, not emulated?
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.
Edit: And this also means that the result isn't necessarily 0000 or FFFF, if the B button state changed during the auto read.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: 4016=1 blocks auto-read, not emulated?
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.)
Re: 4016=1 blocks auto-read, not emulated?
"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.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: 4016=1 blocks auto-read, not emulated?
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.
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.
-
- Posts: 275
- Joined: Wed Jul 09, 2008 8:46 pm
Re: 4016=1 blocks auto-read, not emulated?
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).
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: 4016=1 blocks auto-read, not emulated?
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.
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.