It is currently Mon Dec 10, 2018 7:26 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Thu Nov 23, 2017 4:11 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7006
Location: Canada
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.


Top
 Profile  
 
PostPosted: Fri Nov 24, 2017 4:32 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7804
Location: Seattle
rainwarrior wrote:
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.
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.

Quote:
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.
Correct.

Quote:
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).
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.

Quote:
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.
Correct.

Quote:
then notate all the controller input data lines with xx which I don't know the meaning of.
I've added a call-out in the bit below to try to explain that.


Top
 Profile  
 
PostPosted: Fri Nov 24, 2017 2:42 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7006
Location: Canada
Thanks for the confirmation. I'll try to spruce up the wiki a little bit.

lidnariq wrote:
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.

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?

lidnariq wrote:
rainwarrior wrote:
then notate all the controller input data lines with xx which I don't know the meaning of.
I've added a call-out in the bit below to try to explain that.

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


Top
 Profile  
 
PostPosted: Fri Nov 24, 2017 2:55 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7804
Location: Seattle
rainwarrior wrote:
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?
Ideally, to the best of my knowledge, in the case of a double-read, the two waveforms should look like this:
Code:
Famicom """""""""""""""""_______"""""_______""""""""""""
NES     """"""""""""________________________""""""""""""


Code:
Was I correct to assume that CLK is otherwise pulled high at all [other] times?
Yeah. There's a pullup resistor on the NES that weakly pulls the pin high when the 2A03 is reset.

rainwarrior wrote:
So the xx is just trying to indicate that there's a potential bus conflict if two things are connected to the same line?
I was more thinking that it's neither strictly an input nor an output because it depends on what else is connected.


Top
 Profile  
 
PostPosted: Fri Nov 24, 2017 3:59 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7006
Location: Canada
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?)


Top
 Profile  
 
PostPosted: Fri Nov 24, 2017 4:10 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7804
Location: Seattle
rainwarrior wrote:
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?
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.

Quote:
It seems like the read-only instructions aren't capable of doing a double read from the same address?
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.)


Top
 Profile  
 
PostPosted: Sat Jul 07, 2018 12:53 pm 
Offline
User avatar

Joined: Fri Nov 24, 2017 1:36 pm
Posts: 77
Location: Argentina
rainwarrior wrote:
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.



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

_________________
https://maquinaslibres.noblogs.org/tag/8bit/
http://4232.cf/


Top
 Profile  
 
PostPosted: Sat Jul 07, 2018 1:02 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7804
Location: Seattle
I'm afraid I don't understand your question.


Top
 Profile  
 
PostPosted: Sat Jul 07, 2018 1:45 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
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


Top
 Profile  
 
PostPosted: Sat Jul 07, 2018 3:47 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7006
Location: Canada
bazza wrote:
is posible send PPU or char mapa memory over serial port?

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?


Top
 Profile  
 
PostPosted: Sun Jul 08, 2018 6:05 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20851
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sun Jul 08, 2018 11:48 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Ben Boldt and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group