nesdev.org

I want to create a device that will sit between the the cartridge and the console. While it's purpose is different, I believe the connections it would need would be the same as a Game Genie. My big issue is finding an FPGA board with enough pins for the whole cartridge in and out. So my question is: would any issues be caused by only having the pins I need go through the FPGA while the rest go straight to the console?

Depends on what exactly you're doing, but yes, it's probably OK to just bypass signals you don't care about. (e.g. the Game Genie ignores most of the PPU address bus)

Long explanation short, I just want to intercept APU commands so that the NES doesn't get them.

Uh... that's partially doable but tricksy and may pose compatibility problems.

You'll have to rewrite the instruction that would be STx $40xx to be something else, but you won't know what instruction it would be until the final byte of the instruction (the upper byte of the address) is being fetched. At that point you'll be able to replace the upper byte with something else "safe", but what byte counts as safe depends on the specific cartridge.

Furthermore, some games write to the APU using indirect pointers (e.g. STx (zp,x)) and there will be no way at all for you to intercept those writes.

Could I not just check the Axx pins for a $40xx address? I was thinking of just sending zeros on the data signals, but hadn't really looked into it yet.

Side question: Would data going from the cart to the CPU be a high or a low on CPU R/W?

EDIT: Looked at the APU wiki page. Could I keep $4015 at 0 and let the rest of the signals through?

Trainmaster2 wrote: ↑Sun Jan 12, 2020 3:24 pm Could I not just check the Axx pins for a $40xx address? I was thinking of just sending zeros on the data signals, but hadn't really looked into it yet.

No. The APU is inside the same physical piece of silicon that holds the CPU, and electrically isolated from the outside world. When the CPU writes to an APU address, the write happens entirely internally... and that write is additionally copied to the outside world. But nothing that happens to the outside world (bus conflict or otherwise) can affect the value written to the APU register.

Side question: Would data going from the cart to the CPU be a high or a low on CPU R/W?

"Reads" are the process by which the CPU (or DMA unit) fetches data from the cart (or NES-internal RAM or PPU).

Would there be anyway to just keep $4015 at 0?

The only option without getting ridiculously complicated is what I said in the first place: wait for the easily-caught instructions that would write to $4015:
byte: $8C-8F
byte: $15
byte: $40
replace that final byte with some other byte that's "safe". $44 should be compatible with the vast majority of software.

After reading those three bytes, the 2A03 will always immediately write the relevant register's value to whatever address it fetched. You can't adjust the value that it writes: the APU isn't in a place that you can get "between" it and the CPU.

Well darn. This is a project I've had interest in for a while. I do, however, have an idea for an alternate design.

and that write is additionally copied to the outside world.

Could a more permanent solution be to insert a device into the NES that can read the write from outside the CPU for the data and intercept and disable AD1 and AD2 to mute the audio?

Under what conditions would you mute/unmute the NES audio?

The full project is I want to ultimately create a midi output. Muting the audio is just an idea so that the APU output cannot be heard but sound from the cartridge could still be heard if I wanted to use the midi audio live. Just reread the wiki page and saw that the 72 pin connectors do not have this option.

Would I be correct in guessing that to read the APU commands, I could insert a device between the cart and console (for removability) and check for CPU R/W to be write and Axx to be be a $40xx address. Now that I know that NES carts don't seem to be able to provide their own audio (at least not straight from the cart) I'm only focused on receiving the audio commands and can just mute the TV.

Maybe this will give you some ideas:
viewtopic.php?f=9&t=17715&start=15#p224858

Yeah, sure, you can just listen in on all the writes that the CPU is doing. Everything will be relayed to the outside world.

The only relevant exception is when the CPU tries to read from $4015. You won't be able to see what value it reads.

Results may be lackluster; I remember someone mentioning an ancient emulator that had similar functionality with mediocre results due to the disconnect between "the exact values written to the APU registers" and "the corresponding musical score"

One last question. Now that I would no longer interfering with the data going to the NES, do you think a microcontroller would be fast enough?