Lack of input in Various ROMs

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by sknau...@wesleyan.edu on 12 Jul 2008 at 4:27

[GoogleCodeExporter]

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?

Original comment by shinydo...@gmail.com on 15 Jul 2008 at 10:58

[GoogleCodeExporter]

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.

Original comment by sknau...@wesleyan.edu on 16 Jul 2008 at 11:13

• Changed title: Lack of input in Various ROMs

[GoogleCodeExporter]

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

Original comment by sknau...@wesleyan.edu on 21 Aug 2008 at 4:26

[GoogleCodeExporter]

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?

Original comment by shinydo...@gmail.com on 21 Aug 2008 at 4:17

[GoogleCodeExporter]

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.

Original comment by sknau...@wesleyan.edu on 21 Aug 2008 at 9:58

[GoogleCodeExporter]

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.

Original comment by shinydo...@gmail.com on 21 Aug 2008 at 10:47

Attachments:

• CONTROLL.TXT
• n64dox.txt

[GoogleCodeExporter]

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. 

Original comment by sknau...@wesleyan.edu on 1 Oct 2008 at 7:46

[GoogleCodeExporter]

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?

Original comment by shinydo...@gmail.com on 1 Oct 2008 at 8:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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.

Original comment by sknau...@wesleyan.edu on 6 Oct 2008 at 9:07

[GoogleCodeExporter]

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.

Original comment by shinydo...@gmail.com on 11 Oct 2008 at 10:57

[GoogleCodeExporter]

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.

Original comment by sknau...@wesleyan.edu on 14 Oct 2008 at 6:24

[GoogleCodeExporter]

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

Original comment by dan...@enemyplanet.geek.nz on 29 Aug 2013 at 1:11

[GoogleCodeExporter]

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.

Original comment by darkmast...@gmail.com on 29 Aug 2013 at 9:13

[GoogleCodeExporter]

@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

Original comment by s...@narfation.org on 30 Aug 2013 at 7:07

[GoogleCodeExporter]

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.

Original comment by darkmast...@gmail.com on 30 Aug 2013 at 10:20