I am in process of fixing blob-Rinco famiclone. Console works fine but... there is problem with joypad 1, which causes (even if no pad is present) every game to think that all buttons are pressed at once.
1. Unfortunatelly, strobe & clock lines are dead. And shorting joypad-data to vcc/gnd does not stop games to detect all buttons being pressed.
2. I tried the old trick with putting 0/1 on the data bus when there is read cycle from $4016 but it also does not change anything. So probably this clone has the internal joypad port separated from cpu-bus.
Normally I would throw it into garbage but it has the unique PAL/NTSC region switch feature, so..
I tried my recent trick with code injection: http://forums.nesdev.com/viewtopic.php? ... 15#p224858
but this time, after read cycle from $4016 happens, I am injecting code that loads into accumulator value from joypad-data line (+ and I also generate clock/strobe signals). This value is read by FPGA from 'new' joypad port.
I checked a few games and all of them reads $4016 into accumulator and not inyo any other register. And all this code is executed from ROM, not RAM, so it should work. And it works! I managed to make joypad port working. I tested on some NROM/MMC1/UNROM games and all of them works.
However, when it comes to MMC3 (for example Doki Doki Yuuenchi, SMB3) - they hang just after second after start.
So I thought:
1. Does adding those cycles really make difference to the timing in code? -> No, I modified the ROM in emulator and changed the lda $4016 into jump to some free region + few nops + jump back -> game worked
2. Maybe during the opcode injection, when cartridge ROM is disabled, IRQ is triggered (because MMC3 is the only mapper from the above that uses - it). But looking on the scope, at the moment when something starts messing, there is no IRQ pending.
(I checked this even on second, working console, and it is exactly the same). I checked on true hardware MMC3 cartridge and flash cartridge and also.
Doki Doki read joypad routine looks like:
But looking at the waveforms, there are tens of correct 8 reads from $4016, but suddenly there appears a moment that during some of that injected code (here - during fifth read from $4016), CPU address bus is the same for three cycleS! Even if CPU would read invalid data and treat it as opcode, it wouldn't stay for 3 cycles! Anyone has idea what am I missing? Maybe some weird DMA/APU thing is taking place at this moment?
1. Unfortunatelly, strobe & clock lines are dead. And shorting joypad-data to vcc/gnd does not stop games to detect all buttons being pressed.
2. I tried the old trick with putting 0/1 on the data bus when there is read cycle from $4016 but it also does not change anything. So probably this clone has the internal joypad port separated from cpu-bus.
Normally I would throw it into garbage but it has the unique PAL/NTSC region switch feature, so..
I tried my recent trick with code injection: http://forums.nesdev.com/viewtopic.php? ... 15#p224858
but this time, after read cycle from $4016 happens, I am injecting code that loads into accumulator value from joypad-data line (+ and I also generate clock/strobe signals). This value is read by FPGA from 'new' joypad port.
Code:
RnW ADDRESS DATA STATE ;fix broken joypad
--------------------------------
1 xxxx * IDLE
1 $4016 * IDLE
1 xxxx + 1 $A9 LDA1_1 ;simulate LDA #V, where V=%0100000d
1 xxxx + 2 V LDA1_2 ;(d-current value of joypad data line, 1 to mimic open bus behaviour for some games)
1 xxxx + 3 $4C JMP_1 ;jmp xxxx+1
1 xxxx + 4 LO(xxxx+1) JMP_2
1 xxxx + 5 HI(xxxx+1) JMP_3
1 xxxx + 1 * IDLE
--------------------------------
1 xxxx * IDLE
1 $4016 * IDLE
1 xxxx + 1 $A9 LDA1_1 ;simulate LDA #V, where V=%0100000d
1 xxxx + 2 V LDA1_2 ;(d-current value of joypad data line, 1 to mimic open bus behaviour for some games)
1 xxxx + 3 $4C JMP_1 ;jmp xxxx+1
1 xxxx + 4 LO(xxxx+1) JMP_2
1 xxxx + 5 HI(xxxx+1) JMP_3
1 xxxx + 1 * IDLE
I checked a few games and all of them reads $4016 into accumulator and not inyo any other register. And all this code is executed from ROM, not RAM, so it should work. And it works! I managed to make joypad port working. I tested on some NROM/MMC1/UNROM games and all of them works.
However, when it comes to MMC3 (for example Doki Doki Yuuenchi, SMB3) - they hang just after second after start.
So I thought:
1. Does adding those cycles really make difference to the timing in code? -> No, I modified the ROM in emulator and changed the lda $4016 into jump to some free region + few nops + jump back -> game worked
2. Maybe during the opcode injection, when cartridge ROM is disabled, IRQ is triggered (because MMC3 is the only mapper from the above that uses - it). But looking on the scope, at the moment when something starts messing, there is no IRQ pending.
(I checked this even on second, working console, and it is exactly the same). I checked on true hardware MMC3 cartridge and flash cartridge and also.
Doki Doki read joypad routine looks like:
But looking at the waveforms, there are tens of correct 8 reads from $4016, but suddenly there appears a moment that during some of that injected code (here - during fifth read from $4016), CPU address bus is the same for three cycleS! Even if CPU would read invalid data and treat it as opcode, it wouldn't stay for 3 cycles! Anyone has idea what am I missing? Maybe some weird DMA/APU thing is taking place at this moment?