1CHIP SNES SuperCIC and mod help

Discussion in 'Modding and Hacking - Consoles and Electronics' started by keropi, Aug 14, 2012.

  1. Bad_Ad84

    Bad_Ad84 The Tick

    Joined:
    May 26, 2011
    Messages:
    8,605
    Likes Received:
    1,376
    Are you doing it directly at startup? as iirc, it waits a few seconds before it allows you to change anything.
     
  2. matt5cott

    matt5cott Member

    Joined:
    Dec 10, 2016
    Messages:
    10
    Likes Received:
    1
    Thanks for the reply as always, but nah, in game, it's a real head scratcher!
     
  3. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    161
    Likes Received:
    62
    I've experienced some similar behaviour. It also depends greatly on the game, mostly while games are loading stuff it isn't too likely to work.
     
  4. AndehX

    AndehX You got boost power!

    Joined:
    Apr 7, 2016
    Messages:
    356
    Likes Received:
    68
    Yeah I have noticed that on 1 of the 2 system i've modded too. I just put it down to the simple fact that its a mod, and its probably not garunteed to work perfectly every time lol
     
  5. Bad_Ad84

    Bad_Ad84 The Tick

    Joined:
    May 26, 2011
    Messages:
    8,605
    Likes Received:
    1,376
    It's down to the game how it polls the controller. The original igr mod didn't read the controller with quite a few games. Then borti improved it with the uIGR which seems to work much better.

    If you have a game that works unreliable but others work fine - best to log an issue on github. Or you can tell me, I'll try to reproduce and log issue
     
  6. borti4938

    borti4938 Robust Member

    Joined:
    May 8, 2014
    Messages:
    205
    Likes Received:
    64
    Yeah, some more infos would be great: which game, which controller (wireless controller can mess up the uIGR, too), sd2snes (in game hooks enabled?), original game, etc.!?
    However, I guess that I won't update the uIGR with the PIC16F684 as I don't see any further improvements yet. Moreover I do have a combination with a uC and a CPLD in mind...
     
  7. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    161
    Likes Received:
    62
    uIGR doesn't poll the controller itself right? Only monitors the outgoing latch and then taps the data/clock lines instead?
    Strange because if the game does auto polling it's always 100% the same for every game..
     
  8. borti4938

    borti4938 Robust Member

    Joined:
    May 8, 2014
    Messages:
    205
    Likes Received:
    64
    That's correct. At the moment the sniffing (shift and store of serial data) is completely done by software; however a SPI would do the job much better!
    Some games do not use auto joypad read (AJR). E.g. Super-Star-Wars games, Battletech/Mechwarrior 3050 (uIGR does not work at all with this game) and some more.
    As long as AJR is used the actual procedure should go well and also for most non-AJR games.
    The actual software is a trade off. First, The software solution cannot met the hardware timing of the SNES SPI for the controller (instructions consumes time). So I have to play a bit and all variant I implemented / tested have the problem that it is either too slow for wired controllers or too fast for wireless ones. It has to fit somewhere between the switching speed of cabled and wireless controllers.
    However with a hardware SPI I can met the SNES switching speed without any problems (or at least I hope so).
     
  9. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    161
    Likes Received:
    62
    How about upgrading to a PIC18 instead? Even non-SPI ones are easily capable of polling the ports, especially with an interrupt on change. In fact, they have no problem with the much faster NGC/N64 protocol either :)
     
    Last edited: Feb 13, 2017
  10. borti4938

    borti4938 Robust Member

    Joined:
    May 8, 2014
    Messages:
    205
    Likes Received:
    64
    Polling the controller is not a big deal; problem is sniffing. The implementation you referenced looks similar even to the first IGRs ones. The only advantage you have that you half the instruction cycle (using the internal clock) or go even faster. However, a faster clock does not circumvent the general problem of a software implementation to be compatible to cabled and a variety of wireless controllers!
     
  11. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    161
    Likes Received:
    62
    So when does it fail?
     
  12. matt5cott

    matt5cott Member

    Joined:
    Dec 10, 2016
    Messages:
    10
    Likes Received:
    1
    It's 2x 1CHIP-01s that have this weird quirk, one is at a mates, one I have with me here.

    At the moment I have said 1CHIP-01 and a 1CHIP-02 I'm testing with,

    All the following work fine on the 02, yet exhibit the same quirk on the 01, this is with an official wired SNES pad, I've tried plenty of other games and the same issue arises, I just tested these three now,

    Super mario kart (Japanese)
    Bomberman 5 (Japanese)
    Ultimate MK3 (PAL)
     
    Last edited: Feb 13, 2017
  13. borti4938

    borti4938 Robust Member

    Joined:
    May 8, 2014
    Messages:
    205
    Likes Received:
    64
    I will look at these games when I have time. Have you tried to exchange the uIGR pics between your SNESes? Have you used different wires for installation?
    Sometimes I feel like the performance also depends on the PIC itself.

    Have you ever seen how a non-AJR game reads pulls the controller? If not, here is a picture:

    [​IMG](Source, yellow is latch and blue curve is data clock)

    Other than for the AJR, for the non-AJR the data-clock does not have a 50/50 duty cycle and also the period is usually less than 12us.
    I would like to sample on the neg. edge like in your code but this could be too late for non-AJR in combination with cabled controllers as data is shifted at the pos. edge which comes immediately.
    Btw.: At which clock does your code run? I counted 17 instruction cycles from begin of ISR to reach the SNES part and 18+ instr. cycles for a sampling circle.
    (At 8MHz for example one instr. cycle takes 0.5us (four clock periods))

    So the uIGR samples after a pos. edge. But this cannot be done immediately with wireless controllers. Wireless controllers I do have to wait a bit as the microcontroller inside the receiver also needs time to shift data, which is around 1us for current 8bit.do receiver or for older retrobit receivers it is around 2.5us.
    Despite of this wait I do have just 8 instr. cycles (11 for the alternative timing for retrobit receivers).
    BTW: I always treated B as a special case. From ris. edge to the ISR, sampling B and wait for Y I do have 8 instr. cycles, too.

    So when does it fail:
    First, if the first data clock comes after the rising edge of the latch too early like in Mechwarrier. (allows me 4 instr. cycles max to reach wait for Y state) or Return of the Jedi (7 instr. cycles).
    Second, if the clocks are too close together.

    My idea is to use the SPI for exact sampling at the neg. edge of the data clock like the SNES does. With an hardware interface you have virtually no 'processing' time. I want to have SPI should in a CPLD as it should also include the region patching part as well as a glitch free clock switch for 1chip consoles (has anybody noticed that the current implementation with the NAND gate is not glitch free?)...
     
    Last edited: Feb 14, 2017
    zzattack likes this.
  14. borti4938

    borti4938 Robust Member

    Joined:
    May 8, 2014
    Messages:
    205
    Likes Received:
    64
    Ok, at least you pushed me into testing another strategy of sampling (once again). New implementation has four instr. cycles from ISR begin to sampling B and just 7 instr. cycles for sample & store in general. I will test that during next couple of days.
     
  15. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    161
    Likes Received:
    62
    It's for a USB device so FOSC/4 is 12MHz. I don't recall the exact details, but timing for N64 is a lot more tight (4uS per bit, iirc), so much fewer instructions to sample than for SNES. I will tell you how I captured those, maybe it can be valuable for SNES too.
    So, every bit takes 4µs and starts at falling edge, a '0' remains low for 3µs and goes high for the last 1µs, and a '1' remains low for only 1µs and then goes high for the remaining 3µs. Turns out 3rd party controllers take some liberty with this, so I implemented it as 'if period spent low is longer than period spent high, it's a '0', else it is a '1'. Implemented using a timer that runs with the instruction clock, so no cycles wasted on incrementing manually. Also
    - at falling edge, reset timer
    - at rising edge, store timer to w
    - at next falling edge, subtract w from timer (2's complement), store w using postinc
    In post-processing we can simply check the stored number.

    Now I understand that clock and data are separate for SNES, but maybe we can come up with a strategy that works. Although I can definitely see that it'll be very annoying to obtain a 100% reliable software capture method due to these different timings.
     
    Last edited: Feb 14, 2017
  16. borti4938

    borti4938 Robust Member

    Joined:
    May 8, 2014
    Messages:
    205
    Likes Received:
    64
    Yeah, 6-times faster than the 16F684s internal oscillator ;)
    Edit: If I think of replacing the actual PIC to increase operating speed, I would prefer using a uC which is pin compatible, e.g. like the 16F1503. This PIC is twice as fast as the 16F684. Every other solution (e.g. clocking the uC with an external oscillator) would also mean a redesign of current hardware design. I that case I would prefer a more dramatic change to reduce number of ICs used too ;)

    I know that N64 is more 'complicated'. The challenge with the SNES are the variety of controllers and being compatible to most non-AJR though. That's why I left out any shifting and counting operation during the ISR. I just have 16-times the same instruction after one other and store bits into appropriate registers and bit positions. A simple check on the latch checks validity, though, in case the algorithm has missed a clock pulse in between.

    My new implementation tries to sample as close as possible before the neg. edge is detected with just a very few instructions. I will see how efficient that will be. I had something similar but not that efficient last year in August but rejected it as it felt not as compatible as the current implementation.
     
    Last edited: Feb 14, 2017
    zzattack likes this.
  17. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    161
    Likes Received:
    62
    The region patch is already optimized w.r.t. 74xx ic's needed, and doesn't supercic need to run at the same 3.17something MHz clock? If so, I don't think too much optimization will be possible :(
     
  18. borti4938

    borti4938 Robust Member

    Joined:
    May 8, 2014
    Messages:
    205
    Likes Received:
    64
    I just quickly tested these games on a 1Chip-01, 1Chip-02 and a SNSP-CPU-02 SNES. Everything works like a charm.
    - Have you the possibility to refresh the uIGR PIC or to exchange it?
    - Have you tested to solder the modding board from the 02 into the 01 system to see if this changes anything?

    If you want to have the SuperCIC and the uIGR in one Microcontroller you are stuck at the 3.x MHz. That's right - but you also have to be careful with the number of instructions during the uIGR parts as you have to be synchronised with the CIC-key...
    However, I see that this could be possible; this would need to extract the SPI into a CPLD (which can then also replaces the 74xx ICs for region patching and clock switch) and let the microcontroller get actual data out of the CPLD on demand on the micro controllers speed when he has enough time...
     
    zzattack likes this.
  19. matt5cott

    matt5cott Member

    Joined:
    Dec 10, 2016
    Messages:
    10
    Likes Received:
    1
    Good news, switched the board for a different one and it now works fine, I've yet to put the "bad" board in another SNES, I'll do it when I have another to mod at the w/e.
     
  20. Bad_Ad84

    Bad_Ad84 The Tick

    Joined:
    May 26, 2011
    Messages:
    8,605
    Likes Received:
    1,376
    Sounds like this then. Maybe variation on the internal oscillator?
     

Share This Page