Pirate Kid Dracula reverse engineering

[Fisher]

Another option could be to write a MS-DOS program that do any tests needed, assuming the PAL IC is present in the place of the BIOS ROM.
How difficult would this be?
For me, unfortunatelly, it's almost impossible

[lidnariq]

I mean, it wouldn't be hard to build an ISA card and some software to let you try exploring what's going on.

But I doubt it would be more useful than just writing a simple NES test ROM to see what happens in a reassembled cart, replacing the existing PRG.

The VRC2 should even have a single bit of tristate-able buffer (from pin 16 to CPU D0 during reads from $6000-$6FFF) that would let us test any single output from the PAL at a time, as long as it holds state (i.e. is slow). Assuming that this pirate clone bothered to copy that part... If it doesn't work, we could still add external parts to read any latched state instead.

[zxbdragon]

PRG,CHR address is VRC2

IRQ address
FF00 ： not using?
FF04 : counter?
FF08 : enabled?
FF0C : disabled?

clock?

[lidnariq]

Per the mapper hack's code, $FF04 has to be "acknowledge IRQ, do not stop", because that's how the game implements a variable number of scanlines IRQ (It uses the byte of RAM at $07F8 to count down some number of two-scanlines)

[zxbdragon]

Per the mapper hack's code, $FF04 has to be "acknowledge IRQ, do not stop", because that's how the game implements a variable number of scanlines IRQ (It uses the byte of RAM at $07F8 to count down some number of two-scanlines)

yes，I know 0x07F8,but same pcb TNMT J. not using 0x7F8

[lidnariq]

Are we violently agreeing and just having problems due to lack of fluency in a common language?

[zxbdragon]

Are we violently agreeing and just having problems due to lack of fluency in a common language?

......

[Joe]

Code: Select all

  $C004: Acknowledge IRQ
  $C008: ?start IRQ counter?
  $C00C: Acknowledge and ?stop counter?

It looks like $C004 and $C00C both acknowledge the IRQ, and $C00C additionally resets the counter. I don't see anything that looks like it would stop the counter, but I'm not sure about preventing IRQs.

pin 16: not measured yet

According to the newer dump, this looks like (inverted) writes to $C00C, but it's inconsistent in some places.

showing a significant amount of variation is some outputs, hopefully due to violated timing constraints.

That might be fixed by using a /CE or /OE signal on pin 1, if there happens to be one available, instead of an address line.

[Fisher]

Well, I asked about the MS-DOS program because my dumper is just an old motherboard repurposed.
To be more precise, it's a M748LMR, on wich I have soldered a 20 pin socket at bios' side and use UniFlash to dump.
But I sure can socket a PRG ROM on the cartridge board and do any tests needed.
My next step is to invert the adress pins and dump the PAL IC again.
It'll just take a litle more time than I want.

Joe, I think I can do a fast redump by pulling pin 1 low or high, or even plugging it to /CE or /OE.
What would help more?

[Joe]

Well, I asked about the MS-DOS program because my dumper is just an old motherboard repurposed.

It'd be faster for you to just scramble the address lines you're using and dump it again. Lidnariq could probably tell you which combination(s) would be the most useful. It may also help if you could invert the signals on PAL pin 2 and/or pin 3.

But I sure can socket a PRG ROM on the cartridge board and do any tests needed.

I won't be writing test ROMs any time soon. Maybe lidnariq will.

Joe, I think I can do a fast redump by pulling pin 1 low or high, or even plugging it to /CE or /OE.
What would help more?

I suspect /OE will be more useful than /CE, but we won't know until you try. Pulling it low or high won't tell us anything useful.

The PAL uses pin 1 to detect when the values on pins 2 through 7 are valid. On the NES, /ROMSEL is only low when the other signals are valid. On your motherboard, A0 makes no such guarantee, but hopefully /OE or /CE will.

[lidnariq]

... right, if you're using a motherboard to dump the PALs, that explains the glitchy behavior, because the address bus probably isn't idle between fetches...

As far as useful orders: I think the most helpful minimal change would be to try all the combinations of D0, D1 before the address lines, by moving pins 2-4 to instead connect to dumper A9-A11, rather than doing a full reversing of pins.

[Fisher]

Ok, I'm really tired... Played with the kids on the park almost all afternoon.
Let's see if I understand: Ineed to solder pins 2, 3 and 4 to A9, A10 and A11. Is it correct?
I plan to do it tomorrow, probably at work. (yes, I'll procrastinate!!)

[lidnariq]

Let's see if I understand: I need to solder pins 2, 3 and 4 to A9, A10 and A11. Is it correct?

That's the easiest thing I can think of that should produce useful results.

I'm only confident that that will provide the information necessary to figure out whether $8008 and $800C do anything. Hopefully it'll demonstrate what's going on with $C008 and $C00C too, but I'm not certain about that yet.

Unrelatedly, I was looking more closely at the PAL16L8 datasheet, and noticed that pins 19 and 12 are always outputs, and can never be used as feedback terms inside. So they have to exclusively be a function of the other pins, which makes them really convenient for logic function reduction.

Apparently:
Pin 19 (counter clear) is 1 iff Pin 8 (Cnt=86) is 1 OR pin 16 is 0
Pin 12 (CIRAMA10) is: if Pin 17 ($9004q1 is 1) then Pin 18 ($9004q0) else Pin 7 (VRC2Mirroring)
And it turns out two more pins don't involve any feedback loops ... but we already knew these:
Pin 13 is 1
Pin 15 is 1 iff A2 is 0, or A14 is 0, or R/W is 1, or /ROMSEL is 1 → detects writes to $F004 and $F00C

The other four pins (pin 14 /IRQ, pin 17 $8004q0, pin 18 $8004q1, pin16) involve feedback loops, how inconvenient.

Pin 16 is definitely always 1 during writes to $C008. It is definitely always 0 during writes to $C00C .. but interestingly, it looks like it doesn't care about /ROMSEL?

If I look at the combination of pins 14, 15, 16, and 19, only eight of the sixteen possibilities ever exist, the following never occur:
Pins 19(CLR) and 16 both clear (duh, per above)
Pins 14(/IRQ) and 15 both clear (hmm)
all four pins high (hmm?)

I'll think about this some more and see if anything comes to mind re: pin 14 and 16.

[Fisher]

Ok, I made 3 dumps:

1- Pin 1 on /CE:

PALKDCE.BIN

2- Pin 1 on /OE:

PALKDOE.BIN

3- Lidnariq's request:

PALDKLID.BIN

Pin2 --> A9
Pin3 --> A10
Pin4 --> A11

The pinout is the same as I posted before, except for the pins I told I switched.
If there's anything else I can do just tell me and I'll make as fast as I can.

[lidnariq]

Ok, the dump for me that tells me that writes to $8008 and $800C are no-ops also.

The dumps for Joe where socket /CE is connected to PAL pin 1=/ROMSEL does also illuminate a few things... It really looks like D4=pin16 keeps track of which of $C008 (storing 1) and $C00C (storing 0) was most recently written to. Which ... would combine with D7=pin19 to mean that, yes, $C008 is "start counter", and $C00C is "ack IRQ and hold counter at 0"


I guess I could write a simple real mode program on your DOS machine... what program are you currently using to dump things?

... but I kinda feel like I've got a complete mental model of what's happening now, so maybe there's no need?