Riding the open bus
Moderator: Moderators
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):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.
Code: Select all
LDX #$FF
STX $2002
LDA $3F17,X
AND #$18
(Free Hero Mesh - FOSS puzzle game engine)
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.
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.
Re: Riding the open bus
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.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
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.
Re: Riding the 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.tepples wrote: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.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
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.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.
That I agree.And I don't think the mic can be counted on to pick up background noise unless the user shouts or blows during probing.
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)
Re: Riding the open bus
MY BAD.zzo38 wrote: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.tepples wrote: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.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
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.
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.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.
Re: Riding the open bus
Especially since most people have the volume turned off on it.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.
I see makes sense, well you are not supposed to plug it out that often anyway I guess.@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.
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.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.
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.Once I get serial watch in tonight, I'm not sure what other features I need to add.
Re: Riding the open bus
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.Pokun wrote: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 wrote:I'm not sure what other features I need to add.
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
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.
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.
Re: Riding the open bus
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...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.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
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.
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.
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.
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.
Re: Riding the open bus
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.
There also might be interest in porting this and my other works to FDS.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact: