nesdev.com

Hi.
This is the thread I promissed on the Kid Dracula (Akumajō Special: Boku Dracula-kun) reverse engineering.
I'm posting the assembled card pictures first:



I noticed some routing errors, there's possibly more:
1- Pins 6 and 7 of the 23c269 are swapped.
2- The CIC stun cicrcuit seems misrouted.
3- Pin 22 of the PRG? ROM is misrouted.

Next I'll post the naked board scans.
Get ready for some PCB porn!!

As promised, some PCB porn:



Next I plan to dump the PRG and CHR ROMs plus the PAL chip.
Can someone please tell me wich pins are inputs and wich are outputs on the PAL?
I'm with 9 guests at home (5 are kids) that will stay this whole week and part of the other, so it's better to do these dumps in a single shot!!

... This IRQ counts falling edges of PPU A13. Specifically, it counts 86 of them, or two scanlines.

Of the six pins that could be inputs or outputs, they are either all outputs or connected to nothing. They are probably all outputs.

Tracing completed.

This board is basically identical to the one zxbdragon took pictures of in the other thread, modified to work in a NES instead of a Famicom (and use mask ROMs instead of EPROMs).

Pins 6 and 7 of the VRC2 clone are swapped because this board misroutes them. The NES swaps PPU A10 and A11 relative to the Famicom, and whoever modified this board for NES missed that key difference.

Pin 22 of a 28-pin mask ROM is A16, but the equivalent pin on EPROMs is /OE. You can see where both PRG and CHR had the trace connecting that pin to GND hastily cut, but only the CHR was correctly rerouted. The PRG was connected back to GND! The hack job connects it to the correct location.

PAL pinout appears to be

But why not just use resistors as I suggested in the other thread?

thaks!Hope to be able to solve the MAPPER

I rev-ed your PCB, thanks for providing a lots of fun!

Well Lidnariq, I really want to do that circuit, but my house is a little overpopulated...
Let me explain:
My sister is visiting me with her husband, she has 3 kids, plus, my niece is here with her husband too, and she has 2 other kids.
This makes me a Uncle Grandpa!!
I really fear that some kid come near me while I'm working and get hurt by any of the tools I have on my workdesk.
So it was kind of "Metal Gear" stealth action to hide myself and try to do at least part of the job.
Hope Everything was done correctly. You know: "haste makes waste"!
They really liked me and I have past most of my free time playing with them and my own kids.

Great job Krzysiobal!!
I just need to study and understand better these inner workings!!
I still consider myself a newbie in these stuff. Hope to change this soon!

By the way, here is the PAL data I managed to dump:

The pinout I used:

It's the same circuit I used to get that Gradius 2's PAL data, I only changed pin 14 to D6.
Hope this helps clarify even more how the IRQ circuit works.

If someone is interested, here is the ROMs dump, I just don't know who is who.
Edit: Discovered who is who by comparing the CRC32 with Bootgod's site.

PRG ROM:
Edit: Removed to avoid future problems, as suggested.
For reference:
NCN-18A.BIN CRC32 6a50b553
If someone needs it here's an IPS patch:

Apply it to the original PRG ROM, CRC32 93794634

CHR ROM:
Edit: Removed to avoid future problems, as suggested.
For reference:
NCN-18B.BIN CRC32 c5d1196e
The same CRC32 as the original.

If there's some problem posting this kind of stuff here, please, remove it.
Edit: Removed possibly copyrighted material, as suggested.

Edit2: Fixed the NCN-18A.BIN, it was the same NCN-18B.BIN. Sorry...
Edit3: The CHR-ROM (NCN-18B.BIN) has the same CRC as the original.

Probably should delete the PRG and CHR dumps; unfortunately.

This exact dump is already in GoodNES 3.14 as "[p1][t1]"

(Interestingly, the PRG is also multiply present in multiple dumps, marked as "[b2]", "[p1][t1][b1]", and "[p1][t1]", and the CHR is "[!]", "[p1][t1]", "[t1]", and "[t2]")

Anyway, the PAL:
Pin 13 / D1 - does nothing at all, is always high.
Pin 15 / D2 - is low when writing to ((address & 0xC00C) == 0xC004) (edit, braino)
all other pins (12,17,18,19,14 = D0,3,4,5,6) are complicated, using feedback paths inside the PAL

So ... the PAL probably latches D0, D1 sometimes, and may count some number of overflows from the interrupt handler also. (Uh-oh)

Also, if you could re-dump with PAL pin 16 as an output that'd be nice.

