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:

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.

Author:

tepples [ Thu Mar 26, 2015 7:49 pm ]

Post subject:

Re: Riding the open bus

Quote:

So one could only detect the adapter as a whole, not which controllers are actually connected

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.

Author:

lidnariq [ Thu Mar 26, 2015 8:19 pm ]

Post subject:

Re: Riding the open bus

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.

Author:

AWal [ Tue Mar 31, 2015 6:48 pm ]

Post subject:

Signal Circuit; Freemium clone of Open Bus Rider; In Stores

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.

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.

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.

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)

Author:

tepples [ Tue Nov 29, 2016 4:10 pm ]

Post subject:

Re: Riding the open bus

Bit 7 appearing driven may be the result of a bug in the test. 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?

Author:

lidnariq [ Tue Nov 29, 2016 5:08 pm ]

Post subject:

Re: Riding the open bus

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.

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.

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.