nesdev.com
http://forums.nesdev.com/

iNES Mapper 81
http://forums.nesdev.com/viewtopic.php?f=3&t=16412
Page 2 of 4

Author:  zxbdragon [ Tue Aug 29, 2017 12:56 am ]
Post subject:  Re: iNES Mapper 81

NewRisingSun wrote:
On the subject of NES 2.0 vs. UNIF: I'm planning to make a post about assigning NES 2.0 mapper numbers (256+ for non-Chinese/512+ for Chinese) for all those boards that so far are UNIF-only. :lol: For that purpose, I will also post a UNIF->NES 2.0 converter. ;)

zxbdragon wrote:
Nes 2.0 is very bad, so its use is not recommended. nes 2.0 submapper have 15. 255 * 15 mapper number,is Very don't meet the requirements.
NES 2.0 has 4095*15 mapper numbers,is Very do meet the requirements.

The actual:
main mapper 255(At least the nes is 2.0 )
sub mapper 15 (sub mapper max 15)
4096 is next version.

If the same main MAPPER,but submapper information completely different, nes 2.0 very chicken ribs.

unif After the completion of can reach the PRAM, CRAM (SIZE, SAVE) .
nes 2.0 use ines header,Limited, impossible to 4096 * 15


7 0
---------
SSSS MMMM

S: Submapper number. Mappers not using submappers set this to zero.
M: Bits 11-8 of mapper number.

MMMM 1111 is 4096?
Nes 2.0 is the most chicken ribs, and one of the most chaotic mapper management solution

Author:  NewRisingSun [ Tue Aug 29, 2017 2:27 am ]
Post subject:  Re: iNES Mapper 81

Please read the NES 2.0 header description carefully before claiming more nonsense. The NES 2.0 header provides twelve bits for the mapper number (byte 6 bits 4-7, byte 7 bits 4-7, and byte 8 bits 0-3), yielding 2^12=4096 mapper numbers, plus an additional four bits (byte 8 bits 4-7) for the submapper number, yielding 2^16=65536 different board types or variants.

Author:  Pokun [ Tue Aug 29, 2017 4:09 am ]
Post subject:  Re: iNES Mapper 81

I can't say I don't understand Zxbdragon though. But I guess the real chicken ribs here that's too well established to be thrown away is the original iNES format (even Nintendo's official emulators are using it). NES 2.0 is a carefully designed upgrade to the already messy iNES that solves the problems with it while maintaining backwards compatibility.
Sure it's messy but I think the mapper hell for Famicom/NES is the main source for the mess. In later Nintendo systems, cartridge manufacturing was more regulated, and the mask ROMs came with official headers, which is why there's not such a mapper hell for Game Boy or Nintendo 64.


UNIF just has too many problems for it to be useful.

There's a proposal for MAME-like metadata in the wiki to be used in a separate file. I guess that's the way to go if you want that kind of data to go with the ROM.

Author:  zeroone [ Tue Sep 05, 2017 1:41 pm ]
Post subject:  Re: iNES Mapper 81

Is there a ROM file available?

Author:  MLX [ Wed Sep 06, 2017 12:19 pm ]
Post subject:  Re: iNES Mapper 81

The ROM is hoarded because the cartridge owner requested it. At least it's preserved.

Author:  zeroone [ Wed Sep 06, 2017 3:18 pm ]
Post subject:  Re: iNES Mapper 81

MLX wrote:
The ROM is hoarded because the cartridge owner requested it. At least it's preserved.


I assume this is some unlicensed game then? Is the owner willing to sell?

Author:  krzysiobal [ Thu Sep 07, 2017 2:36 am ]
Post subject:  Re: iNES Mapper 81

Quote:
The fact that Kazzo's CNROM script only yields 8K of CHR ROM data confirms that the CHR ROM switch does not respond to $8000-$FFFF bits 0 and 1.

I had the same issuse with Moero Pro Yakyuu - this and yours game decodes $6000-$7000 but does not take M2 into account, so it uses caps & diodes to de-glitch. But deglitching will work only if timings are same like on NES. Kazzo probably does not respect them and thats why the register writes are not properly decoded.

Author:  MLX [ Thu Sep 07, 2017 3:59 am ]
Post subject:  Re: iNES Mapper 81

