Riding the open bus

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Riding the open bus

Post by tepples »

Satellite = wireless Four Score
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: Riding the open bus

Post by zzo38 »

Have you consider my idea (as improved by lidnariq; my original code contained a mistake) to distinguish RF Famicom from others (I have been unable to test it so far):

Code: Select all

   LDX #$FF
   STX $2002
   LDA $3F17,X
   AND #$18
Because RF Famicom has microphone and not player 2 SELECT/START, there might possibly be the use. It also mean that an emulator could function in similar way too based on its configuration so that the program running on it can detect in this way.
(Free Hero Mesh - FOSS puzzle game engine)
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Riding the open bus

Post by Pokun »

If you want to try it I'm happy to test it on my Famicom if no one else does. I only have the original RF-Famicom though, no Twin or AV. But would this work if the controller II was unplugged?

Is the differences regarding the con II reading values being different (A, B, 0, 0, Up, Down, Left, Right instead of A, B, Select, Start, Up, Down, Left, Right) a result of differences on the main board or is this encoder chip inside the controller itself? So if I were to connect a controller I in the controller II port, would Start and Select work? Not sure I understood everything correctly though.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Riding the open bus

Post by tepples »

zzo38 wrote:Have you consider my idea (as improved by lidnariq; my original code contained a mistake) to distinguish RF Famicom from others (I have been unable to test it so far):

Code: Select all

   LDX #$FF
   STX $2002
   LDA $3F17,X
   AND #$18
That's a test for $4016 D4-3 open bus, through the PPU data latch.[1] The code in src/openbus.s uses this same behavior but uses nametable memory for the reads. And the technique as you have presented it may confuse an NES with a Zapper in port 1 with a Famicom, which is why src/openbus.s uses a more elaborate test to tell the difference among always 0, always 1, serial (like the Power Pad), or open bus.

Telling open bus from the other possibilities is enough to distinguish a Famicom (RF or AV) from NES-001 and NES-101. But the AV Famicom has the same behavior as an RF Famicom in this respect. And I don't think the mic can be counted on to pick up background noise unless the user shouts or blows during probing.

@Pokun
It would more than likely think an RF Famicom with an unplugged controller II is an AV Famicom, drawing the controller as a dogbone.

I'm pretty sure that the 0, 0 on bits 3 and 4 of controller II's report is a result of how the 4021 is wired inside the controller. One thing that may make connecting controller I to the controller II port differ is that controller II has the additional wire for the mic.

This evening I'll post a build with serial watch. It may be the last to support lidnariq's board. One limit I thought of while coding it is that slowly reading a serial line and quickly reading instructions to select a serial line kind of conflict with each other, especially on controllers where a strobe pulse has side effects (Arkanoid Controller and Super NES Mouse).


[1] A misunderstanding that had appeared here has been corrected.
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: Riding the open bus

Post by zzo38 »

tepples wrote:
zzo38 wrote:Have you consider my idea (as improved by lidnariq; my original code contained a mistake) to distinguish RF Famicom from others (I have been unable to test it so far):

Code: Select all

   LDX #$FF
   STX $2002
   LDA $3F17,X
   AND #$18
That's a test for $4016 D4-3 open bus. But $3F17 is $2007, which is VRAM readback, and your stx $2002 writes to the PPU data latch, not the readback latch, which appears to be separate. The code in src/openbus.s uses this same behavior but uses nametable memory for the reads. And the technique as you have presented it may confuse an NES with a Zapper in port 1 with a Famicom, which is why src/openbus.s uses a more elaborate test to tell the difference among always 0, always 1, serial (like the Power Pad), or open bus.
I think that it first reads from $3F16 and then $4016, is how it works (that the low 8-bits of the effective address are correct for both reads), but you can correct me if this is wrong.
Telling open bus from the other possibilities is enough to distinguish a Famicom (RF or AV) from NES-001 and NES-101. But the AV Famicom has the same behavior as an RF Famicom in this respect.
If you have that stuff then hopefully it can still be tested distinct. Note that I am using the information in wiki about "Standard controller", which says that $4016 D4-3 is not open bus on AV Famicom, but that bit2 is open bus on AV Famicom and on top-loading NES, and always zero for front-loading NES. If it is wrong, hopefully it can be corrected.
And I don't think the mic can be counted on to pick up background noise unless the user shouts or blows during probing.
That I agree.

I think the best way to figure out if this will work or not is to try it on all of the common hardware variants, and to see what happen.
(Free Hero Mesh - FOSS puzzle game engine)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Riding the open bus

Post by tepples »

zzo38 wrote:
tepples wrote:
zzo38 wrote:Have you consider my idea (as improved by lidnariq; my original code contained a mistake) to distinguish RF Famicom from others (I have been unable to test it so far):

Code: Select all

   LDX #$FF
   STX $2002
   LDA $3F17,X
   AND #$18
That's a test for $4016 D4-3 open bus. But $3F17 is $2007, which is VRAM readback, and your stx $2002 writes to the PPU data latch, not the readback latch, which appears to be separate. The code in src/openbus.s uses this same behavior but uses nametable memory for the reads. And the technique as you have presented it may confuse an NES with a Zapper in port 1 with a Famicom, which is why src/openbus.s uses a more elaborate test to tell the difference among always 0, always 1, serial (like the Power Pad), or open bus.
I think that it first reads from $3F16 and then $4016, is how it works (that the low 8-bits of the effective address are correct for both reads), but you can correct me if this is wrong.
MY BAD.

