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).
lidnariq wrote:
Code:
$ sha1sum *.nes
c943a39cb4b4d67395a22138a78f74815b1f82d7 Portopia Renzoku Satsujin Jiken (J) [!].nes
7bc0b7a13495a4aa50272d845c28b3531e8e45fe TranslationFromRHDN.nes
82a7bbf67361aaa3ed72ef2df4623d1c8be4a1d1 UNROMPatched.nes
$ crc32 *.nes
9b2b749b Portopia Renzoku Satsujin Jiken (J) [!].nes
88679d11 TranslationFromRHDN.nes
10650200 UNROMPatched.nes
$ md5sum *.nes
8e2619180062804b3300477ef82a66bb Portopia Renzoku Satsujin Jiken (J) [!].nes
b0e67aa8214af3a4a831ab2e3d569415 TranslationFromRHDN.nes
e10ca85f92e3a318b0f694a116249b8a UNROMPatched.nes
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" ?
lidnariq wrote:
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.
lidnariq wrote:
... 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:
Code:
Lunar IPS (LIPS) Version 1.01
Apply IPS Patch Log
Offset Size RLE IPS_File_Range IPS_File_Size
------ ---- ID 00000000-00000004 5
000006 2 No 00000005-0000000B 7
00DE97 6 No 0000000C-00000016 B
00E321 2 No 00000017-0000001D 7
------ ---- EOF 0000001E-00000020 3
Total Patches: 3 (3)
And there's still wrong text:
Just out of curiosity, do our hashes agree?
Code:
$ sha1sum *.nes
c943a39cb4b4d67395a22138a78f74815b1f82d7 Portopia Renzoku Satsujin Jiken (J) [!].nes
7bc0b7a13495a4aa50272d845c28b3531e8e45fe TranslationFromRHDN.nes
82a7bbf67361aaa3ed72ef2df4623d1c8be4a1d1 MyPatched.nes
$ crc32 *.nes
9b2b749b Portopia Renzoku Satsujin Jiken (J) [!].nes
88679d11 TranslationFromRHDN.nes
10650200 MyPatched.nes
$ md5sum *.nes
8e2619180062804b3300477ef82a66bb Portopia Renzoku Satsujin Jiken (J) [!].nes
b0e67aa8214af3a4a831ab2e3d569415 TranslationFromRHDN.nes
e10ca85f92e3a318b0f694a116249b8a MyPatched.nes
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?
lidnariq wrote:
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.
Attachment:
unrom07-highlight-q0-and-q1.jpg [ 22.11 KiB | Viewed 2788 times ]
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!