Mapper 48's IRQ is stated as being generated later than on the MMC3, but there is more: It seems impossible to get the IRQs to fire at the correct scanline in both The Jetsons: Cogswell's Caper's title screen and The Flintstones: The Rescue of Dino&Hoppy's status bar, either one will be off by one. The wiki page advises to XOR the latch value with FF to get the MMC3 equivalent value, which indicates that Taito's chip counts up, not down. When counting up, there is always the question of raising the IRQ when the counter reaches $FF (similar to the Namco 163's CPU Cycle counter) or when it wraps from $FF to $00. I noticed that Flintstones works well when raising the IRQ at counter $FF, while Jetsons works well when raising the IRQ at the time that the counter wraps (plus a delay of at least six CPU cycles, not four as the wiki states). This may be a coincidence, but it is the sort of thing that one would expect from a chip revision. If this hypothesis could be tested with the chips found in cartridges of both games, and confirmed, then a submapper could be allocated to indicate the IRQ counter behavior.
Given my understanding of how the PPU fetch cadence works, I don't see how that would change anything.
If my assumption about the connectivity is correct, namely it only passes through values when it's not fetching from the PPU's bus, then any random $2006 writes would pass through and clock the counter unhelpfully.
If I'm misreading it, and it's only transparent during PPU reads, then yes that would keep writes to $2006 during blanking from incorrectly clocking the counter...
I am unsuccessfully trying to wrap my head around what exactly it means when you are only passing through values when the PPU is NOT reading, and what the purpose of such a thing would be. Unless the game is writing, won't the address that is then passed on just be what the PPU was reading from earlier? So is it basically just a delay?lidnariq wrote:If my assumption about the connectivity is correct, namely it only passes through values when it's not fetching from the PPU's bus
That is exactly where I'm getting stuck also.NewRisingSun wrote:and what the purpose of such a thing would be.
Writing vs not isn't relevant here... PPU /WR definitely does not proceed from the card edge.Unless the game is writing,
I'm not even convinced it's a delay? Beyond the standard 74LS TTL propagation delay, anyway. Which may have been accidentally enough for whatever they needed.So is it basically just a delay?
The only signals in the area at all are PPU/RD, CIRAM A10, and CHR banking outputs A12, A15, A16.
On real hardware (NTSC console) Flintstones run fine. I swapped the EPROMs for the ones with pre-programmed Jetsons ROMs and there is the scanline artifact (see attached videos).
The TC0690 pinout on this particular cartridge is following.
Code: Select all
_____ n/c -- /01 64\ -- n/c n/c -- /02 63\ -- n/c CHR A15 <- /03 (o) 62\ -> CHR A16 PPU /RD <- /04 61\ -> CHR A11 CHR A18 <- /05 60\ -- n/c CHR A10 <- /06 59\ -- GND PPU A12MUX -> /07 58\ <- CPU D3 PPU A11 -> /08 57\ -- VCC VCC -- /09 56\ <- CPU D2 PPU A10 -> /10 55\ <- CPU D4 GND -- /11 54\ <- CPU D1 CHR A13 -> /12 53\ <- CPU D5 PPU A13MUX -> /13 TAITO TC0690FMI 52\ -- n/c CHR A14 <- /14 51/ -- n/c CHR A12 <- /15 50/ -- n/c CIRAM A10 <- /16 49/ -- n/c CHR A17 <- /17 48/ <- CPU D0 n/c -- /18 47/ <- CPU A1 n/c -- /19 46/ <- CPU D6 n/c -- \20 45/ <- CPU A0 /IRQ <- \21 44/ <- CPU D7 /ROMSEL -> \22 43/ -- GND PRG /CE <- \23 42/ -> CHR /CE CPU R/W -> \24 41/ -- VCC VCC -- \25 40/ <- M2 PRG A15 <- \26 39/ -- n/c GND -- \27 38/ -> PRG A17 PRG A13 <- \28 37/ <- CPU A13 CPU A14 -> \29 36/ -> PRG A18 PRG A16 <- \30 35/ -> PRG A14 n/c -- \31 34/ -- n/c n/c -- \32 33/ -- n/c \ / \ /
* 1, 2, 18, 19, 20, 31, 32, 33, 34, 39, 49, 50, 51, 52, 60, 63, 64 - no signs of any internal connection (multimeter diode test to GND/VCC)
* 5 - CHR A18 (because TC0690 does not ignore D0 unlike MMC3 when setting 2k CHR banks, it is possible to access 512kB CHR memory but only using 2k banks)
* 36 - PRG A18
IRQ seems to behave differently that in the MMC3:
Code: Select all
048 - MMC3 --------------- $C000 $C000 irq latch $C001 $C001 irq reload $C002 $E001 irq en $C003 $E000 irq dis
Code: Select all
if falling_edge(PPU_/RD) if PPU_A13 = 0 AND LAST_PPU_A12 = 1 AND PPU_A12 = 0 if (IRQ_counter = 255) IRQ_pending <= 1; end if; IRQ_counter++; end if; LAST_PPU_A12 <= PPU_A12 end if
* IRQ is asserted immediatelly if IRQ_pending flag is set AND IRQs_are_enabled
* It is impossible to tell if the IRQ_counter is reloaded instantly when writing to C001 or when falling edge of PPU /RD (but that does not matter)
* Only writing to C001 clears the IRQ_pending flag (dislabling IRQs doesn't)
* IRQ counter reacts only when there is a PPU A12 transition at $0000-$1fff and only during PPU reads (because the external 74157 mux prevents chip from seeing actual PPU A12/A13 values during PPU write cycles)
* IRQ counter does not checks for M2 when determining if two A12 transitions are too close to each other
Edit: The blurry togemet screenshot Great Hierophant linked to that purports to show that the scanline is not glitched on real hardware when using the real Jetsons cartridge no longer seems to be online.
Interesting that they retained that functionality from the TC0190. Too bad there's no obvious way to change CHR A18 for the 1KB banks.krzysiobal wrote:* 5 - CHR A18 (because TC0690 does not ignore D0 unlike MMC3 when setting 2k CHR banks, it is possible to access 512kB CHR memory but only using 2k banks)
Am I still misreading the PCB? While /PPURD is high, doesn't PPU A12 go through continuously? The value is only in the feedback path while /PPURD is low, right?* IRQ counter reacts only when there is a PPU A12 transition at $0000-$1fff and only during PPU reads (because the external 74157 mux prevents chip from seeing actual PPU A12/A13 values during PPU write cycles)
This is also weird, because in the above-linked thread, Sour said that* Only writing to C001 clears the IRQ_pending flag (dislabling IRQs doesn't)
Sour wrote:that one time I spent hours on that Flintstones game. FYI, the game also requires that writing to $C000 acknowledges the IRQ, otherwise one specific portion of a later stage in the game is bugged