This does read $3F16 then $4016. I was misled by the "$3F17" in the instruction. My test uses X=$20 (because reasons), giving lda $3FF6,x and lda $3FF7, x. The value read from $3F16 is indeed the PPU data latch.
I think the best way to figure out if this will work or not is to try it on all of the common hardware variants, and to see what happen.
Agreed. That's why I'm trying to finish this up. Once I get serial watch in tonight, I'm not sure what other features I need to add.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Riding the open bus

Post by Pokun »

tepples wrote:And I don't think the mic can be counted on to pick up background noise unless the user shouts or blows during probing.
Especially since most people have the volume turned off on it.
@Pokun
It would more than likely think an RF Famicom with an unplugged controller II is an AV Famicom, drawing the controller as a dogbone.
I see makes sense, well you are not supposed to plug it out that often anyway I guess.

I'm pretty sure that the 0, 0 on bits 3 and 4 of controller II's report is a result of how the 4021 is wired inside the controller. One thing that may make connecting controller I to the controller II port differ is that controller II has the additional wire for the mic.
That's what I was thinking. Then maybe adding start and select is as simply as adding a second controller I. The plug is different though so it won't just plug in normally.

Once I get serial watch in tonight, I'm not sure what other features I need to add.
Maybe detect other hardware changes? Like CPU/PPU revision (RGB PPU revision) or features ($2004 readability etc) if it's possible. Might be a bit hard to test though.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Riding the open bus

Post by tepples »

Pokun wrote:
tepples wrote:I'm not sure what other features I need to add.
Maybe detect other hardware changes? Like CPU/PPU revision (RGB PPU revision) or features ($2004 readability etc) if it's possible. Might be a bit hard to test though.
I could add the overclock test (as seen in my NES port of the 240p test suite), and I do plan to add that once I reuse the controller detection routine in the POST screen of a future version of the Action 53 menu.

Distinguishing "2C02" and "2C02G" could be useful on the POST screen. How is an RGB PPU detected? Is it based only on the lack of a short pre-render line? Are there existing test ROMs with source code that I could read, understand, and rewrite from scratch?

Here's the serial watch.
Attachments
allpads-r9.zip
(71.02 KiB) Downloaded 953 times
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Riding the open bus

Post by Pokun »

I have no idea, but I'm guessing since the first 5 bits of $2002 contains the revision ID instead of last written LSBs on RGB PPUs, maybe you could try this:

1) Read $2002 and save the value in RAM.
2) Write to a PPU register.
3) Read $2002 and save the value in RAM again.
4) Write to PPU again with a totally different value.
5) Read $2002 again, repeat these steps at least one more time.
6) Finally check if the the first 5 bits in final value read from $2002 has changed from the earlier. If not, it's the PPU revision number and the PPU is an RGB one.

I have no RGB PPU system to test on though.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Riding the open bus

Post by Quietust »

Pokun wrote:I have no idea, but I'm guessing since the first 5 bits of $2002 contains the revision ID instead of last written LSBs on RGB PPUs, maybe you could try this:

1) Read $2002 and save the value in RAM.
2) Write to a PPU register.
3) Read $2002 and save the value in RAM again.
4) Write to PPU again with a totally different value.
5) Read $2002 again, repeat these steps at least one more time.
6) Finally check if the the first 5 bits in final value read from $2002 has changed from the earlier. If not, it's the PPU revision number and the PPU is an RGB one.

I have no RGB PPU system to test on though.
Only the 2C05 PPUs return special values in the lower bits of $2002, and they also have the additional "quirk" that registers $2000 and $2001 are swapped which would prevent the rest of the program from working at all without significant changes...
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Riding the open bus

Post by tepples »

Some of the last RGB mods before the NESRGB's release use a 2C05 with extra glue logic to unswap $2000 and $2001. I guess I could try detecting a 2C05 that has been unswapped in this manner by writing to $2002 and reading it back. But then that leaves detecting a 2C03, as seen in a Titler.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Riding the open bus

Post by Pokun »

I read somewhere that Titler and Sharp C1 unswaps $2000 and $2001 using some extra circuitry, and I had gotten the impression that all RGB PPUs returned the revision value. I guess that was wrong.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Riding the open bus

Post by tepples »

Perhaps some Titler revisions contain surplus 2C05 PPUs and the A0'=A0 XOR (A2 NOR A1) glue.

I remember the U.S. versions of the NES TV have a standard composite PPU because of the RGB PPUs' incompatibility with games that heavily use color emphasis.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Riding the open bus

Post by tepples »

It's come to my attention that this program does not support a Hyper Click third-party mouse. I have purchased one with which to test and filed an issue.

There also might be interest in porting this and my other works to FDS.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Riding the open bus

Post by rainwarrior »

tepples wrote: Wed Mar 25, 2015 8:56 pmI wonder whether running the FDS version of The Legend of Zelda on a PowerPak would cause Pols Voice to self-destruct.
For the record: it does not.
Post Reply