Question about translated Portopia repro

Hi, I'm new and I had a few questions (go figure) and I was wondering if anyone with more experience could help me with my project. I'm just doing this for myself for fun, and I'm hoping to learn in the process.

So I've already done a gimmick reproduction on which the yamaha chip is a bit loud...I think I need a resistor on it to fix it but I am not sure where to put it. Other than that, it works fine, but any advice on that would be amazing. Regardless, that repro was much better documented and yeah it took some doing, but I more or less could easily figure it out. I decided I wanted to play The Portopia Serial Murder Case translated on real hardware since the game is very text heavy. Originally, I expected it to be fairly easy, since the game uses NROM, which is about as basic as it gets. The problem with this is that the translation uses the much more complex mapper 68 (and for what other than expanded storage, I'm not entirely sure).

My PRG and CHR chips are regular W27C020-70 EEPROMs, in a 32 pin DIP. I've already programmed them based on the translated rom, that shouldn't be a problem (assuming it's written so it can run on a real console, that is).

I've already acquired Maharaja, which uses the same mapper as the translation, seems to use the same mirroring, and has a CHR and PRG just like Portopia uses. The PRG is 28 pins, however, and I don't know how to connect my 32 pin EEPROM to it. Is it the same pins as on MMC3 cartridges? Can I just stick the CHR in as is since it's 32 pin? The game also has a battery, which portopia doesn't use, and I'm not sure if I can just remove it. I figure it's probably also a good idea to replace the 22uf electrolytic capacitor on it since it's pretty old if this works.

I was mainly wondering if this would even be possible to do (I haven't seen anyone's finished repro of the game yet) and if so, what modifications I'd need to make.

Thanks a lot for reading this.

See the last time.

I saw that thread, but it uses UNROM I believe, and I've already gotten the cart for mapper 68, unless doing it for that works the same.

Thanks.

The English translation uses mapper 68 (SUNSOFT-4) only because it was better supported by emulators (at the time) than the previous mapper 78 (Uchuusen) translation.

But either way, the translation only used both hardware variants as though it were UNROM, with CHR ROM instead of CHR RAM, and without bus conflicts. Hence why my patch to UNROM was so tiny (and simple).

I'd save your Maharaja board for actually translating Maharaja instead...

That's fair enough. I do appreciate the work that went into patching it, but if I were to go UNROM could I order an INL board or would I have to use one of the donors?

I didn't see anything in the topic about which pins go where, but I assume it's probably more documented for UNROM. Sorry if these are dumb questions, but I'm pretty new to doing these.

I'm interested in learning about this stuff but there don't seem to be a ton of resources from my searching around for lesser known mappers, so I figured I'd ask here since I know from reading about other stuff that there's a lot of really skilled people here.

How much space is left in the translated ROM? If at least 6-7K or so, the way forward might be to stick CHR data into one of the banks and decompress that to CHR RAM before the title screen. Then you'd be able to stick on any ultra-common UNROM.

I'm not sure. The ROM size (just after the english patch) is 73k, so I guess it'd be 72k without the header. I guess that would probably leave a decent amount of space somewhere if you put it on an EEPROM, but I'm not very knowledgeable about how they split it up exactly.


From what I understand, the original used a sort of compression to fit it on NROM, and I think I remember reading that they used a sort of compression of their own, but I could be wrong about that.

If there's at least 7K of blank space in the first 64K of the 73K file to fit compressed CHR data, a hack to UNROM can fit on a 27C512. Otherwise it'll need a 27C010 or bigger.

There doesn't appear to be much blank space at all until after about 65k just looking at the hex.

Converting a board from "ordinary" UNROM to "UNROM with CHR" is just a matter of pulling the RAM and replacing it with a ROM. A 28-pin 8 KiB ROM would be laziest, but other options could work too.

I think INL's boards are using SMD RAMs, and replacing that with a ROM could be a pain. You could try one of the other retro board manufacturers such as ... uh, Retrostage? (I guess that's it right now?)


The translation is pretty full. I have no idea how much of it is used... most of it is data. And a lot of it is duplicated across the first three banks.

Would the retrostage board have possible bus conflicts or is that not a concern with it? I'm assuming I could just stick the 2 UNROM chips and caps and eeproms in and solder some of the pads and I'd be good?

I'm guessing if i went that route I'd want to go ahead and get the 28 pin EEPROMs so there isn't any funky wiring.

The patch I made resolves the bus conflicts in software. (While one could explicitly add an inverter to remove bus conflicts, it shouldn't be necessary here)

Yeah, should be.

It would certainly be prettier that way. Whether that bothers you is something only you can answer

Alright, I guess I'll take a stab at it, thanks for making the patch. I did think using such an advanced donor for a game that started on NROM was a little weird, so thanks for steering me in the right direction.

A bit of a tangent, but I'd like to learn NES programming at some point, but I'm basically at the level of only being able to edit minor things in an already finished game, so it would probably take me a long time. I tried looking at the wiki, but after reading a lot I couldn't even manage to get something to appear on screen and know why it worked. I have some experience with x86 assembly, but I haven't used it in a pretty long time, so it's cool to see that people are still making games and patches for stuff like this. I actually first learned about NesDev when I found Rainwarrior's StarTropics fix and that kind of got me started on this whole thing. Well, that and the ridiculous prices on older games...I still remember the good old days when you could find them in bulk everywhere for hardly anything.

Anyway, thanks for the help.

Even as slow as the code that CC65 generates is, I think currently I'd recommend dougeff's and shiru's tutorials on writing NES games in C.

It's not like assembly is exactly hard, but the amount of effort for a "my first game" is easier.

I'd rather do it in assembly, it's just that I keep looking at random things that don't really help me on the wiki, and the main tutorial link seems to be for CC65. There's probably the info I want on the wiki, but it's all spread out everywhere and I have trouble putting it all together into a streamlined process to just get things going.

I do have a good amount of more recent C/C++ experience, but I want to be able to take full advantage of everything since I'm sure CC65 isn't super optimized. I've only really tried for a little while, I think I just got overwhelmed with all the NES-specific things there are without focusing on the basics of what I have to do just to get started, since I have a bad tendency to jump into things at the deep end.

I thought I'd update and say everything finally came, so I soldered it together and it went perfectly. Thanks for the help and doing the patch lidnariq. The cartridge is a little fiddly, but I've noticed that that's the case with even real games using the NES to Famicom adapter...