tepples wrote:
I haven't made an FDS version of my own test because I lack a Famicom and FDS with which to test it. But I'm interested in doing so. Is it easy to port NROM cart programs to FDS?
NROM is easy because you only need one disk side so you can just copy your code with very few changes. It's mostly about making the disk and file headers which are explained in the wiki. The wiki is a bit lacking in the FDS department, but I think Rainwarrior did some improvements lately. For the actual main program, the only changes I know that you need to make from an NROM are the following:
1) Three NMI vectors are needed, although you only need to use one handler.
2) Part of stack is used by the BIOS and the last 11 zero page registers are BIOS variables. These can't be touched when clearing RAM or things will break (not sure about the stack pointer though). The first 16 zero page registers are also used as temporary variables. As I understand it they can be cleared and used as you please, but if BIOS calls are used, they may be used by those as well.
3) Mirroring at boot is set to horizontal by the BIOS. You need to change this at $4025 if you want vertical. It's normally changed by ANDing the BIOS variable $FA, which contains the value last written to $4025, then writing it to $4025 (or maybe there is a BIOS call for it not mentioned in the wiki).
4) Interrupt handlers needs to push processor status to stack besides the accumulator and index registers.
Then it's just the problem of linking the files into a disk. The program file should load to $6000 and the vectors needs to be placed so they land at $DFF6. I couldn't solve this using normal asm6 directives, so I instead assembled each disk file separately and had a header source file that includes the assembled disk files as binaries and then assembled the header last. If anyone has a better idea I'm willing to hear it, but from what I can tell it looks like other people did something similar. For ca65 it seems simpler as it uses a linker normally. Rainwarrior's example shows how to do that (even how to skip the KYODAKU-file).
Now when the retrogaming market has crashed, Famicoms are quite cheap again. The FDS RAM-Adapter and FDSStick are also cheap. Maybe it's good timing to get one and add expansion audio capabilities to Pently and keyboard and microphone testing to Allpads.
lidnariq wrote:All the technical information we've been able to find about it (Hori's Multitap) requires access to a signal that's simply not possible via the FC expansion port—namely, player 1 serial input—so I have no idea how they work.
There's also HAL's JoyPair. It appears to have been designed to let someone plug two single player #3 peripheral (i.e. the JoyBall) into both ports and be able to use them as players #3 and #4. I assume Hori's Twin Adapter is identical.
I see, I don't even know what games are using these 4 controller multitaps.
JoyPair and Twin Adapter sounds like adapters that uses the standard way for connecting external controllers (which is what my program tests). Just like those controllers that has a 15 pin port for forwarding the connection to $4017 D1 so another controller can be daisy chained.
tepples wrote:I just tested it on my NES Four Score. The only odd thing I found is that the displayed state of the Select button on any controller doesn't change while the B button on the same controller is held.
Thanks for testing!
Oh you are right! That's a bug I missed. Strange, I thought I had tried all possible and impossible kinds of button combinations already.
Now this is puzzling,

B is processed right before SELECT but there is nothing different in how these buttons are processed from how any of the others are. Each button indicator lamp is a unique sprite entry in OAM, and should not be affected by each other.