This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Riding the open bus

Riding the open bus
by on (#143750)
I'm trying to make a ROM that distinguishes the NES from the Famicom and lists which controllers are plugged into the system. I planned to do this using distinct open bus behavior, but the PowerPak and several emulators are disagreeing again.

Open bus occurs when nothing puts a 0 or 1 on a bit of the data bus during a read. Capacitance holds the old voltages in place for the CPU to use as the value. Reading nonexistent memory, for example, usually leaves the instruction's last byte on the bus, which on 6502 is the address's high byte.

But the PowerPak has been known to interfere with open bus before. Pull-up resistors for 3.3 V to 5 V conversion tend to remove old bits from the data bus. Mindscape games would fail to see presses because they expected open bus on unused bits of the controller port.

Here's what I expected:
Code:
PPU readback result
     00 FF 00 FF 00 FF 00 FF
Open bus result
     40 40 20 20 20 3F 3F 3F
Controller bits
     40 40 20 20 41 41 21 21

Here's what FCEUX gives me:
Code:
PPU readback result
     00 FF 00 FF 00 FF 3F 3F
Open bus result
     40 40 00 00 00 00 00 3F
Controller bits
     40 40 00 00 41 41 01 01

And Mednafen:
Code:
PPU readback result
     00 FF 00 FF 00 FF 00 FF
Open bus result
     40 40 FF FF FF FF FF FF
Controller bits
     40 40 00 00 41 41 00 01

The PowerPak behaves as if all lines had pull-ups (I'm a big kid now):
Code:
PPU readback result
     00 FF 00 FF 00 FF FF FF
Open bus result
     FF FF FF FF FF FF FF FF
Controller bits
     E0 E0 E0 E0 E1 E0 E1 E1


What do you get on a modded donor board or INL-ROM?


This test ROM has a known defect. An improved test will be posted soon.
Re: Riding the open bus
by on (#143753)
Results for me two separate NES consoles (I don't have a 72-to-60-pin converter so I can't use my PowerPak w/ my Famicom AV). Providing console S/Ns "just in case":

PowerPak + NES front-loader (S/N N11526282)
Code:
PPU readback result
     00 FF 00 FF 00 FF FF FF
Open bus result
     FF FF FF FF FF FF FF FF
Controller bits
     E0 E0 E0 E0 E1 E0 E1 E1

PowerPak + NES top-loader (S/N NN104472123)
Code:
PPU readback result
     00 FF 00 FF 00 FF FF FF
Open bus result
     FF FF FF FF FF FF FF FF
Controller bits
     E4 E0 E4 E4 E5 E0 E5 E5
Re: Riding the open bus
by on (#143754)
Does it change if you put a controller in port 2? On my frontloader, if I have two controllers plugged in, I get
Code:
E0 E0 E0 E0 E1 E1 E1 E1  (2 controllers)
E0 E8 E0 E0 E1 E8 E1 E1  (controller and Zapper)
E0 F8 E0 E0 E1 F8 E1 E1  (controller and Zapper, trigger half-held during Reset)
E0 E0 E0 E0 E1 F0 E1 E1  (controller and Arkanoid paddle)
E0 E8 E0 E0 E1 F8 E1 E1  (controller and Arkanoid paddle, button held during Reset)
E0 E0 E0 E0 E1 F8 E1 E1  (controller and Power Pad)
Re: Riding the open bus
by on (#143756)
Further testing (same equipment as earlier):

Code:
E0 E0 E0 E0 E0 E0 E0 E0  (Front-loader, no controllers)
E0 E0 E0 E0 E1 E1 E1 E1  (Front-loader, dogbone #1, Famicom AV dogbone #2)
E0 E8 E0 E0 E1 E8 E1 E1  (Front-loader, dogbone #1, Zapper (orange) #2)
E0 E8 E0 E0 E1 F8 E1 E1  (Front-loader, dogbone #1, Zapper (orange) #2, trigger half-held)
E0 E0 E0 E0 E1 E1 E1 E1  (Front-loader, dogbone #1, original NES controller #2)

E4 E0 E4 E4 E4 E0 E4 E4  (Top-loader, no controllers)
E4 E0 E4 E4 E5 E1 E5 E5  (Top-loader, dogbone #1, Famicom AV dogbone #2)
E4 E8 E4 E4 E5 E8 E5 E5  (Top-loader, dogbone #1, Zapper (orange) #2)
E4 E8 E4 E4 E5 F8 E5 E5  (Top-loader, dogbone #1, Zapper (orange) #2, trigger half-held)
E4 E0 E4 E4 E5 E1 E5 E5  (Top-loader, dogbone #1, original NES controller #2)

That covers all the NES controller port peripherals I have.
Re: Riding the open bus
by on (#143758)
It was fast to hack that to mapper 218, so I tested. This is using my mapper 218 flashcart (with an 8KiB EEPROM for PRG), nothing else funny in the way.

Nothing plugged in:
Code:
CODE:04
PPU READBACK RESULT
     00 ff 00 ff 00 ff 00 ff
OPEN BUS RESULT
     40 40 ff ff ff ff ff ff
CONTROLLER BITS
     40 40 80 80 40 40 80 80


Only the last line changed as I changed what was plugged in:
Original square US controller in port 1: 40 40 80 80 41 40 81 81
Original square US controller in both ports: 40 40 80 80 41 41 81 81
Original square US controller in port 1 + zapper in port 2: 40 48 80 80 41 48 81 81
vice versa: 48 40 88 88 48 41 88 88


On the off chance that I could have broken anything, here's the diff:
Attachment:
mapper218-patch.zip [3.27 KiB]
Downloaded 885 times
Re: Riding the open bus
by on (#143759)
So I've learned a few things:
  • D0-D4 of both ports drive 0 on a front-loader, but D2 of port 1 on a top-loader is open bus. I wonder whether running the FDS version of The Legend of Zelda on a PowerPak would cause Pols Voice to self-destruct.
  • I can tell a serial input (like the standard controller, Super NES Mouse, Power Pad, or Arkanoid knob) from a constant input (like the Zapper trigger or the Arkanoid button).
  • Open bus on a PowerPak is pull-ups to $FF. I should make my program work with $FF. But with a "real" cartridge, however, APU open bus behaves as expected.
  • The original rectangular NES controller, the Famicom AV dogbone, and the top-loading NES dogbone appear to behave the same.
  • Per lidnariq's result, the PPU might not really have open bus. This merits further investigation.
  • There's a bug in my test program that makes the fourth and eighth bytes in "Controller bits" useless. I'll post a revised test program tomorrow.

I'd like to get results from some Famicoms, especially with controllers that plug in to the DA15 port. Later on, as I make the test ROM more detailed, I'd also like to get results from a variety of unlicensed NES controllers. It'd be more convenient for me to assume that return a string of 1's after the report like the official controllers do, a consequence of the 4021's shift input being tied to ground. But I seem to remember reading that some clone controllers have a string of 0's, as if the 4021's shift input were tied to power.

EDIT 45 minutes later with additional observations, performed on a PowerPak:

If you write to pretty much any PPU register and then read from the nominally write-only register PPUADDR ($2006), you get the same byte back. This gives full control of $4016 open bus through a $3F16-$4016 sequence, so long as you're not on a cart with pull-ups. It's true of PPUDATA ($2007) and PPUMASK ($2001). which are writable, as well as like PPUSTATUS ($2002). And FCEUX already emulates this accurately.

Let me repeat that again, because it shocked me so much: You can write a byte to PPUSTATUS and read it back from PPUADDR. Double shock is that FCEUX is accurate in this respect; its PPU calls the storage for this behavior PPUGenLatch.

This will change how I generate the open bus background for my reads.
Re: Riding the open bus
by on (#143762)
Some further emulator testing as well, just for comparison (maybe we'll learn something). This is just with one controller attached, using allpads-r1.zip.

VirtuaNES 0.97
Code:
code: 04
PPU readback result
     00 FF 00 FF 00 FF 40 40
Open bus result
     40 40 00 00 00 00 00 40
Controller bits
     40 40 40 40 41 41 40 41

Nestopia UE (2014/08/25 build)
Code:
code: 04
PPU readback result
     00 FF 00 FF 00 FF 40 40
Open bus result
     40 40 FF FF FF FF FF 40
Controller bits
     40 40 40 40 41 41 41 41

Nintendulator 0.975
Code:
code: 04
PPU readback result
     00 FF 00 FF 00 FF 00 FF
Open bus result
     40 40 FF FF FF FF FF FF
Controller bits
     40 40 00 00 41 40 01 01
Re: Riding the open bus
by on (#143789)
I found and fixed the controller test bugs. I also redesigned the open bus test to account for the existence of the PPU data latch. Here's what my PowerPak in a front-loader gives me now:
Code:
PPU readback
     00 FF 00 FF 00 FF FF FF
PPU latch     3F 3F 3F 3F 3F
APU open bus        FF FF FF

And here's what I get for controllers:
E0 E0 E0 E0: Nothing
E0 E0 E1 E1: D0 serial devices
E0 E0 F8 F8: Power Pad NES-028
E8 E8 E8 E8: Zapper
F8 F8 F8 F8: Zapper, trigger half pulled
E0 E0 F0 F0: Arkanoid controller
E8 E8 F8 F8: Arkanoid controller, button held

The D0 serial devices I tried were Nintendo Controller (NES-004), Retrolink Classic Controller Dogbone Edition, Turbo Touch 360, asciiPad (4900) through a pin adapter, and Super NES Mouse (SNS-016) through a pin adapter.
Re: Riding the open bus
by on (#143791)
tepples wrote:
Let me repeat that again, because it shocked me so much: You can write a byte to PPUSTATUS and read it back from PPUADDR. Double shock is that FCEUX is accurate in this respect; its PPU calls the storage for this behavior PPUGenLatch.

Well then -- this is certainly wrong. It would mean PPUSTATUS is read-write. But I suppose more research is needed before updating the Wiki.
Re: Riding the open bus
by on (#143796)
I thought it was documented that writes to any register in the PPU, including the non-existant one at $2002, can be read from ~any register except $2004 and $2007?
Re: Riding the open bus
by on (#143799)
Anyway, since my results vary slightly from yours:
Code:
PPU READBACK
     00 ff 00 ff 00 ff 00 ff
PPU LATCH     3f 3f 3f 3f 3f
APU OPEN BUS        40 40 ff

CONTROLLER 1     48 28 48 28  (orange zapper)
CONTROLLER 2     40 20 41 21  (square NES controller)
Re: Riding the open bus
by on (#143800)
Thank you. The results from lidnariq's cart match my mental model of what's going on, so now I can explain what the bits mean.

"PPU readback" is the result of reading back two bytes from the nametables four ways: through PPUDATA's base address ($2007), through the mirror at $3F07, through the mirror at $3F17, and through $3F07 riding the open bus to $4007. On authentic hardware, all four pairs should be $00 $FF. With pull-ups on all data lines, the last two will be $FF.

"PPU latch" writes $3F to PPUSTATUS ($2002) and then reads one of the PPUADDR ($2006) mirrors. It reads $2006, $3F06, $3F16, $3F16 64 times taking the last, and $3F16 after waiting a frame. All five should be $3F.

"APU open bus" is the result of reading $4006 and $4007. The first two should be $40. The third was supposed to ride the open bus from $3F06 to $4006, but it's useless due to a typo. I apologize for my typos; long-distance coding is a pain. If you still have the source code handy, please open src/openbus.s, scroll near line 108, and change sta open_bus_values+7 to sta open_bus_values+2 and tell me what that says.

"Controller" is four bytes. I read 32 samples from each controller port directly ($4016 or $4017), wait a frame, restrobe, and read 32 more samples riding the open bus ($3F16+$4016 or $3F17+$4017). The first two bytes in a group of four are the minimum values (all reads ANDed); the second two are the maximum values (all reads ORed). The first and third are from $4016; the second and fourth are from riding the open bus. The following can be observed:
  • Any bit that differs between the first and second probably comes from open bus.
  • Any bit that differs between the first and third is probably a serial output.
  • The $2x comes from the $3F that I use as "background" for maximum contrast with $40. PowerPak is full of Ex and Fx because of the pull-ups.
Re: Riding the open bus
by on (#143801)
tepples wrote:
"PPU latch" writes $3F to PPUSTATUS ($2002) and then reads one of the PPUADDR ($2006) mirrors. It reads $2006, $3F06, $3F16, $3F16 64 times taking the last, and $3F16 after waiting a frame. All five should be $3F.
Fascinatingly, after a few resets, the last byte of the five is consistently 1F or 0F (randomly one of the two, more often the former). A power cycle with three seconds off returns it to $3F, a reset after a few seconds returns it to $1F or $0F.

I think remember previous statements that this "latch" is actually the large capacitance of the very long traces from the pins to the various functions inside the PPU: what visual2c02 calls _io_db0 through _io_db7. Certain values ($55, $AA) should be less stable than others ($FF). _io_db0 is adjacent to pclk0 and pclk1, but since those run 180° out of phase, I'm not clear what the net effect would be, if anything.

Quote:
"APU open bus" is the result of reading $4006 and $4007. The first two should be $40. The third was supposed to ride the open bus from $3F06 to $4006, but it's useless due to a typo. I apologize for my typos; long-distance coding is a pain. If you still have the source code handy, please open src/openbus.s, scroll near line 108, and change sta open_bus_values+7 to sta open_bus_values+2 and tell me what that says.
Consistently says 3F now.
Open Bus Rider: The Adventure
by on (#143802)
I have some hardware results from almost everything but a PowerPak (On the other hand, I do have Everdrive N8)

Cart was a Konami NES-UNROM equivalent, converted to support 32-pin FLASH EPROMs and extended to support UOROM.
A while back I had converted Zap Ruder and LJ65 to run on this same board, and pretty much just copied the code again. It works well enough to be mostly reliable, and doesn't appear to conflict with the tests done here.

MediaFire folder containing all test screenshots. I did my best to make filenames as accurate as possible.

From left to right this is [Cart Only - NES-001], [Everdrive N8 - NES-001 - Cart Only], and [Everdrive N8 - HVC-101 - Cart Only]:
ImageImageImage

P.S.: Forgot to mention that the folder linked has tests using the cart on an NES-001 with just about every controller I could locate.

Notable quirks:
    UForce seems to be detected similar to a controller
    The Power Pad seems to be detected similar to the Zapper
    The Four Score detects like two controllers when the switch is set to 4 (I recall being able to detect which controllers are connected by reading the signature past the controller data)
    The Four Score appears to just pass controller data when the switch is set to 2, but not pass the extra data bits for the Zapper (This was fixed in the Satellite)
Re: Riding the open bus
by on (#143804)
Better to attach the files here than to use Mediafire....
Re: Open Bus Rider: The Adventure
by on (#143818)
AWal wrote:
MediaFire folder containing all test screenshots. I did my best to make filenames as accurate as possible.

Thanks.

Quote:
From left to right this is [Cart Only - NES-001], [Everdrive N8 - NES-001 - Cart Only], and [Everdrive N8 - HVC-101 - Cart Only]

HVC-101 is the Famicom AV, correct?

So it appears EverDrive N8 has the same open bus behavior as a donor. (The third byte of APU open bus is useless because v2 was used, not v2a.)
Code:
PPU readback
     00 FF 00 FF 00 FF 00 FF
PPU latch     3F 3F 3F 3F 3F
APU open bus        40 40 xx

Controller 1: 40 38 40 38
Controller 2: 40 38 40 38

This means that on both ports, D0-D2 are driven low and D3-D4 are open bus. Does it change if you plug any peripherals into the DA15 port? Do you have any such peripherals?

NES-001 results summarized:
Code:
40 20 40 20   Empty port on NES frontloader (NES-001)

40 20 41 21   Nintendo Controller (NES-004)
40 20 41 21   Super NES Controller (SNS-005)
40 20 41 21   Nintendo Controller (NES-039) nicknamed "Dogbone"
40 20 41 21   Family Computer Controller (HVC-102) nicknamed "Dogbone"
40 20 41 21   NES Advantage (NES-026)

40 20 41 21   NES Four Score (NES-034A)

48 28 48 28   Zapper (NES-005)
58 38 58 38   Zapper (NES-005), trigger held
40 20 58 38   Power Pad (NES-028)

40 38 40 38   Empty port on Famicom AV (HVC-101)
Open Bus Rider 2: Literal Electric Boogaloo
by on (#143832)
tepples wrote:
HVC-101 is the Famicom AV, correct?

That is correct.

tepples wrote:
This means that on both ports, D0-D2 are driven low and D3-D4 are open bus. Does it change if you plug any peripherals into the DA15 port? Do you have any such peripherals?

I don't currently at the moment. I'm looking into maybe obtaining a gun, but that's about it.

tepples wrote:
NES-001 results summarized:
40 20 41 21 NES Four Score (NES-034A)

I've noticed that the Four Score will either pass the controllers verbatim (in the 2 player mode), minus the extra data pins used for the light guns, or it will "pretend" to have controllers connected all around (in the 4 player mode), and the signature would generally have to be relied on instead (So one could only detect the adapter as a whole, not which controllers are actually connected).

tepples wrote:
v2 was used, not v2a.

Oops. Crap...Here's the results of r2a without any peripherals connected:

From left to right, NES-001 Cart, NES-001 Everdrive N8, Yobo FC Twin Everdrive N8, and HVC-101 Everdrive N8.
ImageImageImageImage

I'm starting to notice that these colors really stress out the poor picture quality on the clone console. I feel sorry for people who have to put up with poor board design like that because it would be prohibitively expensive to import a genuine console.
Re: Riding the open bus
by on (#143834)
Quote:
So one could only detect the adapter as a whole, not which controllers are actually connected

I figured as much.

Quote:
Here's the results of r2a without any peripherals connected

FC Twin transcribed:
Code:
PPU readback
     00 FF 00 FF 00 FF 00 FF
PPU latch     20 20 20 20 20
APU open bus        40 40 3F

Controller 1     44 24 44 24
Controller 2     48 28 48 28

Good: $3F07 reads properly ride the open bus.
Bad: PPU latch is wrong. NOAC is detectable.
Ugly: FC Twin has $4016.D2 and $4017.D3 high. Might this be related to its Zapper or perhaps the IOBit functionality needed for Super Scope?

Quote:
I'm starting to notice that these colors really stress out the poor picture quality on the clone console.

The vertical stripes on the FC Twin picture almost look like PA13 leaking into the video signal. The interrupted stripe at the left border, where the PPU "skips a beat" between the 2-tile preroll and the body of the picture, seals the deal. Are these signals adjacent on the FC Twin's motherboard? Either that or they're a power problem; perhaps the cart memory is drawing a lot more power than the NOAC's internal nametable memory. What kinds of bypass capacitors are near the power pins of the cart slot and NOAC?

Do you have a Super NES Mouse? I know it'd behave like a standard controller in this ROM. But I just want to see if the FC Twin runs Thwaite, or if I'd have to port it to the Super NES first.
Re: Riding the open bus
by on (#143841)
tepples wrote:
Bad: PPU latch is wrong. NOAC is detectable.
Actually, that makes sense ... if they're putting the PPU and CPU on the same die, there's no reason to have the extra bus drivers in there. No long separate trace with capacitance = no dynamic latch.

On second thought, if that were simply true, I would have thought it would have shown 20 3f 3f 3f 3f .... hm.
Signal Circuit; Freemium clone of Open Bus Rider; In Stores
by on (#144093)
tepples wrote:
Do you have a Super NES Mouse?...I just want to see if the FC Twin runs Thwaite, or if I'd have to port it to the Super NES first.


Here's a video demonstration. (Yes, it does just fine).
Re: Riding the open bus
by on (#145352)
Dwedit wrote:
Better to attach the files here than to use Mediafire....

Better to do both and provide a torrent hash? :)
Re: Riding the open bus
by on (#183569)
I've added more documentation on what all the results mean, both inside the ROM and in the separate file methodology.md. I also revamped font loading in preparation for turning what I have into a controller test, which will need some spare CHR space.
Re: Riding the open bus
by on (#183649)
Better yet, just display which bits are always off, which are always on, which are serial (that is, the value differs over the course of 32 reads), and which are NC (that is, the value differs based on whether the previous data bus value was $40 or $BF). For example, a standard NES controller will be ...0000S: bits 7-5 from open bus, bits 4-1 always off, and bit 0 serial.

I also changed the contrast value in the controller data comparison from $3F to $BF to make open bus at bit 7 visible. This should change, for example, 40 20 41 21 to 40 A0 41 A1. But again, the PowerPak interferes, so I'll probably need some help from an EverDrive, Kazzo, or EPROM programmer user.
Re: Riding the open bus
by on (#183650)
Tested on my m218 cart ... same as before but it indicates that the MSBit (D7, 128s) is driven rather than open bus. (i.e. 0..00000)
Re: Riding the open bus
by on (#183653)
Bit 7 appearing driven may be the result of a bug in the test. :oops: It's hard to test tests when I know that the hardware and emulators to which I have easy access will fail, and I appear to have left line 23 of src/openbus.s in the wrong state.

Before I attempt a rebuild to correct this problem, is there anything I can do to make testing on a mapper 218 cart easier, such as providing a special build whose font uses only 64 distinct tiles?
Re: Riding the open bus
by on (#183655)
That, and padding the PRG such that I don't need to resplice things to fit things into an 8 KiB PRG.

I guess I could share my updated patch ... it's assuredly not the Right Way to do things.
Re: Riding the open bus
by on (#183659)
Thanks for the clarification. Here's my first try at doing it the right way, where the mapper 218 version has a font limited to 64 unique tiles (the uppercase from Thwaite) and a linker script modified to move everything above $E000 to fit on your 27C64.
Re: Riding the open bus
by on (#183661)
Yup, that works as intended.
Code:
NES OPEN BUS TEST R3
  2016 DAMIAN YERRICK
RESET: RESCAN; START: HELP

PPU READBACK
     00 FF 00 FF 00 FF 00 FF
PPU LATCH     3F 3F 3F 3F 3F
APU OPEN BUS        40 40 3F

       4L 3L 4H 3H D76543210
1P:    48 A8 48 A8  ...01000 (zapper)
2P:    40 A0 41 A1  ...0000S (square controller)
Same NES-001 with removed CIC as before.
Re: Riding the open bus
by on (#183861)
Several revisions ago, we got results from Famicom and NES-101 systems. Now that r5 has what appears to be a correct, easy-to-read bitwise display of line condition (0, 1, serial, or NC), I'd like someone to repeat the test with r5 for the record, if anyone with a toploader and an EverDrive or single-game flash cart is willing. (No PowerPak; we've already established that those are often inaccurate.) Once this is done, I can continue work on transforming this into a controller test, which is one of the things I promised to do once I finished a paid project.
Re: Riding the open bus
by on (#183870)
Here is the output from a Top Loading NES w/HDMI mod.
Re: Riding the open bus
by on (#183871)
From IRC:
<pino_p> Anybody with a top-loader (HVC-001, HVC-101, or NES-101) and either an EverDrive or a single-game flash...

I have results from HVC-101 and the "Video Racer Video-Game".
Re: Riding the open bus
by on (#183874)
All had the expected values for PPU readback (00 FF) and APU open bus (40 40 3F).

Code:
NES-101
PPU latch: 3F 3F 3F 3F 37
1P:  40 A4 41 A5  ...00.0S
2P:  40 A0 40 A0  ...00000

Video Racer Video-Game
PPU latch: 3F 3F 3F 3F 3F
1P:  40 B8 40 B8  .....000
2P:  40 A0 40 A0  ...00000

HVC-101
PPU latch: 3F 3F 3F 3F 0A
1P:  40 B8 40 B8  .....000
2P:  40 A0 40 A0  ...00000


This is with a controller plugged into the NES-101, but no controller plugged into the others, per confirmation in #nesdev. Thanks for the report.

Does the HVC-001 (RF) behave the same as the HVC-101 (AV)?

Because the standard controller has three different appearances, I'm going to guess that the controller variant is the same as the one that shipped with the console:
  • If open bus on $4016 D2 then turn NES controllers into dogbones
  • If open bus on $4016 D3-D4 and both D0 are NES controllers then turn them into RF Famicom controller I and II
  • If open bus on $4016 D3-D4 otherwise then turn NES controllers into dogbones
Re: Riding the open bus
by on (#183936)
I added controller detection, which worked for me. But as I expand this into the controller test that it was always intended to be, I'm not sure what all I'll be able to fit in 64 kbit.
Re: Riding the open bus
by on (#183940)
I don't see any reason to worry about that bridge until you cross it. IMO, really the only reason to support my goofy flashcart is that "I'm usually responsive and it's what I have"—it's not really a good reason to prioritize its functionality.

Rev6 works ok for me.
Re: Riding the open bus
by on (#184266)
Moving right along. After looking through R6 to see what I could cut, I noticed that I had left a duplicate copy of the instructions for interpreting low-level results in lowlevel.s. I cut that out and added input tests for several controllers: NES controller, Famicom controller 2 with microphone, Super NES controller, Power Pad, and Four Score. Tests for the analog controllers will follow in a later version.
Re: Riding the open bus
by on (#184333)
I just bought a U-Force on eBay to see if IR proximity detection is as dumb as the other I.R.

Image
I.R. Baboon from Cartoon Network's I Am Weasel


While waiting for it to arrive, I added tests for Super NES Mouse, Arkanoid Controller, and Zapper. And the plain version (without AA font, controller pictures, or full low-level instructions) still fits in 7.5K ($FDC4-$FFF9 unused). This includes multiplication and square root so that I can calculate speed and acceleration magnitude, BCD to report the results as 3-digit numbers, and the same peak following that I put in Vaus Test.
Re: Riding the open bus
by on (#184349)
This is a very cool program, I like it!
OK here are my test results:


Red & White Famicom (HVC-001):
Main board: 1984 HVC-CPU-07
CPU: RP2A03E (Looped noise works)
PPU: RP2C02E-0 ($2004 is write only, Micro Machines has graphical glitches for this reason)

Everdrive N8:
OS 15, BIOS 5, CPLD 1

All Pads R8 Low-level controller port results:
Code:
PPU readback
     00 FF 00 FF 00 FF 00 FF
PPU latch
              3F 3F 3F 3F 3F
APU open bus
                    40 40 3F


Only built-in controllers:
Code:
      4L 3L 4H 3H D76543210
1P:   40 B8 41 B9  .....00S
2P:   40 A0 41 A1  ...0000S


Famicom Dogbone (HVC-102) in exp port (home-made adapter, D1):
Code:
      4L 3L 4H 3H D76543210
1P:   40 B8 43 BB  .....0SS
2P:   40 A0 41 A1  ...0000S


Capcom Power Stick Fighter (CPS-A10CA) in exp port (included adapter):
Code:
      4L 3L 4H 3H D76543210
1P:   40 B8 43 BB  .....0SS
2P:   40 A0 41 A1  ...0000S


Zapper (NES-005) in exp port (home-made adapter, D4 & D3):
Code:
      4L 3L 4H 3H D76543210
1P:   40 B8 43 B9  .....00S
2P:   48 A8 49 A9  ...0100S


All Pads R8 normal interface:

Only built-in controllers:
Family Computer detected
1P D0 Famicom Controller
2P D0 Famicom Mic Controller
All buttons on both controllers works including controller II mic.

Famicom Dogbone (HVC-102) in exp port (home-made adapter, D1):
Family Computer detected
1P D0 Famicom Controller
1P D1 NES Controller
2P D0 Famicom Mic Controller
All buttons works.

Capcom Power Stick Fighter (CPS-A10CA) in exp port (included adapter):
Family Computer detected
1P D0 Famicom Controller
1P D1 Super NES Controller
2P D0 Famicom Mic Controller
The CPS-Fighter shows buttons L, R, X and A as always pressed. All the other buttons: Up, down, Left, Right, Select, Start, B (remapped to A on the controller) and Y (remapped to B) works like normal. The CPS-Fighter is a SFC controller that comes both with a SFC cable and a Famicom exp port cable, so it remaps B and Y to A and B when using the Famicom cable.

Zapper (NES-005) in exp port (home-made adapter, D4 & D3):
1P D0 Famicom Controller
2P D0 Famicom Mic Controller
2P D4-3 Zapper
I have no CRT to test the Zapper on at the moment but the trigger works (PullTime changes when holding trigger).


I wanted to try the Dogbone controller in D2 as well but it seems I must have made a mistake when I made the NES to EXP port adapter. It doesn't work in any games either, so it's not All Pad's fault. Also I wanted to try unplugging the built-in controllers to test if it detects that, but it's a pain in the butt to do since you have to unscrew a bunch of screws and the plugs on the PCB are hard to unplug. I might try it later sometime though.

Edit: Fixed typos.
Re: Riding the open bus
by on (#184366)
Except for the CPS Fighter, all results were as expected. Thanks for the confirmation.

I own a Capcom Fighter Power Stick, which I take to be the U.S. version of the CPS Fighter. It doesn't have a DA15 for Famicom or a 7-pin cord for NES, but it does have a 7-pin cord for Super NES. I'm using it on my NES through a Super NES to NES cable provided by Infinite NES Lives, and all buttons work as expected. Try plugging the Super Famicom side of your CPS-Fighter into your Famicom's exp port through a homemade adapter that goes to D1.

A normal Famicom controller's report is as follows:
Code:
AB-+udlr 11111111 11111111...


A normal SFC controller's report is as follows:
Code:
BY-+udlr AXLR0000 11111111...


Based on the evidence you've presented so far, the CPS Fighter appears to be doing this:
Code:
BY-+udlr 11110000 11111111...


The 0000 in the low nibble of the second byte triggers detection as SFC, but AXLR are on so that programs using a certain method of DMC glitch avoidance (rereading only when Right is pressed) know when to stop reading. I could make a second tool that displays each serial line's raw report to absolutely confirm this, but if no "standard" controllers are connected, how will the user choose which line to view?

"D2" won't work. It needs to be $4017 D1 for games to recognize it. Was that your mistake?
Re: Riding the open bus
by on (#184393)
I kind of hoped that the CPS-Fighter would show different results. It behaves differently from normal SFC controllers, for example it doesn't work in my SFC multitap (the one that is shaped like Bomberman's face) and I also had problems with it in the past when I tried to use it in my Famicom homebrew I made (I eventually got it to work by improving the controller reading routine, I still have no idea why it didn't work though).

I guess it's time to build a Super Famicom Controller to Famicom Expansion Port Adapter then. I have a spare SNES controller extension cord I can use, but it's missing the Data 3 and 4 pins, they don't seem to be used by the mouse or standard controllers though.
I couldn't find a schematic, but judging from the info from the wiki, I guess it should be wired like this if I want to use two SFC controllers or mouse:
Code:
Controller 1:

 Famicom EXP Plug
      oooo oooo  <-GND
 +5V-> ooooooo|
       ||||   |
       ||\/   |
       ||/\   |
       ||||   |
 +5V->|OOOO|OOO) <-GND

 Super Famicom/NES Controller Port 1 (female)



Controller 2:

 Famicom EXP Plug
   +---+
   |   |
   |  oooo oooo
   |   ooooooo|
   |   |  |  ||
   |   |+-/--+|
   |   ||/    |
   |   |||    |
   |  |OOOO|OOO)
   +------+
 Super Famicom/NES Controller Port 2 (female)


Quote:
I could make a second tool that displays each serial line's raw report to absolutely confirm this, but if no "standard" controllers are connected, how will the user choose which line to view?

I don't understand the question, but usually when there are multiple possible scenarios, I just add options to manually pick all possible combinations in the interface.

Quote:
"D2" won't work. It needs to be $4017 D1 for games to recognize it. Was that your mistake?

Ah yes by D2 I really meant D1 of $2017. It's called DATA(2) on this schematic (the EXP pinout is that of the port side) that I followed when I built it years ago. I tested the pin with a multimeter just now and it appears I have accidently wired it to pin 11 of the DB-15 port instead of pin 7 for some reason. The Zapper worked in the second NES port though, so I guess it doesn't use the con 2 data pin.
Re: Riding the open bus
by on (#184396)
Pokun wrote:
tepples wrote:
I could make a second tool that displays each serial line's raw report to absolutely confirm this, but if no "standard" controllers are connected, how will the user choose which line to view?

I don't understand the question, but usually when there are multiple possible scenarios, I just add options to manually pick all possible combinations in the interface.

But what would the user press to select from among these "options to manually pick all possible combinations in the interface"? If you have "funny" controllers plugged into both ports of an NES Control Deck, where by "funny" I mean not a superset of the NES-004 controller, controller 1 isn't necessarily readable.

Pokun wrote:
The Zapper worked in the second NES port though, so I guess it doesn't use the con 2 data pin.

Zapper uses D4 (trigger) and D3 (light).
Re: Riding the open bus
by on (#184407)
If anyone can confirm that my above-posted schematic of SFC Controller -> FC EXP Port Adapter is correct, I'd be very greatful.

tepples wrote:
Pokun wrote:
tepples wrote:
I could make a second tool that displays each serial line's raw report to absolutely confirm this, but if no "standard" controllers are connected, how will the user choose which line to view?

I don't understand the question, but usually when there are multiple possible scenarios, I just add options to manually pick all possible combinations in the interface.

But what would the user press to select from among these "options to manually pick all possible combinations in the interface"? If you have "funny" controllers plugged into both ports of an NES Control Deck, where by "funny" I mean not a superset of the NES-004 controller, controller 1 isn't necessarily readable.

Oh I see, if the user has an unreadable controller the only way of input is the reset button I guess. You are already using that for that purpose, couldn't you just display all raw data on that low-level screen thingy?

tepples wrote:
Pokun wrote:
The Zapper worked in the second NES port though, so I guess it doesn't use the con 2 data pin.

Zapper uses D4 (trigger) and D3 (light).

Yeah no wonder. Gotta rip the adapter appart and start all over again when I have time.
Re: Riding the open bus
by on (#184417)
Pokun wrote:
if the user has an unreadable controller the only way of input is the reset button I guess. You are already using that for that purpose, couldn't you just display all raw data on that low-level screen thingy?

I'd be interested to see how you would recommend to do that. At the font size I'm using, the title safe area can fit 28x12 characters. Here's the current layout of lowlevel:
Code:
Low-level controller port
probing results
Reset: return; Start: help

PPU readback
     00 FF 00 FF 00 FF 00 FF
PPU latch     3F 3F 3F 3F 3F
APU open bus        40 40 3F

       4L 3L 4H 3H D76543210
1P:    40 A0 41 A1  ...0000S
2P:    40 A0 41 A1  ...0000S


In theory, there could be up to seven serial (S) lines on an AV Famicom: devices in controller ports 1 and 2 (D0 of each), and the five input lines on the expansion port (1P D1, 2P D4-D1). The serial devices I currently support are anywhere from 4-bit (Power Pad part 2) to 32-bit (Super NES Mouse). So in addition to what I already display, I'd need to display 32 bits of data for up to seven lines. What would be a good way to go about that?

(The U-Force is 48-bit, but I'll cross that bridge once it gets to me.)
Re: Riding the open bus
by on (#184499)
In that case I'd probably go with automatic page turning, or just slowly scroll the screen left or down until all data has been displayed, then let it wrap around to the first page again and do it all over again. It must be slow enough for one to be able to copy all bits to a paper, and the bits must probably be numbered. It's a bit annoying to read but if you have no way of input that's the only way I can think of.

Also I don't really get why you bother with a large font like that for a tool like this. I always use a normal 8x8 font I stiched together from various fonts on this forum. I stole the capital letters from Super Mario Bros because it has nice and thick characters that are easy to read on any backdrop color on a CRT using RF even (besides the nostalgia factor of fonts like this), numbers from IBM PC BIOS since they not only goes well with SMB letters, but also have a zero that is easy to distinguish from the O. I based my lower case letters on the IBM PC font but I edited them so they became sans serif for maximum readability (although I usually leave the lower case out of NES programs since they take lots of CHR ROM space and aren't really needed for displaying information). I originally stole katakana from Family BASIC since it has separate dakuten and handakuten characters (as opposed to combining kana with the diacritcial marks as separate characters), but I have since created a new Japanese font based on another kana font, including separate dakuten/handakuten characters that I drew myself.
Re: Riding the open bus
by on (#184512)
But then I realized that I know of only two controllers that plug into both ports at once, namely NES Advantage and NES Four Score. Both are NES-004 supersets. The rest can be tested in port 2, with a standard controller in port 1 controlling the test.

Code:
Serial port watcher
Control Pad: Port/bit
A: Poll rate
Reset: Exit

1P D0 Slow
 1-16: 1000 0000 1111 1111
17-32: 1111 1111 1111 1111
Re: Riding the open bus
by on (#184591)
Doesn't the NES Satellite plug in both, too?
Re: Riding the open bus
by on (#184597)
Satellite = wireless Four Score
Re: Riding the open bus
by on (#184663)
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.
Re: Riding the open bus
by on (#184669)
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.
Re: Riding the open bus
by on (#184670)
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.
Re: Riding the open bus
by on (#184678)
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.
Re: Riding the open bus
by on (#184680)
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.
Re: Riding the open bus
by on (#184707)
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.
Re: Riding the open bus
by on (#184716)
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.
Re: Riding the open bus
by on (#184737)
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.
Re: Riding the open bus
by on (#184740)
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...
Re: Riding the open bus
by on (#184742)
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
by on (#184787)
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
by on (#184789)
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.
Re: Riding the open bus
by on (#237391)
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.