nesdev.com

Thanks.


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

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:

That is correct.


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


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


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.


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.

I figured as much.


FC Twin transcribed:

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?


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.

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.

Better to do both and provide a torrent hash?

_________________
Idealogical
From: I have an idea. It seems logical. Thus everyone must agree.

Fail, fail, fail again. Keep trying, then maybe this damn thing will work. Eventually you might even know why it worked.

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)

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?

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.

Yup, that works as intended.
Same NES-001 with removed CIC as before.

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.

Here is the output from a Top Loading NES w/HDMI mod.