goodnes Sorting is imperfect.
[b] rom Many are GOOD DUMP,but is pirate.

After the game Kid Dracula IRQ emu.next MMC5 Clone PCb?

So, we know that the underlying VRC2 is VRC2b shaped. So all of the mapper accesses for CHR banking have to have been adjusted from the original game's VRC4e layout (0,4,8,C → 0,1,2,3).

There are up to eight possible registers in the PAL. The mask is $C00C.
The ones at $8000 and $C000 are explicitly no-ops to minimize how intrusive the patch had to be.
The one at $9004 (i.e. $8004) is the new augmented mirroring control register (since register mirroring will fall through to the VRC2 underneath). Two of the unknown five outputs on the PAL must latch D0 and D1 to keep track of when the PAL is supposed to override the mirroring.

There's one at $F004 (i.e. $C004); it doesn't pay attention to the data bus (the IRQ handler writes the contents of A as the very first thing). By context, this must restart the IRQ timer, keeping track of the number of times before it passes to the original IRQ handler.

The patch also writes to $9008, $F008, and $F00C; it's less immediately obvious what these are doing. After the nametable controls, and the idle bit, there are only two possibly volatile bits remaining. One is probably whether the IRQ is enabled... another may be whether the IRQ is currently asserted.

PAL pin 14 (dump D6) is 1 (IRQ not asserted) IF: /ROMSEL is 0 and CPUA2 is 1 and CPUA14 is 1 and R/W is 0. (i.e. $C004, $C00C)
— it's always 0 (IRQ asserted) IF: (pin 9) CNT=86, unless the immediate above line. More complicated behavior is hard to diagnose.

PAL pin 12 (dump D0) should, sometimes, be one of: pin 8 (A7) , logic 1, logic 0, depending. Additionally, it should be correlated with some other bits.
— Due to the in-order way the PAL-as-ROM was dumped, we can only tell that it does care about $8004 and does not care about writes to $8000, but write to $8008 or $800C cannot be determined.

PAL pin 17 and 18 (dump D3 and D4) appear to be the latched copy of CPUD1 and CPUD0 respectively in response to writes to the mirroring control register.

PAL pin 19 (dump D5) is asserted (i.e. reset counters) if: CNT=86.
—Otherwise, writes to $C008 seem to deassert it, and writes to $C00C seem to assert it


I'm not entirely certain what the next useful test would be. Maybe shuffling some address lines so that the dumper tickles things in a different order. Or maybe writing a test that could be put on some 'PROM to tickle the six different registers. And it would be really nice to massage the /ROMSEL input so that the PAL's latches-made-of-feedback-paths weren't glitchy...

Wait for Joe master

He may well think of something... but here's what I'm confident of:



Separately:
pin 12: (per pinout) Nametable override
pin 13: Nothing
pin 14: (per pinout) /IRQ
pin 15: IRQ ack
pin 16: not measured yet
pin 17: nametable override
pin 18: nametable 1screen override setting
pin 19: (per pinout) 74'393 +CLEAR

If one looks directly at the dump, each byte can be though of as a sequence of accesses to memory:
write "00" to $8000, idle, write to $8004, idle, write to $8008, idle … $800C $C000 $C004 $C008 $C00C, then the same for writing "01", "10", and "11"; then 64 cycles corresponding to reads from those same locations. Then 128 cycles while the nametable mirroring input is high instead of low.
Then 256 cycles while the 74'393 and 74'21 are indicating terminal count.

This pattern is repeated 256 times throughout the dump, showing a significant amount of variation is some outputs, hopefully due to violated timing constraints.

New PAL dump:

Pinout used:


I'm planning to do another dump later, using interleaved address lines (A0, A2, A4, A6, A8, A10, A12 and A14).
Would this be usefull?

Hm. I don't think skipping address lines would be helpful. I tentatively think reversing them should?

That would change the virtual bus behavior to instead look like
Write '00' to $8000 while not terminal count and input nametable=0
Write '00' to $8000 while terminal count and input nametable=0
repeat above, but input nametable=1
repeat above, but reading from $8000 instead
repeat above, but data bus now holds '10', then '01', then '11'
repeat above, but to $C000, then $8008, then $C008, then $8004, then $C004, then $800C, then $C00C
finally 65536 samples while /ROMSEL is high, which if my mental model is right, ought to ignore every pin other than pin 9/A8/"terminal count"

Because the 16L8 has six feedback loops, instead of registers, that means it has to be storing values in a multiplexer-like behavior, rather than caring about edges. So hopefully keeping things like this will help...