LH2311 Mask ROM and 28 pin EPROM

[DNSDies]

I'm trying to use a sunsoft game to play a romhack (english translation of Portopia Serial Murders) that requires that specific mapper. The PRG rom is a simple 28 pin drop and solder, but the CHR rom on the board is a 32 pin 128KB rom with the following specs:



I need to drop an 8KB CHR rom to replace that, but it's putting a 28 pin rom into a 32 pin hole.
It looks like it mostly matches, the only rewire I see is sending VCC to pin 28 from hole 32.

The donor cart I'm using is Maharaja.
Am I missing anything?

[Memblers]

Am I missing anything?

Seems like quite an extreme mapper to require, for a translation of an NROM game. Unforunately, I would say unless the developers who made this translation/hack tested with this mapper (rather than an emulator), there's a good chance that it won't work.. Emulators tend to be really lenient, particularly regarding mapper initialization.

[DNSDies]

the translation changes a LOT of stuff in the game.
http://www.romhacking.net/translations/764/

The rom had to be expanded to accommodate the translation, and it won't work in an emulator if it can't play After Burner due to it really needing that mapper.

[tokumaru]

http://www.romhacking.net/translations/764/

"Additional code hacking to allow emulation on more emulators" doesn't sound very promising. It's tough to make a cart out of a program you're not sure will work on hardware, since you'll not be sure whether the problem is your soldering/wiring or the software itself if things go wrong.

The rom had to be expanded to accommodate the translation, and it won't work in an emulator if it can't play After Burner due to it really needing that mapper.

Memblers' point is that the original game is the simplest kind of cart there is, with no mapper at all, so it's weird that they picked such an exotic mapper to accommodate the changes, when something more traditional would probably have sufficed.

I need to drop an 8KB CHR rom to replace that, but it's putting a 28 pin rom into a 32 pin hole.

You don't NEED to drop an 8KB CHR-ROM though... If it's any easier for you, you could just use a larger chip and fill it with the same 8KB over and over. Whatever you decide to do, the basic rewiring rule doesn't change: match pins and holes that are labeled the same. When in doubt (sometimes /OE, /CE and such are not labeled consistently), compare the the pinouts of a 32KB mask ROM and a 32KB EPROM or FlashROM known to work without any rewiring, and use that as a reference.

EDIT: Checking out the documentation for mapper 68, I really can't see why they'd NEED it. The original game was NROM, meaning it had no CHR bankswitching at all. Japanese needs more characters than english, so it's not like they needed any expansion there. NROM also doesn't have any mirroring control, so I can't see why they'd need that. The PRG switching capabilities of mapper 68 are exactly the same as UNROM, one of the simplest and most common mappers around.

The only feature of this mapper that they might have used is the ability to map ROM for the name tables, maybe for a title screen or something of the sort, but that would be a very lazy thing to do.

[DNSDies]

Well, I have a spare unrom from a baseball game, so I can try it both ways.

Regardless, it will be a fun experiment.

Upon further investigation, it looks like this hack really does require the mapper:
http://dvdtranslations.eludevisibility. ... -revB2.txt

Code: Select all

Because all this compression was already in place, there was nothing left for me to compress.  I had to expand the ROM with a mapper chip to fit in the English text.  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.

The Rev.B patch changes to mapper 68 to provide the same service, but makes the end ROM more compatible with emulators, since at the time he did this, most emulators didn't support Mapper 78 properly.

[tokumaru]

Well, I have a spare unrom from a baseball game, so I can try it both ways.

That's not something you can try, if the ROM was made for mapper 68 it will not work with UNROM. My analysis was just explaining that it could have been hacked to UNROM instead.

Upon further investigation, it looks like this hack really does require the mapper

I know it does, my point is that it SHOULDN'T. This:

With it you could have any number of program banks replace the first program bank, but not change the second program bank

Is exactly what UNROM does, and it's one of the most common mappers. There was no reason to go for an exotic mapper that's poorly supported by emulators and is hard to find in hardware form for the making of repros.

The only reason I can think of that made them not use UNROM is that it uses CHR-RAM, so they'd have to manually copy the CHR data to the CHR-RAM chip. A competent programmer can write a routine to do this in 5 minutes, so the hackers were either lazy or incompetent.

[l_oliveira]

Nothing prevents you from using UNROM mapping for PRG and put a CHRROM instead of CHR RAM, no ?

[nintendo2600]

Also isn't the 161 mapping used on CNROM? You could just add the extra address lines to the 161 on a CNROM no?