Lack of input in Various ROMs

[richard42]

Originally reported on Google Code with ID 133

In a large number of Demo (PD) ROMS, no input registers. This includes:

Pip's Pong by Mr. Pips (PD)
MD5: E821B540A91B7BF088E52ABC02A5CC9A

Simon for N64 V0.1a by Jean-Luc Picard (POM '99) (PD)
3E6FF36AE59F9261ED275FEABBF76CED

And the VNES and SNES 9x N64 ROMs.

This suggests an alternative method of binding input which we don't 
support.

Reported by sknauert@wesleyan.edu on 2008-07-12 04:27:52

[richard42]

Although not a Demo ROM, Pokemon Snap also doesn't register control stick input in
the main game. The menu works fine, though.
Maybe these problems have the same roots?

Reported by shinydoofy on 2008-07-15 10:58:12

[richard42]

There is a part of Paper Mario, aiming Spike's spiny attack - the x-axis fails to 
register while the y-axis does, that doesn't work on either of may machines. Really

odd, since the rest of the game behaves properly. However, these may not be the 
same issue as the demo ROMs. Additionally StarCraft 64 seems not to register input

events on my CD2, but does on my PIII (albeit has some other input issue - the 
cursor seems pulled towards the bottom). 

I'll also point out that I know these aren't joystick (or calibration) related as 
I've tested all these ROMs against the keyboard as well.

Reported by sknauert@wesleyan.edu on 2008-07-16 11:13:14

[richard42]

Hm... might this be a blight plugin input thread issue?

Reported by sknauert@wesleyan.edu on 2008-08-21 04:26:15

[richard42]

I don't quite think so. The old mupen64 0.5 had just the same issues with Pokémon
Snap under Windows. If you used the same input plugin for Project64, I remember the
game doing fine for me.
I assume it has something to do with the PIF in general, not just the plugin to 
answer 0xff01040[0-3].

While we're at it, I just checked out rev 865 and tried to uncomment "#define DEBUG"
in memory/pif.c, but no game I've tried so far successfully started. All I got was
the first 0xff010300 to check for available controllers to respond, but the game just
freezes and cannot be stopped by clicking the stop button. Scanned .7z archives
continued to scroll down my terminal for rebuilding the ROM cache, though.
I know it's a kind of offtopic, but any idea on that?

Reported by shinydoofy on 2008-08-21 16:17:35

[richard42]

Actually your info. (If I understand correctly) seems to confirm my thoughts. 

Blight uses SDL threading internally. I don't know if the Project64 plugin does or

not (I don't have the source). However, SDL needs input events to go to one thread.

If the plugin thread focus changes are an incorrect time it can miss certain types

of input. Where as a plugin without this problem, might work better.

I believe that this issue is more exaggerated on OSX for some reason.

As far as the crash. I did add romcache thread pausing. My guess is the emulation 
thread crashes and either didn't pause the RCS thread (crashes early in the init 
process) or died and the RCS thread was unpaused, since clearly its still running 
if you continue to see RCS messages.

If you want to help with this, feel free to look into SDL input. I honestly am not

an expert and we could really use someone to tackle the issue of getting SDL input

interactively for Gtk and Qt GUIs and threading so we only have 1 input thread to 
remove OSX and possibly other issues.

Reported by sknauert@wesleyan.edu on 2008-08-21 21:58:29

[richard42]

I'd love to help, but unfortunately I nearly can't code at all. The only thing I know
about is the protocol used to communicate with the controller and how to interpret
its responses because together with a coder friend of mine I wanted an open source
N64/GC->USB adapter we found online to feature Rumble Pak support.
That said, the most I could do is try and provide you guys with N64 documentation you
propably already know. I attached it just in case.

Reported by shinydoofy on 2008-08-21 22:47:51

---

• Attachment: CONTROLL.TXT
• Attachment: n64dox.txt

[richard42]

Hm.. some update on this. I switched to the mupen64 basic input plugin and my 
issues in Starcraft64 and Paper Mario went away. The key down / key up functions in

Blight are empty, but seem the only way input is provided in basic. 

This fits the symptom of two methods of input, and one not working. My guess is 
this is a Blight issue, which is better than an odd core issue, but I'm still a 
little lost on the fix. 

Reported by sknauert@wesleyan.edu on 2008-10-01 19:46:16

[richard42]

One way to look at it could be to actually have the PIF printed somewhere to look at
to see if the plugin acts correctly or not. Anything on starting a ROM with DEBUG
#define'd in memory/pif.c?

Reported by shinydoofy on 2008-10-01 20:12:54

[richard42]

Hey, I took a closer look at this and it looks like my Starcraft64 and Paper Mario 
issues were phantom inputs from non-existant joypads on my system due to a bad 
config file.

What we really need is someone with a real N64 and flash cart to try out those PD 
games. Maybe they just don't work. Leaving this issue open since I need to 
implement better sanity checking for Blight.

Reported by sknauert@wesleyan.edu on 2008-10-06 21:07:52

[richard42]

I finally got around to get the PIF printed to console for me. My mistake (as a
complete non-coder) was that I didn't realize I had to press enter every time I want
to progress a frame. So I commented out getchar(); and got the pif on screen. As it
turns out (for Pokémon Snap, haven't tried anything else), blight does its job
perfectly fine, as I understand it:
the PIF is read, "ff 1 4 1" (ff=new command, 1=send one byte, 4=expect four bytes
from the controller, 1=ask controller for button states) for controller 1 (I'm
ignoring the other channels). The core asks the input plugin for buttons and receives
them in some way. To do that, blight correctly reads my gamepad and returns the
correct values to PIF ("a0 0 44 42" for pressing A and Z and pushing the control
stick up and right).

If blight messed up, it wouldn't return the correct values to PIF, would it? So again
my guess is on the core.

Reported by shinydoofy on 2008-10-11 22:57:17

[richard42]

Well, my commercial game issues were just a user / blight default insanity error. 
If Pokemon Snap also works at the plugin level...

that means that there could be a core bug. A minor PIF handling bug might also 
explain some of our issues with DK64 or other copyrighted games.

I wish MooglyGuy was here, so we could test those homebrews on a real N64.

Reported by sknauert@wesleyan.edu on 2008-10-14 06:24:06

[richard42]

Is there any updates on this issue? Pokemon Snap for me is still having issues with
2.0

Reported by daniel@enemyplanet.geek.nz on 2013-08-29 13:11:33

[richard42]

I believe the Pokemon Snap input issue is closely related to the missing red dot issue.
If you recall, in the original hardware, when you first arrive on the beach, there's
a small tutorial where you can't move the cursor until you take a picture of the first
few Pokemon that show up. Once you finish the mini tutorial, you can move the cursor
around as you please. Well, the red dot doesn't work on most plugins, so the game doesn't
detect the cursor locking onto the first few Pokemon, so the tutorial doesn't work,
and thus the input never gets unlocked.

Well, I got a hold of a very buggy port of FatCat's software renderer plugin for Mupen64Plus,
and the red dot works on that, which lets you do the tutorial, and thus the cursor
movement is unlocked and you can play the game as normal. So really, the problem most
likely lies in the video plugins rather than the emulation core. I'm guessing on Project64,
however, they added a hack to force the cursor to move around despite the red dot not
working, which is why it works on that emulator.

Reported by darkmaster14 on 2013-08-29 21:13:19

[richard42]

@darkmaster14: Yes, they are using cheats for pokemon snap roms to fix the input:

[7BB18D40-83138559-C:55]
Cheat0=D1382D1C 802C,80382D0F 0000 //Pass 1st Level and Controller Fix
Cheat1=D11E3C44 2881,811E3C44 2001,D11E3C46 0098,811E3C46 0001 //Make Picture selectable

[4FF5976F-ACF559D8-C:50]
Cheat0=D1381BFC 802C,80381BEF 0000 //Pass 1st Level and Controller Fix
Cheat1=D11E3824 2881,811E3824 2001,D11E3826 0098,811E3826 0001 //Make Picture selectable

[BA6C293A-9FAFA338-C:46]
Cheat0=D1381BFC 802C,80381BEF 0000 //Pass 1st Level and Controller Fix
Cheat1=D11E3744 2881,811E3744 2001,D11E3746 0098,811E3746 0001 //Make Picture selectable

[5753720D-2A8A884D-C:44]
Cheat0=D1381BDC 802C,80381BCF 0000 //Pass 1st Level and Controller Fix
Cheat2=D11E3744 2881,811E3744 2001,D11E3746 0098,811E3746 0001 //Make Picture selectable

[C0C85046-61051B05-C:49]
Cheat0=D1381BFC 802C,80381BEF 0000 //Pass 1st Level and Controller Fix
Cheat1=D11E3994 2881,811E3994 2001,D11E3996 0098,811E3996 0001 //Make Picture selectable

[EC0F690D-32A7438C-C:4A]
Cheat0=D136D22C 802A,8036D21F 0000 //Pass 1st Level and Controller Fix
Cheat1=D11E1EC4 2881,811E1EC4 2001,D11E1EC6 0098,811E1EC6 0001 //Make Picture selectable

[E0044E9E-CD659D0D-C:4A]
Cheat0=D136D22C 802A,8036D21F 0000 //Pass 1st Level and Controller Fix
Cheat1=D11E1EC4 2881,811E1EC4 2001,D11E1EC6 0098,811E1EC6 0001 //Make Picture selectable

[817D286A-EF417416-C:53]
Cheat0=D1381BFC 802C,80381BEF 0000 //Pass 1st Level and Controller Fix
Cheat1=D11E38C4 2881,811E38C4 2001,D11E38C6 0098,811E38C6 0001 //Make Picture selectable

[CA12B547-71FA4EE4-C:45]
Cheat0=D1382D1C 802C,80382D0F 0000 //Pass 1st Level and Controller Fix
Cheat1=D11E3184 2881,811E3184 2001,D11E3186 0098,811E3186 0001 //Make Picture selectable

[39119872-07722E9F-C:45]
Cheat0=D1382D1C 802C,80382D0F 0000 //Pass 1st Level and Controller Fix
Cheat1=D11E30F4 2881,811E30F4 2001,D11E30F6 0098,811E30F6 0001 //Make Picture selectable

Reported by sven@narfation.org on 2013-08-30 07:07:16

[richard42]

Just as I thought. Must be a hell of an issue if they had to resort to cheating (literally!)
to get it to work somewhat. Software rendering seems to fix it, but unfortunately,
the only software renderer plugin available for Mupen64Plus is an unfinished and buggy
"leak". Not to mention it's slow as hell, even on powerful PCs.

Reported by darkmaster14 on 2013-08-30 10:20:44