Quote:
When it comes to the NES, I'm just a programmer/developer, not an EE guy. Spouting off random pin labels (e.g. /ROMSEL) doesn't tell me anything or help educate me. :-)
/ROMSEL is the signal which is typically configured to enable the PRG ROM. Its condition for being true is when the CPU is accessing $8000-FFFF and the CPU is in the part of the clock cycle where data is allowed into /driven from the 6502's internal data bus from/to external memory.
koitsu wrote:
I'm not sure if I'm being dense (highly likely) or you misread what kyuusaku said, but:
kyuusaku wrote:
What if a game comes along with readable mapper registers in $8000-FFFF? Pretty much every emulator would have to be significantly reworked.
Pretend for a few minutes that the system didn't have $4018-7FFF unmapped, or that the PRG ROM was only mapped to a small amount of address space, let's say 16KiB of it. Also assume that the more significant address lines A14 and A15 were not routed to carts to save pins. In both of these cases readable registers like FDS status and data registers for example would have HAD to share the PRG ROM's memory space.
Address decoding can be cascaded (take the ROM enable signal which itself is derived from typically the most significant address lines, then perform arithmetic on it and less significant address lines to further partition the memory). If the FDS status register bits and PRG ROM (and/or RAM in the FDS' case) had to share memory, the address decoder would turn the one ROM enable into one ROM enable and one status register enable which would be connected to a
tri-state buffer component. Hell, an address decoder could turn the signal into 16,384 enable signals for 1 byte ROMs (or tri-state buffers manually wired to 0s and 1s) and there would be no address lines to further decode. That of course would be ridiculous, but possible.
Going back to the real memory map, it is not so ridiculous for a cartridge to map a register or registers to $8000-FFFF (or more likely $8000-BFFF) because it may simplify the address decoding logic by reusing the /ROMSEL signal which must be routed to the cartridge regardless. There's not much of a benefit to this over $6000-7FFF since it can be decoded easily enough with a single, common, small and inexpensive IC AND it would allow your code to grow over 16 KiB, but this is all theory.
In the case of the Game Genie, it has cool programmable address decoders, one for each patch code. Instead of the binary decoders typically used on a couple address lines, it has comparators that decode the full address range like that 1 byte ROM idea, but instead of the data coming from a ROM or buffer, it comes from a register holding the patch data.
With my emulator's memory system in place, if I wanted to I could low level emulate the Game Genie, or several cascaded, by cascading memory fetch functions from one Game Genie to the next and then to the game cartridge. Sure it'd be stupid and slow compared to hooking memory like a normal cheat system, but it can be done, just like on the real thing. The benefits extend beyond the theoretical though; most importantly all mapper logic, irrespective of how complex (woo PowerPak emulation, FPGA and all), can be encapsulated within a few functions and I don't need to come up with equally complex and cumbersome code to fix MMC2/3/4/5/6 raster effects because my PPU code fetches memory again like the hardware. As someone familiar with hardware, who's a bit OCD yet lazy and overall a pretty poor programmer, this approach suits me well.