Titanic 1912 dump madness

I have an Nt Mini with the CopyNES firmware, a stack of bootlegs, and a dream. A pointless dream to make copies of bootlegs that have already been dumped anyway. Also, it's unclear whether Titanic 1912 has ever been dumped cleanly (all existing ROMs appear to be mapper hacks), so this particular one might be worthwhile. I've already written a few CopyNES plugins for unusual mappers (163, 178, 240) which have worked beautifully (although I'm a lazy shit so they're all overdumpers that require removing extraneous banks from the resulting ROM file), so I'm reasonably confident in my ability to write a plugin.

I'm informed that Titanic 1912 uses mapper 227, and a simple NROM dump seems to support this claim, as it always writes x to $8083+x, which fits with mapper 227's odd the-address-you-write-to-is-what-matters behavior. So, I threw together a trivial CopyNES plugin to dump by writing x to $8083+x for all x in $0 to $80, stepping by $4 (as makes sense for the mapper). This is where the... fun?... begins.

Running that trivial plugin caused it to read $a00 pages, then freeze and get a read timeout. OK... that was weird. How would it get a read timeout? Why would it stop? OK, maybe the cart is invoking an interrupt?

So, I tried disabling interrupts. No effect. This was a ridiculous attempt, since surely the CopyNES doesn't just let the cart interrupt it, but what the Hell do I know.

OK, well, if I can't dump more than $a00 pages, at least I can dump $a00 pages, right? Wrong. I modified the plugin to dump that, and then it started dumping garbage after the $a00, i.e., sending more "data" to the CopyNES than I'd actually programmed it to. It's of course well within the realm of possibility that I made a stupid mathematical mistake, but I did a lot of head-scratching and I'm pretty sure that's not the case.

In desperation, I switched it to dump $800 pages. Now? Now it only dumps $100 and then times out again. What???

OK, next step, throw this all away, do an NROM dump, run it in a debugger, and just reproduce its writes one-by-one, doing an NROM dump each time something interesting happens and adjusting.

Now the game runs. I write $10 to $8093 and the game runs. In CopyNES. ?!?!?!?!?!?!

Is this some mightily conflicted bus conflict or something? Is the cart asserting over RAM? CopyNES plugins are stored in RAM, so anything could happen if it's that insane.

Ironically, I got a CopyNES because I was frustrated with the Kazzo having such poor support, and if this is actually some incredible bus conflict magic, it's exactly the situation that a Kazzo would be better for. I managed to brick mine though...

Is there any chance that your hardware looks different from this previous m227 hardware ?

There are some mappers that crash if the wrong location is read, but I don't think that should be relevant here.

It's remotely conceivable that the Analog NT can't handle repeated bus conflicts (happening on every write on the data bus), and I guess maybe that could cause it to get warm and stop working - i.e. time out?

Usually I don't like opening these carts, because they're poorly manufactured and tend to become irreparably broken. I decided it was worthwhile for this one, and as it turns out, it was pre-broken, and some chucklehead had busted off the tabs and shoddily glued the thing back together. 10/10

To an idiot's eyes (read: mine), it looks very different. It is a far busier board than what you usually see in these things, even in multicarts (which this isn't).

https://i.imgur.com/81hQiUV.jpg
https://i.imgur.com/xutjaaz.jpg

It is a truth universally acknowledged that one can only find glaring bugs in software after posting about it publicly somewhere. 80 and $80 are not the same, Yahweasel. Oy vey.

(This observation only applies to the first versions of my plugin. I still have no idea what's up with the just-copy-Titanic's-behavior one that actually starts the game)

My original-style dumper now dumps something... that doesn't work. At least I have something I can sink my teeth into tho!

So, looking at the PCB, I see:

[Hitachi] HD74LS10P (decode PRG RAM?)
[HYUNDAI] HY62256ALP-10 (PRG RAM)
[TI] SN74LS153N
unknown 0.3" 20-pin IC (74'273?)
battery holder
Chip-on-board Mask (PRG?) ROM
[TI] SN74LS32N
unknown 0.6" 28-pin memory (almost certainly CHR RAM)

The 74'153 is probably there for nametable mirroring control - pins 3 and 4 are shorted, and pins 5 and 6 are shorted, so pin 2 should be connected to some state. Other unlicensed carts we've seen use the other half to select between 16KB and 32KB NROM games.

74'273? pin 1 seems to connect to a diode+capacitor /RESET detection circuit.
Pin 4 connects to PRG RAM pin 4 (A6).
Pins 5 and 6 seem to connect to PRG ROM pins 30 (A17?) and 31 (A18?).

The lower-left corner of the 74'32 seems to be ORing R/W and /ROMSEL - probably generating the clock for the 74'273(?).

While this still could be mapper 227, I suspect it to be something else... especially if that 62256 actually provides access to more than 8 KB of RAM.

My personal dumping technique would start off with generating a schematic and figuring out the hardware from there. Krzysiobal has managed to make amazingly accurate guesses from just pictures, though.

NewRisingSun helped me on Discord and was able to resolve the weirdnesses. This mapper is extremely picky. But, it is 227, or it certainly tastes like it.

What ended up being the issue?

It would be difficult to nail down the issue... what I have is a working dumper, but no very good explanation for why the earlier ones didn't work . One definite problem is that I was iterating one-by-one through the PRG banks, but using 32KiB bank switching, and if you combine those modes, it locks up and stops bank-switching entirely. As per why the result of locking up was so crazy, or why my direct attempts at replicating the game were causing incomprehensible behavior, for that I have no answer.

The working solution is to make sure the cart is in a cooperative mode to start (i.e., start fresh; even dumping right after dumping won't work), and just to go two banks at a time.

When setting the PRG A14 bit while in 32 KiB PRG banking mode, the mapper will not accept any further bankswitch writes.

Also, I am having a feeling that the non-multicart variant of mapper 227, and mapper 242 are actually the same mapper.

My doubts/quirks:
* The register is present only at $8000-$9fff,
* There are bus conflicts
* there might be one or two bits controlling WRAM (vias for both PRG-A15 and PRG-A14 suspiciously are present under RAM chip)
* /CS of WRAM is pulled-up to VCC, not the battery backed up voltage (does savestate corruption occur?)
* instead of M2, /RESET is taken into decoding of WRAM /CS (might be more corruption-proof?)
* setting the p bit permanently locks any further writes (no matter if it is in 32K or 16K mode), so the only way of dumping it is to use 32K banks and keep this bit always at 0.
* are both VCC pins (30, 31) shorted?
* rightmost resistor (R2=4.7k) pulls up something to VCC but I dont have idea what (is it placed between GND and VCC?)