I would like to update the cartridge connector page (
http://wiki.nesdev.com/w/index.php/Cartridge_connector) with signal directions. Here is my initial cut at it...
Code:
-------
+5V -- |36 72| -- GND
CIC toMB -> |35 71| -> CIC CLK
CIC toPak <- |34 70| -> CIC RST
CHR D3 <> |33 69| <> CHR D4
CHR D2 <> |32 68| <> CHR D5
CHR D1 <> |31 67| <> CHR D6
CHR D0 <> |30 66| <> CHR D7
CHR A0 <- |29 65| -> CHR A13
CHR A1 <- |28 64| -> CHR A12
CHR A2 <- |27 63| -> CHR A10
CHR A3 <- |26 62| -> CHR A11
CHR A4 <- |25 61| -> CHR A9
CHR A5 <- |24 60| -> CHR A8
CHR A6 <- |23 59| -> CHR A7
CIRAM A10 -> |22 58| -> CHR /A13
CHR /RD <- |21 57| <- CIRAM /CE
EXP 4 |20 56| -> CHR /WR
EXP 3 |19 55| EXP 5
EXP 2 |18 54| EXP 6
EXP 1 |17 53| EXP 7
EXP 0 |16 52| EXP 8
/IRQ -> |15 51| EXP 9
PRG R/W <- |14 50| -> PRG /CE (/A15 + /M2)
PRG A0 <- |13 49| <> PRG D0
PRG A1 <- |12 48| <> PRG D1
PRG A2 <- |11 47| <> PRG D2
PRG A3 <- |10 46| <> PRG D3
PRG A4 <- |09 45| <> PRG D4
PRG A5 <- |08 44| <> PRG D5
PRG A6 <- |07 43| <> PRG D6
PRG A7 <- |06 42| <> PRG D7
PRG A8 <- |05 41| -> PRG A14
PRG A9 <- |04 40| -> PRG A13
PRG A10 <- |03 39| -> PRG A12
PRG A11 <- |02 38| -> M2
GND -- |01 37| -> SYSTEM CLK
-------
CONN -> PIN NAME Output to cartridge
CONN <- PIN NAME Input from cartridge
Would love some feedback.
LGTM. Should probably update both the FC and NES pinouts at the same time.
Do you want to update the page or shall I?
I don't know if it was ever used as such, but the /IRQ line could also be considered bidirectional between the cart and EXP port (and the only such pin on Famicom).
I like the idea, though I'm not sure I like the terminology. I think "direction" might imply some undesirable things, and the arrows feel ambiguous to me.
What if instead you called the various pin types:
1. controlled by NES
2. controlled by cartridge
3. controlled by either (or both, if bus conflict)
I dunno what I'd suggested for symbols, maybe arrows is okay, but it's confusing to me what they mean to represent. Do they point at the device that controls the line, or the device that is controlled by the line? These are questions that should be resolved with text accompanying the diagram or otherwise. (For reference: the cartridge card-edge would be inserted down into the middle of the diagram with the board sticking up out of the screen.)
I borrowed the arrows from the CPU pin out (
http://wiki.nesdev.com/w/index.php/CPU_ ... escription) and PPU pin outs (
http://wiki.nesdev.com/w/index.php/PPU_ ... escription).
I agree, they can be a bit confusing but with a key describing them it should be better than nothing.
If you're matching with those diagrams you linked, shouldn't the PRG/CHR A lines point "in" to the cartridge, not "out"? They came "out" of the CPU, they should go "in" to the cart, right?
My arrows are from the perspective of the NES motherboard not the cartridge. The reason I chose the MB side is because it is the only device of the pair to have all the connections "hooked up" all the time. For example some cartridges don't have a CIC chip so those would technically be NC.
I don't understand what you mean by the perspective of the motherboard. The motherboard is just a host of the lines being diagrammed. This is a diagram of the connector, looking straight into the connector. You have a description that says "output to cartridge" and then the arrow points away from the cartridge slot, and I don't understand why you would label it this way.
It's also opposite to the other diagrams you linked for comparison. These things should correspond, if it comes "out" of the CPU, it goes "in" to the cartridge. Do you understand what I'm saying? The two diagrams put together should look like:
[ cartridge connector ] <- PRG A5 <- [ CPU ]
But what you've done looks like:
[ cartridge connector ] -> PRG A5 <- [ CPU ]
Ah I see what you're saying. I'm thinking in terms of the other side of the connector where the connector connects to the cart not where the connector connects to the motherboard. I went ahead and changed the directions based on your advice.
I would love to fill in the CIC pins and EXP pins but I'm not sure what to fill them in with. If you have any insight into this it would be great.
The EXP pins aren't normally connected to anything. Any connection there is between something custom at both ends of the line. Maybe just -- or xx or the space that's already there for disconnected?
Hmm, I noticed you've used -- for 5V and Ground but I think both of these should be arrows pointing in to the connector. They're both controlled externally to the cartridge, so aren't they an input? I suppose they're fixed signals, no information going in or out, I dunno, depends on point of view maybe. Perhaps a special symbol is okay for them instead of an input arrow.
EXP 6 is commonly used by the PowerPak for expansion audio (requiring the NES end of the line to be tied into the audio circuit), and I believe EXP 9 is sometimes used for the same purpose on top loaders. There's a few other EXP uses listed on the connector page. It's probably fine to diagram them all as disconnected. Someone who has done a custom mod will know what's connected to them anyway.
I don't know much about the CIC circuit. Perhaps you can get the needed information here?
http://wiki.nesdev.com/w/index.php/CIC_ ... hip_pinout
I personally like labeling the cart edge busses as "PPU" and "CPU" instead of "CHR" and "PRG". It's more compatible with how mapper chip pinouts are typically labeled. CHR is really a misnomer here anyway because that bus carries both CHR and NT.
rainwarrior wrote:
Hmm, I noticed you've used -- for 5V and Ground but I think both of these should be arrows pointing in to the connector. They're both controlled externally to the cartridge, so aren't they an input? I suppose they're fixed signals, no information going in or out, I dunno, depends on point of view maybe. Perhaps a special symbol is okay for them instead of an input arrow.
Convention is that power rails aren't considered to be "inputs" nor "outputs", hence why I used
-- elsewiki.
Quote:
I don't know much about the CIC circuit.
CIC toPak is the same direction as PPU A10. CIC to toMB is the same direction as CIRAM A10. (I've already updated the wiki to match)
I renamed the CIC data signals because "in" and "out" are the pins of the CIC itself, and they don't change from master to slave. So those names don't really describe the routing of the signal across the connector.
I also advocate the "controlled by NES" and "controlled by cart" terminologies.
"Input" and "output" are extremely ambiguous, as an input form one side is an output from the other side. This can end up being more confusing than what it looks like at 1st.
Yeah, that's basically the same problem with signals like TX/RX. When messing with UARTs (RS-232...) I end up using a scope to verify signal direction, you just don't know if it's from a DCE or a DTE standpoint. How much do I love how SPI signals are named: MOSI (Master In, Slave Out) and MISO, wow much clear so nice much easy.
入出力表記のの追加はわかりやすくなりいいと思います。しかし、PRG/CHRバスの表記方法は時代遅れと感じています。
私のように memory controller IC (mapper IC) の配線を調べる立場にとって、 CPU/PPU から直接出ているバス全てを PRG/CHR と表記すると混乱だらけになる。この表記方法には否定的だ。私はバスを理解するまで、このような曖昧な表記方法のおかげで理解がおそかった。
I'm a position to examine the wiring of mapper IC. CPU/PPU buses are combined as PRG/CHR, which naming makes many confusion. I do not recommend this.
Here's how I've always understood the terms "PPU bus", "CPU bus", "CHR bus", and "PRG bus": The PPU bus becomes the CHR bus after passing through the mapper, and the CPU bus becomes the PRG bus after passing through the mapper.
Code:
Conceptual illustration of buses present
in an NES Game Pak (not to scale)
,-------. ,-------.
|CHR ROM| |PRG ROM|
`-------' `-------'
||| ||| CHR ||| ||| PRG
||| |||<-bus ||| |||<-bus
||| ||| ||| |||
|||,--------------.|||
|||| Mapper |+||
|||`--------------'|||
||| ||| PPU ||| ||| CPU
||| |||<-bus ||| |||<-bus
||| ||| ||| |||
||| ||| ||| ||| Cart edge
ooo ooo ooo ooo<-connector
tepples wrote:
Here's how I've always understood the terms "PPU bus", "CPU bus", "CHR bus", and "PRG bus": The PPU bus becomes the CHR bus after passing through the mapper, and the CPU bus becomes the PRG bus after passing through the mapper.
Code:
Conceptual illustration of buses present
in an NES Game Pak (not to scale)
,-------. ,-------.
|CHR ROM| |PRG ROM|
`-------' `-------'
||| ||| CHR ||| ||| PRG
||| |||<-bus ||| |||<-bus
||| ||| ||| |||
|||,--------------.|||
|||| Mapper |+||
|||`--------------'|||
||| ||| PPU ||| ||| CPU
||| |||<-bus ||| |||<-bus
||| ||| ||| |||
||| ||| ||| ||| Cart edge
ooo ooo ooo ooo<-connector
It's actually simpler than that.
Just think that CPU BUS is a sub set of PRG bus and PPU BUS is a subset of CHR bus. Because what the Mapper IC does mostly is expand the number of address lines available. It's not really that confusing. It even works exactly the same on a Famicom, a MSX or SEGA Master System/MARK-III... It's just that the Famicom has two parallel mappers operating at the same time in two independent buses.
I would say stick to official naming to reduce the confusion the maximum possible.
I was the other day homebrewing hardware for the Master System and had a hard time with the ASIC generated bus signals naming adopted by the folks at SMS Power while using a SEGA official schematic as pinout reference.
Extremely annoying experience....
So far the NESDEV wiki has done great at avoiding that stuff so let's not duplicate that here, please.
Quote:
Just think that CPU BUS is a sub set of PRG bus and PPU BUS is a subset of CHR bus.
This is true in a loose sense. However, except for a few simple discrete mappers like CNROM, BNROM, and GNROM, a mapper doesn't just add address lines on the way up to the PRG ROM and CHR ROM; it also (conceptually) strips off some upper address lines. For example, the PRG ROM in an MMC3 or FME-7 game can't see CPU A14-A13; it can only see what value of PRG A18-A13 correspond to a particular combination of those values.
Quote:
I would say stick to official naming to reduce the confusion the maximum possible.
How much of this renaming habit comes from A. the community establishing names without access to official documents, or B. wishing to avoid admitting having been tainted by trade-secret or otherwise illegally copied documents?
tepples wrote:
This is true in a loose sense. However, except for a few simple discrete mappers like CNROM, BNROM, and GNROM, a mapper doesn't just add address lines on the way up to the PRG ROM and CHR ROM; it also (conceptually) strips off some upper address lines. For example, the PRG ROM in an MMC3 or FME-7 game can't see CPU A14-A13; it can only see what value of PRG A18-A13 correspond to a particular combination of those values.
Exception being that technically the ROM doesn't see anything as it's not the active element in the action. It's seen by the CPU, which is the element actively reading it. The way the ROM is connected to the bus affect the granularity of the pages or their ordering and that's sensible to the way the software executes, not to the ROM layout (as it's "seen by itself). Including that's a known trick to make software dumping more annoying (have the address lines shuffled so when a chip is read "correctly" with a chip programmer the code is shuffled in the reverse way... Only way to read it properly is analyze how the ROM is hooked to the CPU and duplicate that or use that to de-shuffle the dumped data...)
tepples wrote:
How much of this renaming habit comes from A. the community establishing names without access to official documents, or B. wishing to avoid admitting having been tainted by trade-secret or otherwise illegally copied documents?
That never been a concern for people dealing with SEGA systems. I know Nintendo used to be "ANAL" about their designs back in the day due to the (then justified) concern about how much such knowledge would aid counterfeiters but fear that they will prosecute at this point down the road is a perfect example of a moot point. They won't pursue a subject if the object is not either a possible direct menace to any of their businesses nor is a possible way for them to achieve direct instant profit.
Lovely discussion.