It is currently Mon Apr 22, 2019 1:14 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Thu Mar 14, 2019 6:40 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4014
Location: A world gone mad
Welcome to the romhacker's conundrum! :D

I've been working on a game for the past 6 months -- actually, the only game known to use SMROM, which is MMC1 (not MMC1A!) + 256KB (2x128KB) PRG-ROM + 8KB CHR-RAM + no battery. There is not enough room in this ROM to provide enough space for a Japanese/English translation, thus it must be doubled to 512KB. My options are... complicated... and I'd like some opinions. Some details about this game:

- Mapper set up to use vertical mirroring. However, I haven't completed a full analysis of everything, so for all I know there could be some animated parts that use horizontal screen panning, or maybe even switches to horizontal mirroring etc...
- MMC1 isn't subject to bus conflicts, thus moving to a mapper that suffers from bus conflicts could be a serious problem (it's not easy to simply "shift" a game up by 16 bytes, to make bytes ex. $8000-800F etc. available for ROM bank selection use)
- I'm unsure if there are invalid writes to $6000-7FFF on this game -- I just haven't looked yet. It's assigned mapper 1, but MMC1A (and thus I assume MMC1) are subject to complications like this
- (Random fact) Nestopia has an incorrect forced-board-type on this game of SGROM (it's truly SMROM but SGROM functions the same way in this case). It retains mapper 1, however, so this is not a game that's forced onto mapper 155
- There is no playthrough of this game, which makes testing and verification of features/use/things very difficult -- further compounded by my lack of being able to read Japanese

Options as I see them:

1. Convert to SUROM, which is MMC1B2/MMC1B3 + 512KB PRG-ROM + 8KB CHR-RAM

- Pro: same mapper, backwards-compatible mostly (see below)
- Pro: not subject bus conflicts
- Pro: 512KB support is implemented via writes to $A000-BFFF swapping between each 256KB "half". Might be possible to keep the Japanese version in one half, and the English version in the other half, offering a menu system where the user selects what language they want
- Con: 512KB support is implemented via writes to $A000-BFFF swapping between each 256KB "half". In other words: it isn't just a full 512KB you can pick 16KB from via (the MMC1 equivalent of) lda #20 / sta $E000 ; map bank 20 to $8000-BFFF
- Con: 512KB support would lead to a lot of duplicated banks, which means the IPS patch would contain large sums of intellectual property
- Con: native donor boards are extremely limited -- only 4 other Japanese games use SUROM
- ???: includes 8KB PRG-RAM ($6000-7FFF) that is battery-backed; does this complicate matters? See above
- ???: unsure of console (ex. Retron 5, etc.) and flash cart (ex. PowerPak, EverDrive N8, etc.) compatibility
- ???: if NES 2.0 header required, unsure of emulator and console/flash cart compatibility

2. Convert to UNROM-512

- Pro: offers 512KB natively
- Pro: donor boards w/ mapper are easy to get (i.e. just buy them from INL)
- Pro: no NES 2.0 header required (mapper 30)
- Pro: don't have to worry about anything relating to PRG-RAM since there is none
- Con: have more romhacking work to do, re: converting all mapper writes to UNROM (but probably not too much work/too bad)
- Con: mirroring is fixed (solder pad level), not mapper-level, thus could break the game if it changes mirroring at run-time
- Con: conditionally subject to bus conflicts: non-flashable boards are subject to them, while flashable boards are not
- ???: unsure of console (ex. Retron 5, etc.) and flash cart (ex. PowerPak, EverDrive N8, etc.) compatibility

I have a feeling there are other options I'm overlooking, but these are the 2 I pondered for a while. Thanks everyone.


Top
 Profile  
 
PostPosted: Thu Mar 14, 2019 7:47 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21315
Location: NE Indiana, USA (NTSC)
koitsu wrote:
- Con: 512KB support would lead to a lot of duplicated banks, which means the IPS patch would contain large sums of intellectual property

Nothing a bit of dd prior to patching can't fix. Or do the site's submission standards require IPS without a preliminary doubling step?

koitsu wrote:
- Con: native donor boards are extremely limited -- only 4 other Japanese games use SUROM

Pro: It's not that hard to modify SNROM to SUROM, nor SGROM to SUROM-without-PRG-RAM. It's only a couple more wires than modding SNROM into SNEPROM to make an ordinary SNROM game from a donor.

koitsu wrote:
- ???: includes 8KB PRG-RAM ($6000-7FFF) that is battery-backed; does this complicate matters?

Only if the game has bugs like those of Low G Man and Battletoads & Double Dragon, relying on open bus at $6000-$7FFF.

koitsu wrote:
- ???: unsure of console (ex. Retron 5, etc.) and flash cart (ex. PowerPak, EverDrive N8, etc.) compatibility

Last I checked, Holy Mapperel built as SUROM ran correctly on a PowerPak. And if later Dragon Warrior games that uses SUROM were broken, I assume they'd probably be on an incompatibility list by now. No, NES 2.0 is not required, as PRG ROM size 512 KiB means SUROM by default in classic iNES format as emulators interpret it.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Thu Mar 14, 2019 8:59 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 860
koitsu wrote:
moving to a mapper that suffers from bus conflicts could be a serious problem (it's not easy to simply "shift" a game up by 16 bytes, to make bytes ex. $8000-800F etc. available for ROM bank selection use)

Is that are theoretical problem that could arise with certain mappers? The problem doesn't exist for the UNROM-512 mapper that you have linked to. On that mapper, you would have to write to C000h-FFFFh, and you would need 256 bytes (if you want to support all combinations), and if you don't want to "shift" your game's memory map, use addresses near end of memory space, eg. FE00h-FEFFh or FEF0h-FFEFh or the like.


Top
 Profile  
 
PostPosted: Thu Mar 14, 2019 9:43 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4014
Location: A world gone mad
nocash wrote:
koitsu wrote:
moving to a mapper that suffers from bus conflicts could be a serious problem (it's not easy to simply "shift" a game up by 16 bytes, to make bytes ex. $8000-800F etc. available for ROM bank selection use)

Is that are theoretical problem that could arise with certain mappers? The problem doesn't exist for the UNROM-512 mapper that you have linked to. On that mapper, you would have to write to C000h-FFFFh, and you would need 256 bytes (if you want to support all combinations), and if you don't want to "shift" your game's memory map, use addresses near end of memory space, eg. FE00h-FEFFh or FEF0h-FFEFh or the like.

Ah, thank you. I had to actually read this document very very slowly. I was always under the impression that the lower byte of the address written to had to match the value being written, e.g. $xx00 for bank 0, $xx01 for bank 1, etc. -- and that those locations (in ROM) also had to contain the value being written (e.g. $xx00=$00, $xx01=$01, etc.). Apparently the lower byte of the address doesn't matter, and it's just that both 1) the value being written and 2) the value *at* the address being written be the same.

I went off to look at tepples' code for UxROM, and found in in unrom.s that identity16 is placed in segment RODATA, which starts at ROM15, which also happens to be used for CODE and DMC. For whatever brain damaged reason of my own, I think that lead me to believe the identity16 stuff would always end up at the top of the bank (i.e. $C000-C00F), with values $00-0F, and needed to be exactly there. I dug around old forum posts relating to all of this too and literally cannot find where or how I thought this needed to be the case, so the problem is purely with me.


Top
 Profile  
 
PostPosted: Thu Mar 14, 2019 10:22 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3668
Location: Indianapolis
koitsu wrote:
- Con: native donor boards are extremely limited -- only 4 other Japanese games use SUROM


Limited in variety but not quantity, as Dragon Quest 4 is really cheap (I noticed because I bought one, and converted it into Dragon Warrior 4). Looking it up on Wikipedia it sold 3.1 million copies, and was the 4th best selling Famicom game. So, I wouldn't worry about this point too much.

As for ditching MMC1, not worth considering unless/until you can be certain that the game never changes the mirroring bits. If you're lucky there might just one or a few subroutines that handles all the mapper stuff, and it shouldn't be too hard to tell if it's allowed.


Top
 Profile  
 
PostPosted: Thu Mar 14, 2019 11:45 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7412
Location: Canada
So three questions to resolve off the bat which will veto the whole thing:

1. Does it ever use MMC1's low-fixed PRG mode?

2. Does it ever use MMC1's 4k CHR banking?

3. Does it ever change nametable mirroring?


As for mapper 30, I think you'd really want to use mapper 2. Oversized UxROM support in mapper 2 is very widespread, and I don't think you're calling for any actual mapper 30 features. (8k CHR banking probably isn't going to help here?)

