Reproducing Portopia

I'm going to have to bump this thread, I'm interested in doing a Portopia Renzoku reproduction, the first revision of the translation by DVD translations uses Mapper #78 and the second uses mapper #68. Now I don't know if the #78 version is compatible with the Holy Diver specific circuitry? How do I check that?

Also, when they will be available again? I can't find a purchase button.

EDIT: Thanks to our friend, lidnariq, it is possible to use a UNROM board to reproduce Portopia Renzoku Satsujin Jiken, translated by DvD Translations (Rev B)! Just apply their patch into the original rom, then use lidnariq's UNROM + Character ROM patch. I fully tested it with Nestopia, played to the end with no glitches. Have fun!

Patch: download/file.php?id=1095 (33 bytes).

Look at the game running in an emulator with a nametable viewer, such as FCEUX for Windows. If the #78 version uses one-screen mirroring (all four nametables the same), it's the Uchuusen Cosmo Carrier board. But if it's normal horizontal/vertical mirroring, it's the Holy Diver board. If scrolling is visibly broken, then the emulator is using the wrong mapper variant.

In the readme it says it's the Uchuusen (1A/1B) variant.

That said, they completely redid the translation between the two builds. Not clear why they're using a whole sunsoft 4; their translation requires only a bus-conflict free UNROM variant with 8KiB CHR ROM instead of RAM.

So I guess it is unsupported, right? I'll change manually the ines header to see if it is compatible with another mapper with that specification, lidnariq.

Nestopia, at least, supports the Uchuusen variant by default, and makes it exceptionally hard to make hacks/homebrew using the Holy Diver variant.

It'd be really easy to re-hack the revision B translation to the funny UNROM variant I mentioned above; it basically just involves commenting out the CHR bank setup routines they've added. I don't know if any emulators support using CHRROM instead of CHRRAM on UNROM, though, and I know very few support disabling bus conflicts.

.... Actually, with only 4 banks, the bus conflict avoidance table is only 4 bytes long. Gimme a moment.

Thanks for the insight, lidnariq. I'll read the docs on the Wiki and try something too.

It appears that the bankswitching is used only when text is being rendered and the nametable registers are unused. The graphics are mapped one time only, too, to replicate the character rom setup of the original program (mapper 0). Perhaps something can come out of this? Hmm.

Haven't tested beyond the title screen, but this seems to work in nestopia:
It skips the CHR init sections and changes the banking instruction to use something that (coincidentally) avoids bus conflicts.

There are some out of place dialog in ceirtain areas... I got a dialog piece from the endgame by using the command hit in the first screen...

I guess the problem is the separate 2K bank swapping that is used in the original patch. Anyway, don't waste much time on it if it is too much trouble. Thanks anyway.

It doesn't use the advanced banking facilities at all. Honestly, at all. It's really just using the Sunsoft 4 as a fancy UNROM variant, very similar to what they were doing before with mapper 78.

Also, what "command hit" ?

You sure about that? Any clues about the cause of the errors? In the readme he says:
"But, I only needed a really basic chip that simply doubles the lower bank of program ROM as this is where all the 496 blocks of text are stored. I would simply swap it based on which of the pieces of text need to be displayed at any moment.
It turned out that Mapper 78, the Irem 74HC161/32 chip was perfect. With it
you could have any number of program banks replace the first program bank, but
not change the second program bank--exactly what I needed."
it fits your description but I wonder why the text shown is incorrect.

Also, the command hit:

OH. I see what I'm doing wrong.
The original bankswitching calls with A and Y not just in the range of 0 to 3, even though there are only 4 banks, so it'll index past the end of the bus-conflict avoidance table. For emulators (and hardware) that enforce bus conflicts, it'll then switch to bank 0 instead of 1 or 2 as it intended.

This fixes that.

Have you uploaded the wrong file? I still get the same bugs.

Thanks a lot for taking your time to hack the rom!

... Are you sure you did? The previous patch was 31 bytes, the new one is 33. With the old patch, the "hit" command when in Hanakuma wouldn't ask where to tap and would display some random crud; now it seems to DTRT.

Yes... I retried a dozen times with different files to make sure. Here's the log of Lunar IPS:



And there's still wrong text:

