[Question] N64 Controller Protocol

Discussion in 'Modding and Hacking - Consoles and Electronics' started by MRKane05, Jun 15, 2018.

  1. MRKane05

    MRKane05 Active Member

    Joined:
    May 16, 2016
    Messages:
    32
    Likes Received:
    8
    Hello all,

    I figure this is the correct place to ask this question. So I stumbled across the project to convert PS2 to N64 here (www.afermiano.com) a while ago, and decided that it could do with a little upgrading. That said and done, there's one thing I've not been able to get around: Super Mario 64 thinks a controller isn't attached where as everything else seems fine.

    There were already replies to commands 0x00 and 0x01, and I added in 0xFF thinking it was the same as 0x00 (to the best of the documentation I could find) but I've still not been able to get the game recognising the chip. I also don't have any way of sniffing the bytes going backwards and forward so am a touch blind in solving this issue.

    Question is: Does anyone know what makes Super Mario 64 special in this regard?
     
  2. Mord.Fustang

    Mord.Fustang Fiery Member

    Joined:
    Feb 17, 2013
    Messages:
    804
    Likes Received:
    180
    MRKane05 likes this.
  3. MRKane05

    MRKane05 Active Member

    Joined:
    May 16, 2016
    Messages:
    32
    Likes Received:
    8
    Fantastic idea! I'd not thought of that.

    Now interestingly it does answer the queries I had, and that is that the original project was correct as the 0xFF (reset) call isn't addressed in this code and I know that it works for Super Mario. Everything else seems to be in order so I can only guess that it's something to do with my hardware setup, be it the clock or even the little PCB I've made.

    I'm happy to share the project work, and also happy to play SM64 using the original controller - but I'm the type that gets "bugged" by things if you will!
     
  4. sanni

    sanni Intrepid Member

    Joined:
    May 30, 2008
    Messages:
    653
    Likes Received:
    77
    MRKane05 likes this.
  5. bagheera

    bagheera Rising Member

    Joined:
    Aug 1, 2014
    Messages:
    65
    Likes Received:
    3
    Well, according to this site, 0xFF should indeed be replied to the same as 0x00.

    I once wrote code for my own adapter and I also use the same reply for 0xFF as for 0x00. SM64 was working fine with that.
     
    zzattack and MRKane05 like this.
  6. MRKane05

    MRKane05 Active Member

    Joined:
    May 16, 2016
    Messages:
    32
    Likes Received:
    8
    I'm actually quite surprised how different the code-bases are for these projects. Usually things that solve the same problem are all similar to some degree but it varies quite wildly - it gives me plenty to go off, but in general it's all coming back to the same thing: it should be working. Two of these projects don't even address the 0xFF call by the looks of things, and talking with other members of the community they've never seen it in use by a game before.

    I'll go back to the original code and see if that works, but the other place where this could be going astray is that I'm using an everdrive to boot the roms. Failing that the issue has to be mechanical somehow - and I have hit cases where the orientation of the clock did matter so it could be a weird issue like that.

    I'm inclined to think I'll probably just call the project complete shortly - but thanks for all the help!
     
  7. fluxcore

    fluxcore Spirited Member

    Joined:
    Nov 5, 2013
    Messages:
    126
    Likes Received:
    4
    MRKane05 likes this.
  8. MRKane05

    MRKane05 Active Member

    Joined:
    May 16, 2016
    Messages:
    32
    Likes Received:
    8
    What a nifty little idea! I didn't know anyone had done a control stick project :)

    It's looking more and more like the problem has to be something in the little setup that I've got, a call not going through with the correct timing, or even a bad solder joint somewhere, and of course I had to pick the one that was in Assembly to modify, when I'm a C-language programmer by profession!
     
  9. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    160
    Likes Received:
    62
    I made a device that is able to transform snes/n64/ngc signals into any of the 3.
    My device does not handle the 0xFF command but certainly works with SM64.
    One thing to remember is that SM64 checks whether the controller is plugged in when the game boots. If it's not, it makes no further attempt to discover the controller and after plugging it in, you'll still have to press the reset button.
    My guess is there's a problem with the 0x00 command, resulting in the console concluding no proper controller is attached, and therefore no further 0x01 commands are issued.
     
    MRKane05 likes this.
  10. MRKane05

    MRKane05 Active Member

    Joined:
    May 16, 2016
    Messages:
    32
    Likes Received:
    8
    Best advice I've got so far!!!

    So going back to the original project it doesn't work with SM64 booted off of the Everdrive. I've got no way of testing if it works as a cart as I sold it not long ago (hobby electronics isn't cheap!).

    Now if I remember the system setup by TuxDC (youtube alias) handles requests from the N64 as interrupts, and I don't know if I could do "better" as far as timing etc. goes than that, but my spidey sense here suggests that it could be a timing issue from what you said. Given that situation I've no idea how I'd go about resolving this one.
     
  11. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    160
    Likes Received:
    62
    What kind of microcontroller are you using?
     
  12. MRKane05

    MRKane05 Active Member

    Joined:
    May 16, 2016
    Messages:
    32
    Likes Received:
    8
    The project uses a PIC16F688 - the guy who made it originally brilliantly documented it in the link I included in my first post. He's been super busy so hasn't had much time to spend on my tinkerings but I do finally have my FPS control for the N64 :) Just oddly no SM64 - it really is the only game I've found that has a problem.
     
  13. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    160
    Likes Received:
    62
    Generally the fastest way to do this is interrupt based. Use an IOC port (interrupt on change) on the data line, then keep sampling the data line and writing its PORT register to a buffer using indirect addressing (FSR) until there's a brief silent period on the data line. That silence indicates the console is done transmitting and now it's the controllers' job to respond. That's where you exit your interrupt handler, see what kind of request the console sent, and immediately form your reply to it..There's a fair bit of time before you have to respond, it's quite lenient.
     
    MRKane05 likes this.
  14. MRKane05

    MRKane05 Active Member

    Joined:
    May 16, 2016
    Messages:
    32
    Likes Received:
    8
    I'll have a rummage around in the code and see what I can do there. Will edit this post if I manage to get anything working/broken.

    Now you might know: I've been having a world of problems soldering these PIC chips into the custom PCBs I've made for them - they simply stop working and seem flakey as all hell - even at low temperatures. Anyone got hints there?

    EDIT: given the setup of the project I couldn't wait for it to go low so through a few nops in (which should have equated to about 1.6us) and that seems to be about the operational spacing of the data coming in, however it still didn't read for Mario while reading fine for the few other games I tried.
     
    Last edited: Jun 18, 2018
  15. MRKane05

    MRKane05 Active Member

    Joined:
    May 16, 2016
    Messages:
    32
    Likes Received:
    8
    I've not been having too much success here. The few patterns I've written to wait for the line to go low are either missing something or flat out not working. So I decided to try a few delays to see if that'd do it, I've gone all the way up to about 64us and it still wasn't enough. I've no way to probe things and see whats happening under the hood so would love any numbers anyone can throw in my direction :D
     
  16. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    160
    Likes Received:
    62
    There probably shouldn't be any (busy) waiting. You'll have to describe much more about what your setup is like and some (pseudo-) code of what you're trying to do
     
    MRKane05 likes this.
  17. MRKane05

    MRKane05 Active Member

    Joined:
    May 16, 2016
    Messages:
    32
    Likes Received:
    8
    Sorry - I was rushed in my prior reply (life, time, blah blah blah). What doesn't help with this is that it's not originally my code (so I don't fully know the extents of what's happening) and it's in PIC Assembly, which is stunningly different from the Assembly I learnt years ago. That said here's the "outline" I suppose:

    -Programme works really well, but obviously isn't sending the correct controller type response to the request given with Super Mario
    -At present when the 00 interrupt comes through for controller type the code immediately sends off a reply of "just a controller, nothing in the attachment slot"

    I've become suspicious that the speed of this reply is too fast, the delay will be somewhere in the order of 1.6us before the PIC sends its reply through. I've been using a basic "btfsc PORTA, N64_DATA" loop to try and delay it sending a reply but while it's working fine for everything else it's simply not working for SM64. This left me wondering "is the delay before the line goes low known?" in the pretense that I could simply have the chip wait x amount before sending a reply. I've had a few pot-shots at doing it this way but with the same results every time (everything works with the exception of Mario).

    To be totally honest I'm not sure this is worth my time as SM64 plays great on the original controller anyway lol
     
  18. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    160
    Likes Received:
    62
    The reply speed can't be too fast. The PIC simply isn't capable of handling it that fast. As soon as the packet from the console's end is done the controller can reply. If there really needs to be any sort of delay, 4µs is the time of 1 bit so go with that. But if you're unable to debug with logic analyser or oscilloscope, I wouldnt' bother.
     
    MRKane05 likes this.
  19. MRKane05

    MRKane05 Active Member

    Joined:
    May 16, 2016
    Messages:
    32
    Likes Received:
    8
    I had that idea earlier and tested in increments up to 32µs with no noticeable difference. It is the controller type that I should be delaying and not the controller response (just to be totally sure).

    To be honest I'm inclined to put this one to bed and call it done. I've got my "dual stick on the N64" setup, with buttons mapped to multiple PS2 buttons (circle and square are both "B") as well as grouped mappings for Perfect Dark (so L2 is "Z+B") which I think is pretty solid, bar one game lol.
     

Share This Page