As for duplication, yes you'll need to move the high fixed bank for this in another mapper, though I don't think anything else would need to be relocated? Alternatives to IPS exist, though they're a whole other discussion.

Though actually if you can use MMC1 in its weird 512k configuration, switching the outer bank would let you have completely different code in your "other" fixed bank, so maybe staying with mapper 1 is a way to avoid that problem? When DPCM is playing, it needs to stay in place, so maybe that could need a duplicate, but otherwise there's nothing that would need to be duplicated at all in the second outer bank. You can switch into it then back out as needed to run patches. (This actually seems very convenient to me.)

PRG-RAM and bus conflicts should be a non-issue either way, and banking with UxROM doesn't even need a 16 byte table, it's just a convenient paradigm. You can find an equivalent byte to write over anywhere you want, it doesn't have to be in a table.


Top
 Profile  
 
PostPosted: Fri Mar 15, 2019 1:24 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4014
Location: A world gone mad
Thanks everyone. <3

@rainwarrior To answer your 3 main questions:

1. Nope -- it always keeps $C000-FFFF mapped to the last bank and only swaps 16KB at $8000-BFFF.
2. Nope -- the game is entirely CHR-RAM, so no CHR-ROM switching is involved
3. Covered in initial post -- "Mapper set up to use vertical mirroring. However, I haven't completed a full analysis of everything, so for all I know there could be some animated parts that use horizontal screen panning, or maybe even switches to horizontal mirroring etc..."

