nesdev.com

So a member over at Assembler recently scanned some docs.

http://www.assemblergames.com/forums/sh ... and-Konami

"All documents are in Japanese.
All documents are originally in faxed copy(faxed from Japan about 20 yrs ago).
There may be personal notes on these paper.They are developer's comments.I think it's better to keep them as is.
Part of these documents seems to be used in project of porting Famicom and FDS game to another platform.FDS docs is still in scanning.

Doc list:
Famicom APU and PPU
MMC 1
MMC 3
Konami VRC 2
Konami VRC 6"

Just figured I would share this here since this is the boards I think could make the most use of this information (assuming there are things that we don't all ready know)

One nifty thing: it tells us how the VRC2 Microwire EEPROM was supposed to have worked: Writes to $6000-$6FFF were latched, and the 3 least significant bits of the byte written were: &1- DataToEeprom &2-SK &4- CS. Reads of $6000-$6FFF should have returned the value DataFromEeprom as the least significant bit.

It's interesting to see what kind of documentation people had back then! The fact that some of these are handwritten is pretty amusing too.

In the PPU document there's a diagram showing how to wire a second PPU in slave mode, but I don't see anything explaining how its registers would be mapped... Oh well, it's still nice to see that.

It's awesome that these seem to be the original Ricoh documents on the CPU & PPU, dating back to 1982. No surprises in the PPU doc, except that the section and bit about sprite overflow is all crossed out. Does this indicate it doesn't work properly in the earliest PPU, or that it was meant to be removed altogether?

_________________
http://www.chrismcovell.com

資料の内容は詳細に書かれていて、どの解析文書にも勝る内容です。
M2 なんて言葉が公式にはなかったんですね。

しかし、このような完璧な資料を流出させてしまった人がどういうことになるかが心配です。

Now if someone would translate above message and the docs into English...

This is facinating !

Really, even though I of course don't understand most of it, it's really amazing to have these for historical and curiosity purposes. It's especially interesting at the bottom of page 6 where there is a correspondance table between notes and bits code for the length counter. Were Ricoh actually guessing that only 0.2 % of NES games would ever use this feature ?

PS : This should end the polemic about how the registers $2000, $2001, etc... should be named, too.

PPS : It's incredible, the infamous "undoccumented footer" lying at $fff0 in some games is finally doccumented in MMC1 page 10.
From what I understand with katakanas, it's basically this :
$ffe0 - $ffef : "Title area"
$fff0 -$fff1 : PRG checksum
$fff2 - $fff3 : CHR checksum
$fff4 : Casette "mechiri" size
$fff5 : Casette type ($04 would mean MMC1 ??), it was previously assumed this byte was for mirroring
$fff6 : ?? (assumed to be version)
$fff7 : ??
$fff8 : Maker code. Here in the example it's $07 which means Enix (surprising to say the least).
$fff9 : ?? check

I'm kinda sad this header format, so well documented here, went so much disrespected. If all games respected it, there would have been no need for iNES theoretically, and things would have been much better. Oh well.

PPPS : So, "MMC" actually means "Multi Memory controller" officially.

naruko, oh cmon, its dated 1982 ) These "secrets" doesn't matter for Yakuza today.

Asked a friend to translate the japanese message above:

The VRC6 documentation seems to only describe what we currently know as the "mirroring control register" at $B003 - apparently, it does quite a lot more than that. From what I can tell, the VRC6 has the ability to map either CHR ROM or CHR RAM (not sure if the chip has separate enables for the two) into the nametables, much like the Namco 163 mapper.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Maybe it does in Japan, but in USA it's Memory Management Controller according to the article "Why Game Paks Never Forget" in Nintendo Power #20 (March 1991). Perhaps it's like cassette vs. Game Pak.

Very interesting stuff. Also on pages 4 and 9 of the MMC1 doc it seems like the "official" way to initialize MMC1 indeed is "INC AddressInROM", which is not surprising given how many commercial games used this method.

I wonder what exactly it says about "PROM" below the init code on page 4?

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

Other interesting things:
* In the version of the 2A03 described here, pin 30 was instead part of a on-chip crystal driver for the CPU
* We now have official (awful) names for all the registers
* They initially were going to release the MMC3 in a 42-pin DIP or SOP (Probably the same as the MMC2?)

Now what should be done is someone add the official names of registers to the wiki too, together with the unofficial names mostly used today. Other things mentioned in there may also be figured out in the way that it could put in wiki, too, if they might be relevant.

_________________
.

The official APU registers names are WRA0, WRA1, WRA2, WRA3, WRB0, WRB1 … WRE3, WRF0, RDST/WRST, RDP0/WRP0, RDP1/SoftCLK
I think that's worse than using the numbers.
The official PPU register names are CTLR0, CTLR1, SR, OAM.AR, OAM, SCC, VRAM.AR, and VRAM
I don't know how many assemblers support periods in the middle of symbols.