Ok, so in order to split this from Zepper's RockNES thread I am making this one to discuss what tests need to be run to characterize Rambo-1 IRQs.
I've already started on the test ROM infrastructure, so I want to get an idea what the first test is that should be run.
so far I have this to start from:
Does anyone else have any ideas on what needs to be tested to EXACTLY characterize what's happening here?
My current idea for a testing criteria is to simply manually read the upper nametable address space to get PPUA12 exactly when we want it. The result will be a screen color or something simple indicating how many clocks exactly passed. Then once we've nailed down the basics we can start timing things relative to the PPU accesses.
I've already started on the test ROM infrastructure, so I want to get an idea what the first test is that should be run.
so far I have this to start from:
NewRisingSun wrote:
I'd say kevtris or James might be the persons to ask for hardware testing. I suggest the following initial list of things to investigate:
- Can it be confirmed that under normal circumstances, in scanline mode, writing 0 to C000 and C001 returns in exactly one IRQ being asserted not at the next A12 rise, but the one after that, as Kevin Horton describes?
- Can circumstances be found under which writing 0 to C001 and C000 causes the IRQ to be asserted at the next A12 rise after all, and not at the one after that? That's what Hard Drivin' needs. Its IRQ handler that does such a thing starts at PC $FDB4. Circumstances could include the order in which registers are written to, or the timing of the register writes relative to what's happening on the A12 line.
- Does it make any difference whether C001 is written before C000, or vice-versa?
- Does writing to E000 or E001 clear the IRQ counter, as Alyosha_TAS suggested?
- Are any of the latch value bits written to C000 ignored, as Zepper suggests on the wiki discussion page?
- Is the prescaler in CPU cycle mode actually cleared every time when writing to C001, as the wiki claims? Is it cleared even when scanline mode is selected?
- Does anything funny happen when switching from CPU cycle to scanline mode? An earlier version of puNES' source code seems to suggest that when switching form M2 to A12 mode, the next M2 falling edge will still clock the chip even as the chip is already in scanline mode (variable tengen_rambo.irq_force_clock in puNES' mapper_Tengen.c, not in the current source code version, tough).
Does anyone else have any ideas on what needs to be tested to EXACTLY characterize what's happening here?
My current idea for a testing criteria is to simply manually read the upper nametable address space to get PPUA12 exactly when we want it. The result will be a screen color or something simple indicating how many clocks exactly passed. Then once we've nailed down the basics we can start timing things relative to the PPU accesses.
