nesdev.com
https://forums.nesdev.com/

Riding the open bus
https://forums.nesdev.com/viewtopic.php?f=2&t=12549
Page 4 of 4

Author:  tepples [ Mon Dec 12, 2016 7:35 am ]
Post subject:  Re: Riding the open bus

Satellite = wireless Four Score

Author:  zzo38 [ Tue Dec 13, 2016 5:18 am ]
Post subject:  Re: Riding the open bus

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

Author:  Pokun [ Tue Dec 13, 2016 6:45 am ]
Post subject:  Re: Riding the open bus

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.

Author:  tepples [ Tue Dec 13, 2016 7:38 am ]
Post subject:  Re: Riding the open bus

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

Author:  zzo38 [ Tue Dec 13, 2016 11:32 am ]
Post subject:  Re: Riding the open bus

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

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

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

Author:  tepples [ Tue Dec 13, 2016 11:41 am ]
Post subject:  Re: Riding the open bus

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

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

Author:  Pokun [ Tue Dec 13, 2016 5:14 pm ]
Post subject:  Re: Riding the open bus

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.

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


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


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

Author:  tepples [ Tue Dec 13, 2016 6:18 pm ]
Post subject:  Re: Riding the open bus

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 62 times

Author:  Pokun [ Wed Dec 14, 2016 1:25 am ]
Post subject:  Re: Riding the open bus

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.

Author:  Quietust [ Wed Dec 14, 2016 5:31 am ]
Post subject:  Re: Riding the open bus

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...

Author:  tepples [ Wed Dec 14, 2016 7:36 am ]
Post subject:  Re: Riding the open bus

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.

Author:  Pokun [ Wed Dec 14, 2016 6:13 pm ]
Post subject:  Re: Riding the open bus

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.

Author:  tepples [ Wed Dec 14, 2016 6:54 pm ]
Post subject:  Re: Riding the open bus

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.

Page 4 of 4 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/