As I was going through NesCartDB and made my was here, I took a close look at the pictures on the PCBs.
In all 5 samples in the collection,the /IRQ pin isn't connected to anything. So it shouldn't be able to request interrupts. But this is the mapper that explicitly is supposed to have IRQs.
Just to check occam's razer, I went and disabled Nestopia's hash database and changed the mapper number back. And it didn't work; it did require the interrupts, despite that there seems to be no way for the hardware to signal them.
Except that the mapper could inject BRKs. If this is the case, given the actual hardware, it should be possible to detect because: 1- the code shouldn't be able to signal a pseudo-interrupt if code is running not on the cartridge, barring bus conflicts and 2- should be visible in the stack while in an interrupt. But that's ludicrously complicated, since there is an IRQ acknowledge behavior. Suddenly it has to maintain a very complex FSM just to decide whether or not the interrupt needs to be re-issued when the interrupt ends, it has to know when instructions hit their edge such that injecting a BRK is ok, it has to rewind across the injected BRK, and these pseudo-interrupts can't be enabled or disabled by the cli/sti instructions.
Doesn't seem likely.
Am I missing something? How do you drive the pin low without being connected to it? Is there a via I don't see?
p.s. additionally utterly bizarre: Look at the chr-rom pins. What should be D4 seems to be connected to+5Vground. This is not consistent with the datasheet for the part number.
In all 5 samples in the collection,the /IRQ pin isn't connected to anything. So it shouldn't be able to request interrupts. But this is the mapper that explicitly is supposed to have IRQs.
Just to check occam's razer, I went and disabled Nestopia's hash database and changed the mapper number back. And it didn't work; it did require the interrupts, despite that there seems to be no way for the hardware to signal them.
Except that the mapper could inject BRKs. If this is the case, given the actual hardware, it should be possible to detect because: 1- the code shouldn't be able to signal a pseudo-interrupt if code is running not on the cartridge, barring bus conflicts and 2- should be visible in the stack while in an interrupt. But that's ludicrously complicated, since there is an IRQ acknowledge behavior. Suddenly it has to maintain a very complex FSM just to decide whether or not the interrupt needs to be re-issued when the interrupt ends, it has to know when instructions hit their edge such that injecting a BRK is ok, it has to rewind across the injected BRK, and these pseudo-interrupts can't be enabled or disabled by the cli/sti instructions.
Doesn't seem likely.
Am I missing something? How do you drive the pin low without being connected to it? Is there a via I don't see?
p.s. additionally utterly bizarre: Look at the chr-rom pins. What should be D4 seems to be connected to