SOROM WRAM bank control bit (conflicting info)

Reviewing the MMC1 SxROM upper CHR lines on the wiki I found an interesting point yesterday that supposedly SOROM uses the second highest CHR address bit (CHR-ROM A15) to select the 8KB WRAM bank.

I had always thought it was the highest bit (A16). Pretty sure I got that idea in my head from one of two sources, Kevtris which claims the highest bit, although it's confusing how he shifts things in 4KB mode.. Or I learnt it from disch's docs. My copy of disch's docs agreed A16, but just now I downloaded the currently release from romhacking. The current copy of disch doc's actually agree with the wiki (A15).

Based on that modification to disch's docs and current wiki info I'm guessing it was determined sources claiming A16 were wrong, and it's actually A15.

Don't have an SOROM cart to verify for myself, but probably going to pick one up when I can gotta catch em all.. Trying to glean info from bootgod's database doesn't give much as all US carts are front side of PCB pics only with no traces leaving the top layer from those pins. The JP version does have bottom pics. While inconclusive based on photo alone, there is a trace leaving the A15 pin which goes to a via under the MMC1 chip. Assuming that via is useful and ends up controlling the WRAM bank that would agree with the wiki and current version of disch docs.

Tried some Koei games on my boards and not sure I even found a place to save, was unable to find a loadable game reguardless of what bit I used.

Tried Holy Diver Batman, and got interesting results..
A16 used for WRAM bank select: Seen as good SNROM (8KB RAM OK)
A15 used for WRAM bank select: Craziness S*ROM 24KB RAM PROBLEM
A14 used for WRAM bank select: S*ROM 16KB RAM PROBLEM
A15&A14 used for WRAM bank select: Seen as good SXROM (32KB RAM OK)

Now perhaps the PRG RAM PROBLEM is stemming from how I only implemented chr bank 0 in my logic simplifing out chr bank 1 since one should have both match, or use 8KB CHR bank mode. But how Holy Diver Batman sees 24KB of WRAM when there clearly is none sounds like a bug, might be cause of the curve ball I threw with only using chr bank 0 though I suppose... I should implement both banks and see what Holy Diver Batman says.

So anyway, any background discussion burried on the net that occurred on this to change disch's docs? Or has/can someone verify this with a multimeter and an original SOROM board before mine arrives?

EDIT: on closer read, my old disch docs shifted things around like Kevtris did in 4KB mode, so perhaps he just copied info from Kevtris which was the source of the suspected bad info?

I am the one who did edit the Dish docs, I was confident that they were wrong and that the wiki was correct. Now, looking back, I think I was overconfident. I don't have any access to SOROM so I'll try to reverse engineer SOROM games and see how they swap SRAM banks, this should give the answer.

Also : Don't worry about 4k mode too much. Since you'll be using CHR-RAM it makes no sense to use it, use $2000 instead to determine which pattern tables are used. If you really want to use 4k mode it changes nothing, you just need to write the same value in both regs. It does not change which bit is in cause of controlling SRAM banking, the values written to the regs are always 4k bank numbers, even in 8k mode, that is why.

Thanks for the info Bregalad,

Yeah my guess was that Kevtris probed things out on his board as he had a physical copy, but it's possible he did make an error. And my guess was that Disch's reverse engineered games to determine behavior. So with those guys previously agreeing make it hard to discount both of them.

I'm interested to see what you come up with REing the game(s) yourself.

I did pick up a copy of Genghis Khan off ebay but won't have it for another week.

Alternatively if anyone knows how to get these games to save that'd be valuable info. I couldn't find anything in the manuals which makes me assume it just saves your progress automatically after each turn or something. I played for a turn or so and couldn't find data to load upon reset. Perhaps I've got some bug with my hardware setup though, either that or I'm not actually saving..

On Genghis Khan, when it's your turn you select the last option (other), and the save command is in there. I do have the cart, but it's at a friends' house.

Why was SOROM created?
Back then, a 62256 might have been more expensive back then than two 6264s. Nowadays, the situation has changed.

What's with the 24K?
Holy Diver Batman measures from the start of memory to the end of the last unique bank. It was not designed for SOROM or anything else with holes in the RAM map. (This means it'll probably puke on TQROM too.) Nor was it designed for boards with only half of one kind of RAM battery-backed. I was assuming that future homebrew games using an MMC1 clone and CHR RAM would all use some variant of SXROM.

Should we sell SOROM at all?
In the SXROM numbering system, SOROM has two banks: bank 0 and bank 2. Bank 1 is mirrored to bank 0, and bank 3 is mirrored to bank 2. Only bank 2 is battery-backed. This means an SOROM game will still run on SXROM so long as A. it accesses only banks 0 and 2 or only banks 0 and 3, and B. its soft reset detection doesn't assume bank 0 is destroyed when power is lost. If the Koei games don't rely on things like being able to write a value to bank 2 and read it back from bank 3, and they don't freak out when bank 0 has valid data in it, then they'll still run on SXROM and you don't need to sell SOROM.


EDIT: missed a chip

You should say, a 62256 and an inverter was more expensive than two 6264s and an inverter. SOROM also requires an inverter for the CE pins of the second SRAM, it is implemented with a transistor and a resistor.

Also nothing tells that infinitives wants to create his own homebrew using SOROM (like you seems to have assumed to), he just wants to clear up conflicting information.

EDIT:

So I checked both Ghensis Khan and Romance of the Three Kingdoms. The SRAM bank switching code looks like this:

Which makes it clear the forth bit (bit 3) is used for bankswitching, not bit 4 as stated in the previous version of Dish docs and on Kevtris' homepage. They should have confused with SUROM which does uses bit 4. I'm relieved, my modification to Dish docs actually corrected them and didn't introduce an error.

But that's clearly writing specific values to BOTH of the two MSBs, not just the 4th or 5th...

If you look at the only SOROM PCB back in NESCartDB, there's clearly a trace going to pin 10, although I can't see where it goes afterwards.

I forgot to specify that $52 was containing either $00 or $01. But yeah, if it was containing $02 or $03 that'd change a lot of things. I belive they used "lsr A" to save a byte as opposed to "lda #$00", I always use this trick myself when I know that A=$01 or A=$80 and I want to have A=$00.

Apparently bank $01 is used just for the saving, and bank $00 during gameplay. When you choose to "save" in Ghensis Khan it does constant switching so I believe it copies data from one RAM bank to another. This is pure speculation, but it makes the most of sense given the context.


The absence of a trace going from MMC1's pin 11 is probably the most interesting in our case.

Thanks that did the ticket, should have thought to look there. Pretty sure that info isn't in the manual..

Thanks for checking out the code Bregalad! I was able to verify it's using CHR-ROM A15 pin for myself as well being able to save and load on one of my boards.


Thanks for the explaination makes sense now, there's 24KB of space between the first and last byte of PRG-RAM.. And the 8KB hole is the "problem." Support for SXROM is fine, I'm not suggesting/recommending support for SOROM be added. I was scrounging for data points when I tried it out and got unexpected results. They would have been more expected had I taken the time to read that SOROM isn't supported in the readme.


All valid points once you've verified they are indeed compatible... At the time of writing the OP I had a hard time discounting kevtris and Disch when I had no solid evidence of my own.


Why is the absence of a trace from pin 11 (CHR-ROM A16) interesting? We just concluded that A16 isn't used for anything on SOROM. The trace/via going to pin 10 (CHR-ROM A15) can now be safely assumed to run to PRG-RAM control circuitry.

Because it confirms that conclusion. It's always better to double check, considering all the confusing info that erroneously stated that A16 was used in SOROM.