zeroone wrote:
I assume this is some unlicensed game then? Is the owner willing to sell?


He's not willing.

Author:  krzysiobal [ Thu Sep 07, 2017 5:02 am ]
Post subject:  Re: iNES Mapper 81

I would say it uses D6-D3

Image Image Image

Author:  NewRisingSun [ Thu Sep 07, 2017 9:18 am ]
Post subject:  Re: iNES Mapper 81

Doesn't correspond to what the game writes, and what the Kazzo dumping script produces. If I understand your PNG file correctly, I basically would need to emulate
Code:
void   MAPINT   Write8000 (int Bank, int Addr, int Val) {
   CHR = (Val >>3) &3;
   PRG = (Val >>5) &3;
   Sync();
}
which does not work and cannot possibly be right: during the first game level, the game writes $01 to $FFE1 and $10 to $6000 to select the 8K bank number 1. Your schematic would indicate that the CHR ROM chip U2 takes $8000.3 and $8000.4 as A13 and A14, which would be zero rather than one with this game's write sequence. It cannot be zero since the title screen is already at bank zero ($00 written to both $FFE0 and $6000) and needs a different CHR bank.
krzysiobal wrote:
so it uses caps & diodes to de-glitch.
What's "deglitching"?

Author:  lidnariq [ Thu Sep 07, 2017 12:51 pm ]
Post subject:  Re: iNES Mapper 81

One thing that is concerning is that I do only see one latch, not two; with only one latch clock input there can't be two disjoint registers.

To decode the memory region from $6000-$7FFF requires hardware that isn't present — there's only a 74'32, a 74'161, and that KC5373 appears to be a charge pump ( = CIC stunner).

Given the values that are written, the functionality should be Mask: $8000 ; $8000 - [.... PPCC] ; bus conflicts.

Author:  NewRisingSun [ Thu Sep 07, 2017 12:55 pm ]
Post subject:  Re: iNES Mapper 81

But then the CNROM Kazzo script should at least dump the 32K CHR-ROM, which it doesn't. (Although I'm not quite sure I understand the "deglitching" part --- does CNROM need no deglitching and this one does?)

Author:  lidnariq [ Thu Sep 07, 2017 12:59 pm ]
Post subject:  Re: iNES Mapper 81

NewRisingSun wrote:
But then the CNROM Kazzo script should at least dump the 32K CHR-ROM, which it doesn't.
I understand, and yet, there is no physical way on this board for it to have two registers in two separate memory regions.

EVEN IF the two 74-series parts are total lies, are actually random ASICs with surprisingly persuasive incorrect markings, there's not enough pins on them to be able to fulfill your description of what the behavior is.

Quote:
(Although I'm not quite sure I understand the "deglitching" part --- does CNROM need no deglitching and this one does?)
The electrolytic capacitors (C1, C2, C5) are not there for deglitching. They're part of the CIC stunner.

(Deglitching is removing very brief incorrect digital values)

Author:  NewRisingSun [ Thu Sep 07, 2017 1:09 pm ]
Post subject:  Re: iNES Mapper 81

Looking again the Kazzo CNROM script, I wonder why line 23 doesn't always fail due to bus conflicts, since it just writes to $8000. My Kazzo script for this game writes to FFE0+i, which is what the game actually uses. Maybe that's the true reason why the CNROM script fails with this game, and it's really just $8000-$FFFF ....PPCC? I'm still waiting for krzysiobal for clarification of the D0...D3 instead of D3..D6 bits before I change the wiki article.

Of course, that still leaves open the question why the game writes to $6000 as well. I suppose it could be a kind of compatibility write for a different PCB; no other NTDEC game has those however.

Author:  tepples [ Thu Sep 07, 2017 1:23 pm ]
Post subject:  Re: iNES Mapper 81

If the ROM is hoarded, and the cartridge is not for sale, and no other copies of this game are known to exist, and no other games using the same mapper are known to exist, then the existence of games using mapper 81 is no more verifiable than someone's research project in his bedroom. So if no ROM dump is available to emulator developers, against what test ROM should emulator developers test their implementations of mapper 81? What am I missing?

Page 2 of 4 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/