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?
資料の内容は詳細に書かれていて、どの解析文書にも勝る内容です。
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:
Quote:
He's talking about the content of the material that is written in detail, and it's better than any other analysis document.
But there seems to be no official term for M2
And he also says he is worried of what will become of that perfect material when other people will leak it.
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.
Bregalad wrote:
So, "MMC" actually means "Multi Memory controller" officially.
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?
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.
zzo38 wrote:
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.
Not so sure how wise that'd be. I'm not a lawyer, but I'd guess propagating names that came straight from leaked confidential docs might threaten the legitimacy of NES homebrew.
I seriously doubt anyone cares. It's not like homebrew has been based entirely on those documents that only leaked 30 years after their original intent (longer than the expiration time of a patent).
But yes those names are terrible, just like the ones that tepples made which are IMO pretty bad but still better than Rico's.
I'd still vote for adding them in addition to the register name and the names tepples made. That was, all the info is here, and anyone is free to use them as they want.
Someone with knownledge of japanese should definitely upload the "optional header" page with all the info from those documents. It's very interesting stuff I think.
Quote:
I seriously doubt anyone cares.
Maybe I did overreact. Back when I was active on gbadev.org, I seem to remember there being a big no-no against even mentioning leaked official docs. Perhaps the difference is that I was writing homebrew for GBA while the system was still manufactured.
Quote:
30 years after their original intent (longer than the expiration time of a patent).
Copyrights on the documents in question last longer than patents. Look at some of koitsu's recent locks of topics in SNESdev when That One Manual gets brought up.
I'm still interested in seeing That One NES manual in English, though only as a historical artifact, just to see what the old devs had to work with in those days. :-)
doppelganger wrote:
I'm still interested in seeing That One NES manual in English, though only as a historical artifact, just to see what the old devs had to work with in those days.
I don't believe an english NES manual exists. I'm pretty sure developers outside of japan had only the Japanese manual if any at all.
I remember developers saying they had poorly translated versions of the Japanese docs.
It is cool to see the header (or footer rather) documented. We talked about this a long time ago here
http://forums.no-intro.org/viewtopic.php?f=2&t=445 (which is surprisingly close). With these docs, we fill in some more blanks
Code:
FFE0-FFFFh: Game Title. 16 bytes max. ASCII codes 20h-5Ah allowed. Supposed to be right-justified.
FFF0-FFF1h: PRG checksum (last bank - 2 checksum bytes). NROM & CNROM, is the whole PRG. GNROM is last 32KB. UNROM & MMC is last 16KB.
FFF2-FFF3h: CHR checksum. 00h if RAM
FFF4h: Data sizes. Values: 0 = 8KB,1 = 16KB,2 = 32KB,3 = 128KB,4 = 256KB,5 = 512KB (No love for 64KB I guess)
D7-D4: PRG size
D3: 0 = CHR ROM, 1 = CHR RAM
D2-D0: CHR size
FFF5h: Board Type.
D7: 0 = H Scroll, 1 = V Scroll (invert to interpret as mirroring)
D6-D0: 0 = NROM
1 = CNROM
2 = UNROM
3 = GNROM
4 = MMC (any)
FFF6h: Version? Should start at 1
FFF7h: Valid Title Length - 1. 0 if no title entered.
FFF8h: Maker Code. 1 = Nintendo, 2-254 = everyone else. 255 must be reserved.
FFF9h: Header Validation Byte. 8-bit checksum of FFF2-FFF9h should = 0.
The footer requirement was not obviously well-enforced, as there are all sorts of games which are "non-compliant" in this manner. I clearly see many Konami games which fill the region with $ff.
Yeah the footer only shows up in maybe 1/4 of the games out there, and often enough even if it is present, the data is incorrect in some manner.
BootGod wrote:
Code:
D7: 0 = H Scroll, 1 = V Scroll (invert to interpret as mirroring)
"H Scroll" and "V Scroll" are very poor names to describe name table layout, because games can have any kind of scrolling with any kind of name table layout (different combinations will result in different kinds of artifacts at the edges of the screen, but all types of scrolling are always possible).
tokumaru wrote:
BootGod wrote:
Code:
D7: 0 = H Scroll, 1 = V Scroll (invert to interpret as mirroring)
"H Scroll" and "V Scroll" are very poor names to describe name table layout, because games can have any kind of scrolling with any kind of name table layout (different combinations will result in different kinds of artifacts at the edges of the screen, but all types of scrolling are always possible).
Not my wording, that was straight from the docs. Nintendo always seems to use the "scrolling" convention rather than mirroring. The H/V pads on their boards are the same story.
BootGod wrote:
Not my wording
I didn't say it was.
Quote:
Nintendo always seems to use the "scrolling" convention rather than mirroring.
I'm totally fine with the convention, and I do think it's better than the "mirroring" convention, what I'm arguing is that the type of scroll a game uses is not directly related to the way name tables are mapped in the PPU's addressing space (will a game that scrolls both horizontally and vertically have both solder pads on the cart soldered? certainly no), so "scroll" is a bad word to define mapping.
Quote:
The H/V pads on their boards are the same story.
They don't use the word "scroll" on the boards though, so that's fine.
I know I may be sounding somewhat grumpy, but the only reason I'm saying this is that as a programmer who knows that there are several different solutions for each programming problem, I find it bad to imply that a particular solution is mandatory for a particular problem. I don't want newbies to think they absolutely must use one type of name table mirroring/arrangement to scroll in a specific way, I want them to know that there are other things to consider.
I think it's OK to document Nintendo's wording for preservation reasons, but I don't think it should be used in new documents or Wiki pages if it may give people the wrong idea.
The
mirroring page already mentions "horizontal arrangement" as a synonym for vertical mirroring and vice versa.
On CPU/PPU pages 1 and 4, I notice that pin 30 is merely called X_OUT and described alongside X_IN (pin 29, previously named CLK). No mention of test registers either. I wonder if the early CPU versions that don't have periodic noise also lack the test registers.
It might differ between the early 2A03 and revision G.
I have to admit that as a newbie, the term "mirroring" has always confused me to no end. I don't say that the term "scrolling" makes me any wiser though.
Does the "arrangement" nomenclature click better with you?
Code:
,-------+-------.
| | |
| A | B | Horizontal arrangement
| | | Vertical mirroring
`-------+-------'
: : :
: A : B :
: : :
` - - - + - - - '
,-------. - - - .
| | :
| A | A : Vertical arrangement
| | : Horizontal mirroring
+-------+ - - - +
| | :
| B | B :
| | :
`-------' - - - '
A and B are distinct nametables
Dotted lines surround repeated nametables
Maybe if you specifically say "nametable arrangement". Though the term "nametable" was a bit confusing too at first. lol
Pokun wrote:
Though the term "nametable" was a bit confusing too at first.
I'm not sure whether this term was invented by people who reverse engineered the NES or if it was taken from official documentation, but in other platforms I'm familiar with, the term "tile map" is often used to describe their equivalent of the name tables. The NES is different from most other platforms though, because it keeps the tile attributes separate from the tile map, so maybe that's the reason for the different naming convention?
I agree that "name" is a confusing word to use here though, since nothing is actually named, unless you consider that the index of each tile is also its name, but even then the name table isn't really naming anything, it's just "calling" the tiles by their "names". Problem is that these terms have been used for so long that changing them at this point would do more bad than good, creating even more confusion instead of preventing it!
tokumaru wrote:
I'm not sure whether this term was invented by people who reverse engineered the NES or if it was taken from official documentation
The term "name table" is used in Nintendo's English-language patents, for example, in U.S. patent #4,824,106. The same patents also refer to sprites as "motion pictures".
NewRisingSun wrote:
The same patents also refer to sprites as "motion pictures".
Now that's weird, considering how widely used (to refer to something else) this term is!
It seems like the Commodore manuals had a funny name for sprites as well. I'm not at my desk at the moment though so I couldn't look it up. It was something similar to motion picture though.
The TMS9918 datasheet refers to a "name table base address" for the tilemap and a "sprite attribute table" that appears to correspond to OAM.
The Intellivision documentation I read recently called sprites "MOBs" (movable objects). The term "sprite" is relatively recent I guess.
tepples wrote:
The TMS9918 datasheet refers to a "name table base address"
Then maybe that's where the NES term came from, since all research suggests that the 9918 was a big inspiration for the NES PPU.
They are called "sprites" on the commodore 64.
However the french translation translated them literally (referencing the fantasy creature) instead of simply calling them "sprites" which sound REALLY weird.
tokumaru wrote:
The Intellivision documentation I read recently called sprites "MOBs" (movable objects). The term "sprite" is relatively recent I guess.
tepples wrote:
The TMS9918 datasheet refers to a "name table base address"
Then maybe that's where the NES term came from, since all research suggests that the 9918 was a big inspiration for the NES PPU.
The same terminology (Name Table Base Address) is used in the official SNES developers documentation, I should point out.
Bregalad wrote:
They are called "sprites" on the commodore 64.
Both the C64 User's Guide bundled with the system, and the Programmer's Reference Guide, actually use both "sprites" and "MOBs". It even contains two different sets of register names for the VIC-II. For example, in a basic register map, VIC register $00 labels the bits as S0X7-S0X0 (Sprite 0 X position bits 7-0), while the more in-depth VIC-II appendix lists the same register as M0X7-M0X0. The sprite nomenclature made for funny register names - the registers for X and Y expansion of sprites is labeled SEXX7-SEXX0 and SEXY7-SEXY0, while the "MOB version" is a dull M7XE-M0XE and M7YE-M0YE.
Sure, a port called SEXY1 wasn't likely to look good to management. (See the fate of
sign extend mnemonics.) But I wonder if Coca-Cola made legal threats against the use of "sprite" in second- and third-generation VDPs' manuals.
Sprite Zero: Might as well be the official caffeine-free, sugar-free soft drink of NESdev
Bregalad wrote:
They are called "sprites" on the commodore 64.
You are correct. I'm back at my desk and verified that. Not sure what I was remembering there
I remade the diagrams in the
mirroring article to make the arrangement aspect clearer. Above I distinguished the "primary" addresses of the two nametables from their mirrors with dotted lines around the mirrors. In the PNG versions, the mirrors are drawn faded.
A vertical arrangement of the nametables results in horizontal mirroring
Shouldn't $2C00-$2FFF be the original for NT b, since its location never changes? $2800-$2BFF and $2400-$27FF are the NTs that change depending on mirroring bits.
Pokun wrote:
I have to admit that as a newbie, the term "mirroring" has always confused me to no end. I don't say that the term "scrolling" makes me any wiser though.
When you see "mirroring", think mapping from addresses to nametable locations. At the conceptual level you have four screens arranged in a square, with $2000-$23FF being top-left, $2400-$27FF top-right, $2800-2BFF bottom-left, and $2C00-$2FFF bottom-right. What scrolling does is place a viewport the size of the screen within this square. What mirroring finally does is to determine how the addresses that fall within that viewport map to nametable locations. Without extra nametable memory in the cart you always need some kind of non-linear mirroring, as there are twice as many address locations as there is nametable memory (CIRAM).
Just in case the above was a confusing way to put it, the mapping (mirroring mode) assigns a nametable location to each address within the four-screen square. The viewport in turn selects some portion of the square, and the way the addresses within that portion are mapped determines what gets drawn.
Even though it's pitched towards emulator authors, I think you really need to read through the
The skinny on NES scrolling page to understand how all the addressing stuff works out when the PPU draws the background.
Edit: Square/rectangle/whatever... should be clear enough.
ccovell wrote:
Shouldn't $2C00-$2FFF be the original for NT b, since its location never changes? $2800-$2BFF and $2400-$27FF are the NTs that change depending on mirroring bits.
Or $2400-$2BFF never changes, and $2000-$23FF and $2C00-$2FFF are mirrors. Some of my early init code cleared this $2400-$2BFF range. (Nowadays I have it clear $3C0 bytes to one value and $40 bytes to another in a subroutine.) But the goal of the diagram was to connect mirroring to the arrangement terminology that the "H Scroll" stuff implies. Besides, what you say isn't true of diagonal mirroring.
The hotfile.com is gone.
Could someone
update the wiki page with new (?) links?
... Oh, right, hotfile.com was shut down.
ulfalizer wrote:
Pokun wrote:
I have to admit that as a newbie, the term "mirroring" has always confused me to no end. I don't say that the term "scrolling" makes me any wiser though.
When you see "mirroring", think mapping from addresses to nametable locations. At the conceptual level you have four screens arranged in a square, with $2000-$23FF being top-left, $2400-$27FF top-right, $2800-2BFF bottom-left, and $2C00-$2FFF bottom-right. What scrolling does is place a viewport the size of the screen within this square. What mirroring finally does is to determine how the addresses that fall within that viewport map to nametable locations. Without extra nametable memory in the cart you always need some kind of non-linear mirroring, as there are twice as many address locations as there is nametable memory (CIRAM).
Just in case the above was a confusing way to put it, the mapping (mirroring mode) assigns a nametable location to each address within the four-screen square. The viewport in turn selects some portion of the square, and the way the addresses within that portion are mapped determines what gets drawn.
Even though it's pitched towards emulator authors, I think you really need to read through the
The skinny on NES scrolling page to understand how all the addressing stuff works out when the PPU draws the background.
Edit: Square/rectangle/whatever... should be clear enough.
Thanks. I think I understand the basics about mirroring now. Gonna read through "The skinny on NES scrolling" sometime.
If you do, I recommend this revised version of it on the wiki, rather than the old txt document:
http://wiki.nesdev.com/w/index.php/The_skinny_on_NES_scrolling(Not trying to downplay Loopy's great work in documenting this stuff, but I'd like to think that with multiple authors on the wiki we've made a lot of improvement to understandability here.)
"The skinny on NES scrolling" isn't directly related to mirroring, and since you're still learning the basics, it might actually confuse you. I suggest you put reading "the skinny" on hold until you need to work with mid-screen scroll changes.
Zepper wrote:
The hotfile.com is gone.
Could someone
update the wiki page with new (?) links?
Yeah, can someone repost these? I'd love to see them.
Thanks!
These links will expire. I'm not sure if I can just upload these as an attachment instead.
http://www.sendspace.com/filegroup/v8gG ... INnSzASsKwI thought of giving a translation of these a try, but the print is so bad that I couldn't even finish the first page for MMC1. I couldn't see some kanji or find them in any dictionary.
tokumaru wrote:
"The skinny on NES scrolling" isn't directly related to mirroring, and since you're still learning the basics, it might actually confuse you. I suggest you put reading "the skinny" on hold until you need to work with mid-screen scroll changes.
I see. I haven't tried to do any scrolling at all yet. I'm currently studying the APU using Metal Slime's Nerdy Nights guide.
Pokun wrote:
These links will expire. I'm not sure if I can just upload these as an attachment instead.
http://www.sendspace.com/filegroup/v8gG ... INnSzASsKwI thought of giving a translation of these a try, but the print is so bad that I couldn't even finish the first page for MMC1. I couldn't see some kanji or find them in any dictionary.
Thanks, I got them. Yeah, looks like they were scanned with really high contrast / black and white (as opposed to greyscale). Appreciate it!
Pokun wrote:
I thought of giving a translation of these a try, but the print is so bad that I couldn't even finish the first page for MMC1. I couldn't see some kanji or find them in any dictionary.
These pdfs are reconstructions I made from SONIC3D's scans. I've done all the MMC1 docs but some I haven't yet formated.
mmc1_pinout_(Japan)_(1986-08-23).pdf (revised)
mmc1_cassette_(Japan)_(1986-11-18).pdf (revised)
mmc1_notice_(Japan)_(1989-06-15).pdf (revised)
game_cassette_registration_(Japan)_(1987-02-10).pdfmmc1_multi-checker_(Japan).pdf
オーストラリアの人が文書を作り直すとは驚きました。間違いを見つけました。
mmc1_pinout_(Japan)_(1986_08_23).pdf
誤: 23 | φ2 | CPU クロツク
正: 23 | φ2 | CPU クロック
間違っていても大丈夫
mmc1_cassette_(Japan)_(1986-11-18).pdf
page1 の冒頭
誤: ROMカセットに対応しがっ、
正: ROMカセットに対応しかつ、
これは変と感じます。 「かつ」means "and",普段使わない言葉です。
mmc1_notice_(Japan)_(1986_06_15).pdf
末尾の辺り
拡張のCSに接続されているのでの CS の上にラインが必要 (負論理記号が必要)
Overloadさん、Narukoさん、手伝ってありがとうございました!
今ならぼくたちはこの文書を翻訳できるはずです!Overloadさんは多分、光学文字認識で文書を作り直しましたから、
こんなに間違いになったでしょう。
I guess Overload used some kind of OCR method to reconstruct the documents?
That would explain those weird mistakes anyway.
Thanks a lot anyway! I started to translate the first page:
NES_MMC1_0001.jpg
Code:
0001
MMC Cartridge Programming Specifications
Draw up date 1986-11-18
Revision date 1987-3-26
This memory controller MMC (Multi Memory Controller) for Family Computer has been developed at Nintendo.
From now on it supports ROM cartridges that are expected at a larger and larger scale, and it is also
designed to bring about much more flexibility for program development.
--- Merits of MMC ---
1. Possibility to expand memory space ... Program 2M / RAM 64Kx2 / Character 1M
2. Bank settings details .... Program 16K units, possibility to change permanent settings / Character 4K units
3. Possibility to support battery backup ... Lithium batteries guaranteed to last 5 years, 64K RAM
4. V-RAM control ..... H-V settings / 1 screen scrolling
5. Effective copy protection ..... Since it is a custom IO it is difficult to replace it with another gate type.
Nintendo Co., Ltd.
I'm not sure about the terms. Maybe port is better than gate in that last sentence? Also that line about ROM cartridges may be needed to be redone.
僕はおそらくたくさん間違いしますから、ご遠慮なく直してください。
Everyone are welcome to contribute with corrections, translations, suggestions, criticism, image editing and so on.
Good stuff, would love to see it all translated someday.
Gate sounds like the best choice, port wouldn't make as much sense in that sentence.
Thanks for the corrections Naruko.
I have uploaded new versions, see my previous post for the links.
I used about 5 different OCR programs, a Japanese dictionary and my brain
Pokun, I think your dates are incorrect? I have 1986-11-18 and 1987-03-26.
Oh I can only say god job!!
You are right I made a mistake about the dates, it should be correct now.
I started translating the pinout now and there's a date there too that's really hard to read. It looks like 1988 to me but it says 86 in the reconstructed document.
Infiniteneslives thanks! I'll probably need a lot of help with technical terms from now on. It's a good thing that this forum is full of technical wizards.
Pokun wrote:
I started translating the pinout now and there's a date there too that's really hard to read. It looks like 1988 to me but it says 86 in the reconstructed document.
It look's like an eight but I believe it's a six. Obviously detail has been lost when the document was faxed. If you look at PRA16 you'll see what I mean. Chronologically it makes sense the pinout be available before any register specifications.
I see what you mean and I agree that it looks more like a 6.
TN = Translator's Note
NES_MMC1_0019.jpg
Code:
Multi Memory Controller specification document, 1986.8.23 revision
--- Pinout ---
Package: 300mil shrink DIP
TN: pinout diagram here
Pin no. | Pin name | Function | I/O
TN: From here on only the Function and I/O columns are translated (since the others doesn't need a translation).
For program ROM bank switching use, program ROM address | Output
For expansion RAM bank switching use, RAM address / program ROM bank switching use, program ROM address | Output
Output only when in read mode, ROMSEL | Output
For RAM expansion use, addresses 6000~7FFFH, decode signal | Output
For character ROM bank switching use, character ROM address | Output
Ground pin | -
PPU addresses 10~12 | Input
For Scroll switching use, Video RAM address 10 | Output
CPU READ/WRITE signal | Input
Serial Data input | Input
Serial Data Clear input | Input
For program ROM use, addresses 8000~FFFFH, decode signal | Input
CPU addresses 13, 14 | Input
CPU clock | Input
Power pin | -
* Pins that needs a pull-up resistor.
I'm very busy nowadays and my usual one page per day is totally impossible at the moment.
NES_MMC1_0021.jpg
Code:
TN: The upper half of this paper is identical to "NES_MMC1_0001.jpg" including the draw-up date. The only difference is that it doesn't have the revision date.
MMC cartridge repertory
Type | Program memory | Character memory | Notes
TN: Type I row's Note column reads:
Battery backup possibility
TN: Type VI row's Note column reads:
Program development board
* Any other combinations than the above ones will be discussed.
Nintendo Co., Ltd.
Has anyone re-hosted these docs yet? hotfile has been dead for a year now.
I see PDFs posted here of the MMC1 docs (all of them or just some? not sure), but still missing:
PPU+CPU
MMC3
VRC2
VRC6
LN
I have these archived "somewhere". *ahem* :P I'm not sure anyone dares make public links to them or make them publicly available given that the content is heavily copyright.
BTW I'm sorry to say that all my translations work are on hold. My files are on a computer that won't boot and I don't have time to fix it at he moment. I do intend to finish what I start though, eventually.
I can probably have the documents translated by my neighbour if needed (since he does English/Japanese technical documentation), but given the number of scans and text involved, I'm fairly certain I'd have to pay him.
For those who have the archive(s): if there is a particular page or section you want translated, let me know (filename, etc.) and he can probably do that for free / without much effort.
Minor follow-up:
1. I showed the documents in question to my neighbour, and he agrees that the quantity/amount of data would take him too long to do (esp. for free), but absolutely has no problem providing translations for things people aren't sure about or want translated. As previous: just give me the filename + description (or send me a PM with a screenshot of the section you want translated) and I can have it done within a few hours.
That said: he was able to read almost all of the text (incl. the handwritten stuff), and that which he cannot figure out his (Japanese) wife can help with recognising. :-) He may also have to sit down with me to get some context (i.e. me opening up our wiki and correlating things, or explaining certain concepts/tech things to him. He works with low-level IC documentation all day so he understands things like registers and MMIO and what not, but things like audio and video are a more tricky, which is where I can shed some light).
2. He also reviewed the PDFs someone did (using OCR). He agreed that OCR for some of the documents is not a good idea (for some it might be okay, because they're typed/printed, while others (ex. CPU/APU/PPU doc) would be bad because they're hand-written).
3. The CPU/APU/PPU doc is officially from Ricoh, and very clearly has a stamp on every page in the upper right corner which reads "CONFIDENTIAL". In other words: this stuff is definitely intellectual property, therefore please be careful with it.
4. The VRC2 doc that has a page covered in random scribbles -- the scribbling/handwritten notes appears to be in English (or at least mostly), which is further supported by the fact that the first picture has "mapper 23" written in English on it (same handwriting). This really isn't important, but I do find it kind of interesting (makes you wonder who had it).
I feel it's worth mentioning that because the VRC2 and MMC3 documents are typeset, I've had no difficulty getting the android version of Google Translate to give me mostly-understandable OCR results.
BootGod wrote:
It is cool to see the header (or footer rather) documented. We talked about this a long time ago here
http://forums.no-intro.org/viewtopic.php?f=2&t=445 (which is surprisingly close). With these docs, we fill in some more blanks
Code:
FFE0-FFFFh: Game Title. 16 bytes max. ASCII codes 20h-5Ah allowed. Supposed to be right-justified.
FFF0-FFF1h: PRG checksum (last bank - 2 checksum bytes). NROM & CNROM, is the whole PRG. GNROM is last 32KB. UNROM & MMC is last 16KB.
FFF2-FFF3h: CHR checksum. 00h if RAM
FFF4h: Data sizes. Values: 0 = 8KB,1 = 16KB,2 = 32KB,3 = 128KB,4 = 256KB,5 = 512KB (No love for 64KB I guess)
D7-D4: PRG size
D3: 0 = CHR ROM, 1 = CHR RAM
D2-D0: CHR size
FFF5h: Board Type.
D7: 0 = H Scroll, 1 = V Scroll (invert to interpret as mirroring)
D6-D0: 0 = NROM
1 = CNROM
2 = UNROM
3 = GNROM
4 = MMC (any)
FFF6h: Version? Should start at 1
FFF7h: Valid Title Length - 1. 0 if no title entered.
FFF8h: Maker Code. 1 = Nintendo, 2-254 = everyone else. 255 must be reserved.
FFF9h: Header Validation Byte. 8-bit checksum of FFF2-FFF9h should = 0.
FFE0h Game Title
FFF0h Program Checksum
FFF2h Character Checksum
FFF4h Memory Size
FFF5h Cassette Type
FFF6h is not version, it's "Registration Character Type Distinguishation (Is That a Word?)".
Normally alphanumeric characters. Refer to table 1 about Registration Character Code.
0 = title is not registered
0 ≠ registered
Alphanumeric: 1, Other: 2~FFh
Table 1 is the one with the allowed ASCII characters.
FFF7h Number of Registration Characters
0 = title is not registered
0 ≠ registered
If it's registered it will be [number of characters]-1 (max 16 byte)
FFF9h Complement Check
The wiki needs to be updated too.
Pokun wrote:
FFF6h is not version, it's "Registration Character Type Distinguishation (Is That a Word?)".
Normally alphanumeric characters. Refer to table 1 about Registration Character Code.
0 = title is not registered
0 ≠ registered
Alphanumeric: 1, Other: 2~FFh
Table 1 is the one with the allowed ASCII characters.
Registration Character Type
Distinction.
The rest of the description you wrote is very difficult to understand. I should probably get my neighbour to help, as he does JP<->EN technical documentation translation as part of his job. I'll ask him this coming weekend.
Ah distinction, thanks.
Well I guess I translated it too literary. Maybe alphanumeric could be interpreted as ASCII in this case? What I think they mean here is:
0 = Unregistered
1 = Title uses ASCII encoding (refer to the ASCII table for allowed characters)
2~FFh = Title uses other encoding
Normally 1 is used.
Or what else could "Registration Character" refer to if not the Game Title? FFF7h seems to indicate this too (since it's max 16 byte). It should probably be Registration Characters (plural) btw.
On the Ball is SNS-CT-USA (for Cameltry, its Japanese title). Later games had a 4-character code: Pinocchio is SNS-ACGE-USA. It turns out that these codes are reused from one platform to the next: AGB-ADME-USA is Doom for Game Boy Advance but NTR-ADME-USA is Animal Crossing: Wild World for Nintendo DS. (Reuse of a code associated with a game that popularized first-person view only increased my disappointment when I learned that neither Wild World for DS nor Animal Crossing: City Folk for Wii had a first-person view. But I [url=http://lawstreetmedia.com/blogs/think-twice-before-spray-painting-your-lawn-green-california/]dye grass[/urll].) These codes appear in the header of GBA and DS games and reportedly in the extended header of Super NES games. Does "registration" on Super NES have anything to do with these codes?
Quote:
But I ...(broken link)
What was that supposed to be?
tepples wrote:
On the Ball is SNS-CT-USA (for Cameltry, its Japanese title). Later games had a 4-character code: Pinocchio is SNS-ACGE-USA. It turns out that these codes are reused from one platform to the next: AGB-ADME-USA is Doom for Game Boy Advance but NTR-ADME-USA is Animal Crossing: Wild World for Nintendo DS. (Reuse of a code associated with a game that popularized first-person view only increased my disappointment when I learned that neither Wild World for DS nor Animal Crossing: City Folk for Wii had a first-person view. But I [url=http://lawstreetmedia.com/blogs/think-twice-before-spray-painting-your-lawn-green-california/]dye grass[/urll].) These codes appear in the header of GBA and DS games and reportedly in the extended header of Super NES games. Does "registration" on Super NES have anything to do with these codes?
I don't understand the question, what do you mean by "registration"? The Game Code (whether 2 or 4 characters) is used in the new extended SNES header as you said. Anyway I don't think the "Registration Characters" in Famicom headers have anything to do with the 2-/4-characters Game Code, it's just another word for the Game Title (unless the Game Code is supposed to be included in the 16 byte Game Title).
How the heck would you play Animal Crossing in first person mode? lol
Pokun wrote:
How the heck would you play Animal Crossing in first person mode?
Probably not unlike a town in
Skyrim.
Skyrim huh, haven't played that one. I can't see how first person-view would useful in anything else than FPS games and old fashioned dungeon crawling like Wizardry though.
I've handed the documentation off to my neighbour, re: getting good definitions of $FFF6 and $FFF7, including the existing translations (thanks for both, Pokun!). We'll see what he says or comes up with.
Yeah well the more that looks into it the better. I'd like if we'd come up with a better term than "Registration Characters" anyway. You could also rephrase the whole sentence and avoid having to translate that word (something you often have to do that when translating Japanese), but it's hard in this case since we have to call it something.
BTW I looked up 英数字 (literary: English Number Letter) and while it means alphanumeric, 英数 also can mean ASCII encoding according to the dictionary.
My translations is a bit literal, but I think it's hard to understand mainly because it's hard to understand to begin with in Japanese. The second translation is not really a translation, I just totally rewrote it in an easier to understand language (using a ≠ is just confusing IMHO).
I sometimes think Nintendo makes their documents hard to read on purpose to sort out less serious developers or something.
Pokun wrote:
I'd like if we'd come up with a better term than "Registration Characters" anyway.
ゲームカセット登録仕様 = Game Cartridge Description Specification
登録エリア = Storage Area
タイトル登録エリア = Title Storage Area
登録文字数 = Number of Stored Characters
登録文字タイプ識別 = Encoding of Stored Characters
Does this sound right?
So you want to translate 登録 (registration) to "storage"? I suppose it could be translated to "data entry" or something like that.
"Data entry" is pretty much exactly what it means in this usage. I chose "storage" because it makes the descriptions more intuitive in my opinion.
Decided to give it a try myself since I keep seeing people nitpicking how the fields are translated (I've decided to not translate the names exactly and instead go by the descriptions of the fields). I know I'm probably repeating nearly everything said so far but whatever. I hope I didn't miss anything.
- $FFF9: header checksum
- $FFF8: developer code
- $FFF7: game title length
- $FFF6: game title encoding
- $FFF5: mapper details
- Bits 6-0: mapper type
- Bit 7: nametable arrangement
- $FFF4: memory size
- Bits 2-0: CHR-ROM/RAM
- Bit 3: 0 = CHR-ROM, 1 = CHR-RAM
- Bits 7-4: PRG-ROM
- $FFF2: CHR-ROM checksum (2 bytes)
- $FFF0: PRG-ROM checksum (2 bytes)
- $FFE0: game title (16 bytes)
The header checksum is the checksum of the bytes from
$FFF2 to
$FFF8. Adding all the bytes and the one here should give 0 (after overflow).
The developer code (
$FFF8) is a number that identifies the developer (or most likely, the publisher). Nintendo has a developer code of 1, third parties got a code from 2 to 254 (I'll let you figure out what code represented each company). This is akin to
Sega's T codes.
The game title length is, as it says, how long is the title. 0 means no title, other value is the length in
bytes minus 1. How does it account for a length of 1 byte is beyond me, although later in the doc it seems to say that the title is required anyway.
The game title encoding indicates what format it has. 0 means no title, 1 means alphanumeric characters (a subset of ASCII which lacks lowercase and several symbols), 2 or larger means a different encoding scheme.
The possible mappers in
$FFF5 (at the time of that doc) are as follows:
- 0: NROM
- 1: CNROM
- 2: UNROM
- 3: GNROM
- 4: MMC (MMC1?)
The possible nametable arrangements in
$FFF5 are as follows (use 0 for cartridges where this is programmable):
- 0: horizontal arrangement (aka vertical mirroring)
- 1: vertical arrangement (aka horizontal mirroring)
The possible sizes (for either PRG or CHR) in
$FFF4 are as follows:
- 0: 64 Kbit (8KB)
- 1: 128 Kbit (16KB)
- 2: 256 Kbit (32KB)
- 3: 1 Mbit (128KB)
- 4: 2 Mbit (256KB)
Checksums for PRG and CHR are calculated from the last bank (whatever that means for the relevant mapper). As with the header checksum, they should add up to 0 after overflow.
The game title takes up the
most significant bytes of the field. What this means is that if the title is less than 16 bytes, you need to add padding at the beginning, not at the end. Somebody may be caught off guard by this one.
Some earlier findings about the reality of the header:
viewtopic.php?p=56964#p56964
Sik wrote:
The developer code ($FFF8) is a number that identifies the developer (or most likely, the publisher). Nintendo has a developer code of 1, third parties got a code from 2 to 254 (I'll let you figure out what code represented each company).
Do they by any chance match up with the codes for FDS publishers?
Code:
_C01 .db "Nintendo",0
_C08 .db "Capcom",0
_C0A .db "Jaleco",0
_C18 .db "Hudson Soft",0
_C49 .db "IREM",0
_C4A .db "Gakken",0
_C99 .db "Pack-In Video",0
_C9C .db "Imagineer",0
_CA2 .db "Scorpion Soft",0
_CA4 .db "Konami",0
_CA7 .db "Takara",0
_CAC .db "(?)",0
_CB1 .db "ASCII / SEDIC",0
_CB2 .db "BANDAI",0
_CB3 .db "Soft-Pro",0
_CB6 .db "HAL",0
_CBB .db "Sunsoft",0
_CC0 .db "Taito",0
_CC1 .db "Sunsoft-Ask Kodansha",0
_CC2 .db "Kemco",0
_CC3 .db "Square / DOG",0
_CC4 .db "Tokuma Shoten Int.",0
_CC5 .db "Data East (DECO)",0
_CC6 .db "Tokyo Shoseki",0
_CC7 .db "East Cube",0
_CCA .db "Konami (2)",0
_CCB .db "VAP",0
_CCC .db "System Sacom / USE",0
_CCE .db "Pony Canyon",0
_CD1 .db "SOFEL",0
_CD2 .db "Bothtec",0
ccovell wrote:
Do they by any chance match up with the codes for FDS publishers?
Looks like it. I checked a few games:
The Goonies II: $A4 (Konami)
Duck Tales 2: $08 (Capcom)
Is there any correlation between A4 vs. CA and "Konami" vs. "Ultra"/"Palcom" branding?
Correcting self after thinking some more:
Sik wrote:
The game title length is, as it says, how long is the title. 0 means no title, other value is the length in bytes minus 1. How does it account for a length of 1 byte is beyond me, although later in the doc it seems to say that the title is required anyway.
When the encoding is 0 it means no title, so that most likely would distinguish between both situations. Oh well. (there's still a contradiction as later in the doc it talks as if the title was required anyway, I should probably recheck to be sure)
I didn't bother with the developer codes because that'd require checking just about every game and I'm not going to do that, I'll leave that to you. Same deal with the mapper codes (you'd need to look for the values of any mappers beyond those five)
Sounds like the Maker Codes are the same codes as for FDS, Gameboy and SNES etc.
Joe wrote:
"Data entry" is pretty much exactly what it means in this usage. I chose "storage" because it makes the descriptions more intuitive in my opinion.
I see, I guess storage is a good translation then.
I'm not sure where I got "Game Title" from?
Well, that's how I translated it because in a tech doc written in English that's how the field would actually be described. タイトル means "title" as in the name of a work, and that's the word used here. Writing it as "game title" helps making it more clear. I suppose that if you still insist on a more literal translation of what the doc says, "title field" may be closer to the original meaning.
EDIT: and just to make it clear, "storage" there is essentially "this is the field where you store this information". So yes, it really should be translated as "field".
The good old
formal equivalence vs. dynamic equivalence debate. The way NIV and NET Bible resolve it is by translating the main text with dynamic equivalence (that is, the way you'd explain it in an English doc), with the "more literal translation" given in a footnote.
Okay, so here's the feedback from my neighbour for $FFF6 and $FFF7:
Code:
$FFF7: game title length
A value of $00 indicates the game title (i.e. $FFE0 to $FFEF) is unregistered
A non-zero value indicates the game title is registered and indicates the length of the game title - 1
$FFF6: game title encoding
A value of $00 indicates the game title (i.e. $FFE0 to $FFEF) is unregistered
A value of $01 indicates alphanumeric characters (more specifically, "English characters"; see below)
- The literal word used to describe this is "eimoji" which in this context is used to differentiate English vs. JIS vs. SJIS vs. EUC encodings
A value of $02 to $FF indicates "other encoding" (i.e. not English, so possibly JIS, SJIS, or EUC); no other details are provided
As for $FFE0 to $FFEF -- the game title must only allow ASCII characters $20 to $5A, excluding $40 (@ / at-symbol). This is what's referred to as "table 1" in previous posts.
There's a paragraph in the documentation that describes the allowed characters ($20-5A excluding $40) in a game title, but no mention or reference if that applies universally or just when $FFF6 was a value of $01. I asked my neighbour about that ("if you're limiting the characters allowed, why would values $02 to $FF be allowed in $FFF6?"). He believes strongly, given the contextual flow of the document and the phrasings used, that said requirement only applies in the case $FFF6 is $01. So it's not explicitly stated in the documentation, but he feels it's an oversight rather than a deliberate omission.
Finally, he wanted me to note that
Sik's definitions and descriptions are, contextually, the best he's read here. The "literal translations" aren't as helpful/accurate. The biggest confusion stems from the fact that most of the Japanese uses the word "registration" over and over, as if it's some kind of special thing -- I knew what this was about almost immediately: the word is used because Nintendo has you "register" a game with them (yeah, it's that simple -- they do the same thing in official SNES/SFC documentation).
koitsu wrote:
The biggest confusion stems from the fact that most of the Japanese uses the word "registration" over and over, as if it's some kind of special thing -- I knew what this was about almost immediately: the word is used because Nintendo has you "register" a game with them (yeah, it's that simple -- they do the same thing in official SNES/SFC documentation).
Which is where I got the mistaken idea that it was somehow related to game code. Sometimes the game code is issued based on a preliminary title (e.g. NES-VU-USA and DMG-VU-USA for "Virus" which was released as "Dr. Mario") or a foreign title (e.g. SNS-CT-USA for "Cameltry" which was released as "On the Ball" stateside).
Yeah the deal with the register thing may require prior knowledge about Nintendo's registration process.
My translation was MORE accurate but made less sense.
It was only to serve as a first draft anyway, in order not to get things lost in translation (and put attention back to this topic). Sik explained nicely why storage is the most logical translation of the word in this context.
koitsu wrote:
Okay, so here's the feedback from my neighbour for $FFF6 and $FFF7:
Code:
$FFF6: game title encoding
A value of $01 indicates alphanumeric characters (more specifically, "English characters"; see below)
- The literal word used to describe this is "eimoji" which in this context is used to differentiate English vs. JIS vs. SJIS vs. EUC encodings
A value of $02 to $FF indicates "other encoding" (i.e. not English, so possibly JIS, SJIS, or EUC); no other details are provided
As for $FFE0 to $FFEF -- the game title must only allow ASCII characters $20 to $5A, excluding $40 (@ / at-symbol). This is what's referred to as "table 1" in previous posts.
There's a paragraph in the documentation that describes the allowed characters ($20-5A excluding $40) in a game title, but no mention or reference if that applies universally or just when $FFF6 was a value of $01. I asked my neighbour about that ("if you're limiting the characters allowed, why would values $02 to $FF be allowed in $FFF6?"). He believes strongly, given the contextual flow of the document and the phrasings used, that said requirement only applies in the case $FFF6 is $01. So it's not explicitly stated in the documentation, but he feels it's an oversight rather than a deliberate omission.
But since the allowed symbols are so few, there wouldn't be any different if it used ASCII or JIS would there? The only difference is the yen symbol replaces the backslash, and tilde replaced by overline, but they are not allowed characters anyway. I guess they just mean "eimoji" = English (well we would say Roman/Arabic, although Ei literary refers to England) characters in ASCII/JIS encoding standard.
I suppose, giving the contextual flow of this and other Nintendo dev docs, that the rules for "other encoding", is simply not covered by this document, as it's a very special case. You'd have to make a deal with Nintendo on what value to put there and what characters to use if you really want to use another encoding for whatever reason. Or something like that.
More likely, values $02 to $FE were just reserved in case they decided to allow other encodings in the future (hence why that isn't explained, they simply hadn't done it at the time!).