I didn't know UxROM had an "oversized" mode. The wiki doesn't mention it, instead stating........ well what the heck, that's wonderfully conflicting. This is exactly how threads get off-topic, hahaha...

- ASCII diagram only depicts 4 bits usable for UOROM (16*16KB = 256KB)
- "Emulator implementations of iNES mapper 2 treat this as a full 8-bit bank select register, without bus conflicts." -- 8 bits means essentially 256*16KB = 4MBytes, except...
- "To make use of all 8-bits for a 4 MB PRG ROM, an NES 2.0 header must be used (iNES can only effectively go to 2 MB)" -- what exactly about the original NES header limits this to 2MBytes? The original NES header gives an entire byte to PRG-ROM bank count.
- The first sentence states "emulator implementations", which might be OK for emulators but donor boards certainly do not have the upper 4 or 5 bits wired up, which means donor carts are limited, no?
- The only other section I saw mentioning >256KB support was in "Variants", mentioning Battle Kid 2 and use of 512KB UxROM via mapper 30 (i.e. UNROM-512), which is why I focused on it.

As for staying with MMC1:

1. Is there anything about MMC1 (which is what this game uses) vs. MMC1A vs. MMC1B2 vs. MMC1B3 I need to worry about if someone was to use a donor cart with the latter chips? There's no PRG-RAM in this game, but I don't know for sure (at this stage) if it does issue spurious writes to $6000-7FFF. I want to assume it doesn't -- I certainly need to find out through closer disassembly analysis (there's no walkthrough or play-through anywhere and I can't read Japanese).

2. MMC1 boards (incl. donor) -- the options I see in this case would be:

a) INL's CPLD-based boards for SUROM ($20 each), which I'd trust 100%. SXROM maybe (same price, but mentions avoiding CHR-RAM)
b) SOROM -- mainly Koei games -- don't appear to support 512KB according to this chart and this page (read footnote text)
c) SUROM -- already discussed (maybe the 2nd-most-viable choice next to INL boards)
d) SXROM -- not feasible due to extreme rarity

Do I have this right? :)


Top
 Profile  
 
PostPosted: Fri Mar 15, 2019 5:55 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21315
Location: NE Indiana, USA (NTSC)
koitsu wrote:
- ASCII diagram only depicts 4 bits usable for UOROM (16*16KB = 256KB)

I have clarified that this figure depicts UNROM. The caption now describes how the 2 Mbit (UOROM) and 4 Mbit (homebrew "UNROM 512") boards relate. Is this any better?

koitsu wrote:
- "To make use of all 8-bits for a 4 MB PRG ROM, an NES 2.0 header must be used (iNES can only effectively go to 2 MB)" -- what exactly about the original NES header limits this to 2MBytes? The original NES header gives an entire byte to PRG-ROM bank count.

The largest power of two value that a single byte can hold is 128, which corresponds to a PRG ROM size of 2 MiB.

koitsu wrote:
- The first sentence states "emulator implementations", which might be OK for emulators but donor boards certainly do not have the upper 4 or 5 bits wired up, which means donor carts are limited, no?

UNROM could be rewired to UOROM, but rewiring to the mapper 2 compatible subset of "UNROM 512" would need an additional '161/'32, possibly mounted on the board "dead-bug style."

koitsu wrote:
1. Is there anything about MMC1 (which is what this game uses) vs. MMC1A vs. MMC1B2 vs. MMC1B3 I need to worry about if someone was to use a donor cart with the latter chips? There's no PRG-RAM in this game, but I don't know for sure (at this stage) if it does issue spurious writes to $6000-7FFF.

Spurious writes to those addresses don't matter as much as depending on the value of spurious reads. That's what breaks Low G Man.

koitsu wrote:
2. MMC1 boards (incl. donor) -- the options I see in this case would be:

e) SGROM or SNROM donor modded to behave as the relevant subset of SUROM by running one wire from MMC1's CHR A16 out to the PRG ROM's A18 in.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue Mar 19, 2019 2:51 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7692
Location: Chexbres, VD, Switzerland
Eventually, it all ends up in what you want to do.

If patching use .ips format is important to you, you can't use SUROM-style extension, so you have to use another mapper. I personally very much dislike this UNROM-512, but if that suits your needs, go for it.

On the other hand, if patching with another format such as UPS or XDELTA or whathever is fine, I think it makes more sense to stay to the original mapper and expand the ROM to 512k. The fact that no games have used this configuration with no PRG-RAM should not be an issue - it's very unlikely your game does a Low-G-Man-style crash if SRAM is present.

You also didn't mention it, but you could add some form of compression in order for the game to still fit in 256k.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group