nesdev.com

I just want to ask to make sure, because the wiki is a bit confusing on this topic.

Is the following correct?

• 1. Between the CPU and the controller ports / expansion ports on both the NES and Famicom, all 2 x 5 input lines are inverted. Thus a 5V input from the controller pin / expansion port will be read by the CPU as a 0, and 0V will read as 1.
• 2. The outputs from the CPU ($4016 write D0-2) are not inverted. Sending a 1 from the CPU produces 5V output until $4016 is written again with a 0.
• 3. The CLK signal is normally 5V, but when the CPU reads $4016 or $4017 it becomes 0V while reading, and then returns to 5V once completed which will clock the shift register (low-to-high transition).
• 4. The expansion lines and the front controller port are both tied to the same inverting buffer, so it is not the case that one is inverted and the other is not.

The reason I'm confused about this is the expansion port diagrams on the wiki mention inversion for only two cases, and then notate all the controller input data lines with xx which I don't know the meaning of. Controller port pinout doesn't mention how the signals work at all or even just inversion. Then I found this topic with a schematic that looks horribly wrong to me.

Standard controller seems to say this stuff, now that I've kinda sorted it out and can follow what I'm reading but I just want to see if I understand this properly or not.

Correct, in the Famicom and NES-001 there's a 74'368 inverting the pins from the controller jacks and/or expansion port into the CPU. There's some ASIC in the AV Famicom and NES-101 that does something similar.

Correct.

Basically correct. The behavior is subtly different in the NES and the Famicom.

In the Famicom, the pin floats with a weak pullup. /RD4016 and /RD4017 enable a tristateable inverter from M2, pulling the CLK signals strongly high then low on every cycle that the 2A03 reads from the joysticks.

In the NES, the 2A03's pin is directly connected to the CLK pins on the controllers, and M2 does not affect things; as a result, DPCM bit deletions of the serial port will behave differently.

Correct.

I've added a call-out in the bit below to try to explain that.

Thanks for the confirmation. I'll try to spruce up the wiki a little bit.


So... does this mean that on the Famicom the CLK signal goes high partway through the cycle (via M2) and on the NES it goes high slightly later when the whole cycle is finished?

How does that affect DPCM bit deletions differently?

Was I correct to assume that CLK is otherwise pulled high at all times?


So the xx is just trying to indicate that there's a potential bus conflict if two things are connected to the same line?

Ideally, to the best of my knowledge, in the case of a double-read, the two waveforms should look like this:


Yeah. There's a pullup resistor on the NES that weakly pulls the pin high when the 2A03 is reset.

I was more thinking that it's neither strictly an input nor an output because it depends on what else is connected.

Ah, okay so I had the order backwards (it goes low earlier, rather than high later).

So the double read DPCM case is when a bit deletion read happens one cycle later than a legit read, causing a deletion on the Famicom but not the NES?

Does that also mean instructions with a double read can have a deleted bit on the Famicom but not the NES? (Maybe that only applies to RMW instructions, though? It seems like the read-only instructions aren't capable of doing a double read from the same address?)

Yeah. I don't remember exactly the address pattern that happens during a DPCM deletion, so I don't know exactly how it would go.

I guess that with the NES, you'll only get a single bit deletion, where as things that care about M2, such as the the Famicom and 2C02 $2007 you'll see multiple bits of deletion.

I think you're right. (The RMW abs,X instructions do... say X=0, ROL $4017,x should read from and write to $4017 both twice.)

is posible send PPU or char mapa memory over serial port?

_________________
http://ochobitwlectqv5c.onion.link/
http://4232.cf/

I'm afraid I don't understand your question.

With a quite big risk i'm misreading your intentions (sorry, in that case):


You can load any addressable data into your A,X,Y registers and then write it to the controller ports, with an appropriate routine, but it's slow, since it is serial. You probably want to be frugal about what sort of data you're sending/receiving.

Connecting two NES:es this way for 2-television, 2-NES multiplayer is possible, but the games probably need to be pretty basic. You're best off trying something turn based, like a game of battleships or a card game or something.

You can put a dual ported RAM and shift registers between the two units as a middleman device, if you so wish. That may make interaction easier since the NES:es don't need to sync talk/listen phases.

There was a thread recently about a realworld proof of concept, using a laptop as a middleman server. Another related item is memblers' usb-to-nes controller cable which is part of the kit that lets you reprogram GTROM boards. I think partytimeHXLNT:s twitter reader/poster for the NES used the controller port, too.

You also need to be mindful of what cable you're using. Not all controller port cables (new or old) have all the wires present. Ask your manufacturer if buying new ones from china.

_________________
http://www.frankengraphics.com - personal NES blog

It's possible to send any data you want over the serial port, but it goes to the CPU first. You can pass it on to the PPU from the CPU, if you want, though for CHR data that requires the use of CHR-RAM, of course.

I'm not sure there's many practical applications for this kind of thing, though. The serial port is very low bandwidth, and not too bad for input devices, but sending bulk data will be very slow, and probably for most purposes you can just get more data onto the cart some other way that is cheaper and faster?

Unless you're building a RAM cartridge to be used on the second machine for several different games, analogous to the "multiboot" feature that was reportedly planned for Lynx and shipped with Game Boy Advance. Player 2 using such a cartridge would receive graphics, code, and the like from player 1 over the serial connection before gameplay begins, possibly with some loading between levels.

Another application for the RAM cartridge would be to load it with heavy problems to solve. Then send a problem ID, some passed variables, do some stuff, then check back later for an answer.

_________________
http://www.frankengraphics.com - personal NES blog