Thanks for the photos. Someone else (i.e. not me) will need to review them to see if there's anything obvious wiring-wise that looks odd or wonky.
I also won't be able to tell you if that wiring diagram is correct or not; someone more familiar with hardware could.
The thread you linked me is just filled with people not really providing "linear, easy-to-follow" details -- the people trying to do the repros there spew verbal diarrhoea with little details, due to not being technical This is incredibly common with reproduction-related threads/things, sadly. Not your fault of course, but threads like that are usually impossible to glean useful information from.
My below words are going to jump around a bit, and for that I apologise, all of this is intertwined. Apologies for it not being clear (esp. right after judging other people in threads).
I think the complication here lies in regards to the ROM expansion that's going on, but I don't know for sure. I'd have to actually sit down with a debugger and see what this romhack is doing, bank and code-wise. What I do know for certain: the original Zelda 3 is is 8mbit (1MByte) mode 20 slowrom, and the romhackers of this particular game expanded it to 12mbit (1.5MByte) mode 20 slowrom. What's confusing about this is: there is no real 12mbit "model" or "method" on any of the SNES production PCBs. I'll get back to this in a moment when talking about PCBs. They really should have extended it to 16mbit and then all of this would've just worked.
The best you can do is go with 16mbit (2MByte) and make sure your addressing lines are wired a specific way to deal with the 4mbit (512KB) difference by mirroring those contents to specific banks (I think through A20 on the SNES), *or*, do some very bizarre hackery with the ROM itself -- which I believe is what Lunar Expander might be trying to do I should add I quite literally have never understood how that tool/program can work, given that addresses are hard-coded into the game at assemble-time of where things should be, and if they're not, things break -- often weirdly, sometimes in the exact fashion you describe. Other times you might just get nothing (i.e. a crash).
Another option might just be to copy the upper/last 512KB and append that to the file itself (thus the last, and second-to-last, 512KByte regions would be the same) and hope for the best. Maybe that's what Lunar Expander does in this case, I don't know.
That thread you link, though,
in this post mentions something called "swap bin", which I believe
is referring to some feature of this tool but I have no idea what it's doing. It also mentions addressing line A19 on the 27C160, which pertains to exactly what I just described above, re: "mirroring".
...oh, wait a minute, the person in that thread who said that was talking about the previous fellows' 27C801. Oh look,
in a completely different thread here someone describes something similar.
While looking for a 27C160 pinout,
I found this useful piece of information that says that the 27C160 won't work at all, with some forum reference? I didn't care to look into it.
Okay, here are the respective pinouts for the 27C160 vs. 27C801:
* 27C160 =
https://www.dataman.com/media/MROM27C160.png* 27C801 =
http://www.jaskagaming.com/wp-content/u ... rison1.png (also has SNES mask ROM pinout)
Yeah, these two are completely different. The 27C801 looks a lot easier to deal with, IMO. Although it's a 8mbit (1MByte) chip, so it wouldn't fit a 12mbit ROM. I guess that's why people are trying to use the 27C160. :-)
ALSO in that thread, flagoss mentioned that there seemed to be a bug/problem with the romhack and he had to patch it. Later on, blurayno mentions some OTHER kind of patch, but because he provides no context I don't know if he's talking about the German spin-off or what. Like I said about this stuff: nobody ever communicates coherently so it's impossible to know what the heck is going on 6 years later.
***ALSO*** in that thread, later on, there's
some other patch mentioned, blah blah blah.
Supposedly the process that worked
is here but again, subsequent posts after that claim to have problems (though they claim it was due to a through-hole wiring problem/mistake and had to use a different donor PCB as a result -- sounds like they tore/damaged the through-hole wiring when desoldering/removing the existing mask ROM, which is quite common). But the users don't specify what they had done up to that point WRT the ROM, etc... Starting to see why I asked for details of what exact version of the romhack you're using, etc.? It all matters. For all we know right now your wiring could be fine and this is some quirk/bug in the actual romhack itself, depending on what "version" or "patch" you're using. There are so many variables here that it's ridiculous. I see from your screenshot that the filename ends in
v1-3 but I dunno what that means exactly.
About PCBs: yes, SHVC-1A3B-13 is helpful. That's a production PCB (meaning it uses mask ROMs, as you already know) works with mode 20, is wired to support up to 16mbit ROMs, and has 64KB SRAM that's battery-backed. It should be OK to use (the SHVC-1A3B-12 should work too, or ). The source of this information I'm using
is here; if you look through the PCB list you'll see there's quite a lot of variance due to what models/PCBs were available at Nintendo at the time of release in a particular country or time. That board you have from
Super Baseball Simulator 1.000 should work perfectly though.
Wouldn't it just be easier to buy a repro board, specifically
this mrTentacle board that supports 27C322 and *also* 27C160 (read the description), to make all of this easier? They look affordable, including the additional chips/parts needed which
he also sells as a parts kit.