Just out of curiosity, do our hashes agree?

Yes, 100% match. Why does it work for you and not for me???

I've been mostly testing in nestopia (debian:1.45+dfsg-1) and fceux (debian:2.2.1+dfsg0-2), but I only rarely tested using wine or virtualbox with nintendulator (windows:0.975, but doesn't support CHRROM on UNROM), and fceux (windows:2.2.2)... which is why:
In the changelog for FCEUX 2.2.2 they claims they "fixed" mapper 2. And by "fixed" I mean the most hilarious piece of crap I've ever seen. Never fear, if you actually built a reproduction it would work fine: we only need to prevent bus conflicts on the bits that are used by the latch (two for a 64KiB UNROM game), not all eight.

Anyway, would a moderator please split this entire tangent about Portopia?

Thanks a lot, you made my life 100x easier! Awesome! Working in Neutopia/Windows. And I agree on the thread split, sorry for the offtopic questions.

Hi,

I stumbled upon this thread trying to make this game. I've created the rom from your fix and burnt it and put it in an UNROM board but it doesn't work. I'm guessing this is due to the CHR-RAM? But all UNROM boards have this so is it okay to just take that chip out and put in the CHR data from the ROM? Or will rewiring be required?

Thanks,

- Hubz

What kind of "doesn't work" ? Even before you've replaced the CHRRAM with a CHRROM it should display a smear of colors (not unlike what you'll see running it in Nintendulator), just not the actual content.

The pinout of the 8KiB RAM used should be compatible with that of an 8 KiB 'PROM. If you're using an EEPROM, you might want to tie its /WRite input high, but flash or UVEPROMs shouldn't need any help.

Hmmm no smear of color just a solid screen. I"m using a 27c512 EEPROM but I have mirrored it up to 64kb for both PRG and CHR on a California Games PCB. I didn't think it would need rewiring since it is a 28 pin EEPROM but maybe I am wrong. I went ahead and took out the CHRRAM and added the CHR ROM but no difference unfortunately.

Thanks for any advice you can provide,

- Hubz

Do you get the klaxon from the opening animation when it first starts? If not, something is going wrong much earlier than the CHR should matter.

I dug around for a bit, and just discovered a "funny" bug where if, for some reason, the game boots with the movable bank bank as the final bank it'll crash... On the unlikely chance that's what's wrong, you could add a couple of resistor+LEDs to the outputs of the 74'161. Or just test it with a voltmeter. But ... that's pretty unlikely; the game itself never writes 3 to the register, and the latch really should power up with the value 0 in it.

Pinout of the 74'161. Check the pins labeled Q0 and Q1 (13 and 14); if both are high that's what's wrong. If so, it can be fixed by lifting the /CLEAR pin (1) on the 74'161 and adding a resistor and capacitor. If that is what's wrong, the Correct Fix involves finding some free space in the final 16kB of the game... which in turn involves either DvD having their notes on where there's any, or someone else sitting down and play testing giving me a complete CDL.

If that's not what's wrong, I don't have any better guesses than rewiring problems... You did rewire pin 22 to be ground instead of A16? Should have been the only thing you had to do.

No go unfortunately... I didn't have pin 22 to GND but do now and still nothing. Has anybody made a UNROM Portopia by chance?

Thanks,

- Hubz

I can't tell: did you test the 74'161's outputs?

Also, I failed to be specific, the rewiring I meant was on the PRG ROM, not CHR ROM.

How easily can you program another 'PROM to test with? If it's easy, try testing with Magic Floor or Galaxian or something else tiny and reasonably guaranteed to work.

Sorry haven't gotten to mess with this until now.

I'm a newbie with all this so not sure what you mean by the outputs being high? Do you have any link on explaining how to test that with a Multimeter?

Thanks!

- Hubz

Assuming you can get access to the cartridge while it's in the NES and on, measure the voltage on the pins I've circled in red.
As long as both of them aren't more than 3V, then that's not what's wrong.

Just want to say thank you and I got this to work finally after messing with it again today. It was a combination of a bad EEPROM i believe as well as I had the wrong pin run to GND. I stupidly was counting for a 32 pin chip instead of 28 so I was off. Thanks for all your help now I can finally play this game on the console!