I Dumped a VRC Super Contra.
IRQ is HCF4020BE
read HCF4020BE as:
* HCF = manufactured by ST microelectronics
* 4020 = 14 bit ripple-carry counter
* B = buffered inputs
* E = DIP
CD4020
* CD = genericized, but originally meant manufactured by RCA
* 4020 = 14 bit ripple-carry counter
lidnariq wrote:
read HCF4020BE as:
* HCF = manufactured by ST microelectronics
* 4020 = 14 bit ripple-carry counter
* B = buffered inputs
* E = DIP
CD4020
* CD = genericized, but originally meant manufactured by RCA
* 4020 = 14 bit ripple-carry counter
this pirate cart,using
http://wiki.nesdev.com/w/index.php/INES_Mapper_040 irq,not working!
zxbdragon wrote:
If you tell me what the pins of the small ICs are connected to, I can tell you what's supposed to happen.
As is, I can only guess; I'd guess that the 74'138 is decoding some pair of addresses, but I have no idea which ones. With only six inputs, of which only three can be high if we're decoding multiple addresses, it's hard to guess what addresses it'd be decoding. Furthermore, I'd guess that two of the gates in the 74'00 are making an /S-/R latch enabling or disabling the counter and a third inverts the output of the 4020 into /IRQ.
Specifically Mapper 40's IRQ is unlikely, that'd collide with various functions inside the VRC4 clone. The registers "ought" to be somewhere at $Fxxx or between $4020 and $7fff.
lidnariq wrote:
zxbdragon wrote:
If you tell me what the pins of the small ICs are connected to, I can tell you what's supposed to happen.
As is, I can only guess; I'd guess that the 74'138 is decoding some pair of addresses, but I have no idea which ones. With only six inputs, of which only three can be high if we're decoding multiple addresses, it's hard to guess what addresses it'd be decoding. Furthermore, I'd guess that two of the gates in the 74'00 are making an /S-/R latch enabling or disabling the counter and a third inverts the output of the 4020 into /IRQ.
Specifically Mapper 40's IRQ is unlikely, that'd collide with various functions inside the VRC4 clone. The registers "ought" to be somewhere at $Fxxx or between $4020 and $7fff.
F008,F00C,Disable or Enable IRQ
I F008,Enable IRQ.,count=0;
F00C Disable.
if (IRQa) {
if (IRQCount<238)
IRQCount += a;
//IRQCount = 0;
else{
IRQa = 0;
X6502_IRQBegin(FCEU_IQEXT);
}
}
but failure。
In order to help, I need to know how the ICs are connected.
Or, to be able to run the program in a debugger.
The first is preferable: it lets me say with 100% confidence exactly how something works. (The latter is merely deduction)
lidnariq wrote:
In order to help, I need to know how the ICs are connected.
Or, to be able to run the program in a debugger.
The first is preferable: it lets me say with 100% confidence exactly how something works. (The latter is merely deduction)
For the time being, no success(暂时,没有成功)
(repeating this publicly)
I sat down and traced the images... they appear to have swapped a few pins on the ROMs relative to the standard JEDEC 23'1024 pinout. There really isn't quite enough information in just the images, but my best guess:
The 4020 is counting falling edges of PPU A12. After 32 falling edges, or 4 scanlines, it'll trigger an IRQ. Unless they've set up the background and sprite tables backwards, in which case it'll happen after slightly less than one scanline. If ignored, the IRQ will de-assert after another 32 falling edges. (repeat ad nauseam)
There appears to be no on-cartridge way to disable the IRQ; the software has to be using CLI and STI.
It looks like the IRQ is acknowledge on writes to $F008. Writes to $F00C look like they might be ignored. [*]
[*] The 74'138 pin /Y6 appears to be the only one used, and it goes to the 74'00 where it is inverted and sent towards the 4020. That only makes sense if it's connected to 4020.+CLR. The three enables to the 74'138 are R/W (low); /ROMSEL (low); and NOT(NAND2(A13,A14))=AND2(A13,A14) (high), so one of A,B,C must be A12 (high). I can't see what the 74'138 A,B,C are connected to, but we know that whatever C is connected to must be low to trigger /Y6 (instead of /Y7).
lidnariq wrote:
(repeating this publicly)
I sat down and traced the images... they appear to have swapped a few pins on the ROMs relative to the standard JEDEC 23'1024 pinout. There really isn't quite enough information in just the images, but my best guess:
The 4020 is counting falling edges of PPU A12. After 32 falling edges, or 4 scanlines, it'll trigger an IRQ. Unless they've set up the background and sprite tables backwards, in which case it'll happen after slightly less than one scanline. If ignored, the IRQ will de-assert after another 32 falling edges. (repeat ad nauseam)
There appears to be no on-cartridge way to disable the IRQ; the software has to be using CLI and STI.
It looks like the IRQ is acknowledge on writes to $F008. Writes to $F00C look like they might be ignored. [*]
[*] The 74'138 pin /Y6 appears to be the only one used, and it goes to the 74'00 where it is inverted and sent towards the 4020. That only makes sense if it's connected to 4020.+CLR. The three enables to the 74'138 are R/W (low); /ROMSEL (low); and NOT(NAND2(A13,A14))=AND2(A13,A14) (high), so one of A,B,C must be A12 (high). I can't see what the 74'138 A,B,C are connected to, but we know that whatever C is connected to must be low to trigger /Y6 (instead of /Y7).
A12 IRQ?not M2?
Definitely not M2. They made a mistake in routing the PPU A12 signal, and it shorts out the jumper that was supposed to have let them decide between PPU A12 and M2:
Attachment:
annotated-irq-ax40g+4020+74138+7400.png [ 61.12 KiB | Viewed 5778 times ]
(Please forgive the lack of pixels.)
You could try borrowing FCEUX's
IRQ implementation for mapper 90.
However, since FCEUX is scanline-based, not pixel- or cycle- based, I'm not certain it would work.
lidnariq wrote:
Definitely not M2. They made a mistake in routing the PPU A12 signal, and it shorts out the jumper that was supposed to have let them decide between PPU A12 and M2:
Attachment:
annotated-irq-ax40g+4020+74138+7400.png
(Please forgive the lack of pixels.)
You could try borrowing FCEUX's
IRQ implementation for mapper 90.
However, since FCEUX is scanline-based, not pixel- or cycle- based, I'm not certain it would work.
I guessed,in fceux.beat final boss,to the first stage's score display is screen blurred
(我在FCEUX猜了一下,但在最终BOSS死后,转到第一关的分数画面显示花屏。)