I already got the PCBs for the first approach (didn't have time to implement the improvements yet) and they work perfect!
But suddenly I noticed something more that could be optimized: even though the boards work, shouldn't they also work without using Phi2? (since #PRG is supposed to be A15 NAND Phi2, so Phi2 line is already present when using #PRG without having to explicitly use it again).
I might remove the Phi2 signal from U6, replacing it with a connection to VCC, and see what happens.
Will this mapper 113 implementation work?
Moderator: Moderators
Re: Will this mapper 113 implementation work?
For mapper 113, don't you need M2 to to distinguish writes to $4100-$5FFF from writes to $C100-$DFFF?
Re: Will this mapper 113 implementation work?
If the game's well behaved, it may never write to addresses above $8000, and so he might technically be able to get away without decoding /ROMSEL.
And because, on a write cycle, all of the address lines, data lines, and R/W are driven at about the same time ... well, it might work if you ignore M2, too, basically just detecting any moment where A14=A8=1 and A13=0. There's even established (accidental) precedent for this, on the hardware for mappers 38 and 86.
Anyway, you already have the PCB, with the routing complete; what would you gain from omitting that trace?
And because, on a write cycle, all of the address lines, data lines, and R/W are driven at about the same time ... well, it might work if you ignore M2, too, basically just detecting any moment where A14=A8=1 and A13=0. There's even established (accidental) precedent for this, on the hardware for mappers 38 and 86.
Anyway, you already have the PCB, with the routing complete; what would you gain from omitting that trace?
Re: Will this mapper 113 implementation work?
You are right, I have nothing to gain on this PCB, but was asking just in case I decide to do a future revision (or just for learning purposes). But maybe it's better to be safe and leave it as is.
Thanks for feedback!
Thanks for feedback!