Rambo-1 Test ROMs
Page 1 of 1

Author:  Alyosha_TAS [ Mon Aug 14, 2017 4:58 pm ]
Post subject:  Rambo-1 Test ROMs

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:

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:
  1. 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?
  2. 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.
  3. Does it make any difference whether C001 is written before C000, or vice-versa?
  4. Does writing to E000 or E001 clear the IRQ counter, as Alyosha_TAS suggested?
  5. Are any of the latch value bits written to C000 ignored, as Zepper suggests on the wiki discussion page?
  6. 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?
  7. 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.

Author:  Zepper [ Mon Aug 14, 2017 7:33 pm ]
Post subject:  Re: Rambo-1 Test ROMs

* N is the value written to $C000.

Here my suggestions.

test 1. Trigger an IRQ and see if writing to $E001 acknowledges it. The expected answer should be NO, since it should work like the MMC3 (only $E000 acknowledges it).

test 2. The number of cycles between a $C000 write ($C001 first) and an IRQ. This will answer if the NEXT IRQ will be triggered after N or N+1 cycles (or N | 1).

test 3. The number of cycles between a $C001 write ($C000 first) and an IRQ. This will answer if the NEXT IRQ will be triggered after N cycles.

test 4. Write $FE to $C000, trigger an IRQ; then write $FF to $C000 and trigger an IRQ. This will answer if the last bit is ignored (probably NOT).

Author:  Zepper [ Sat Sep 23, 2017 12:40 pm ]
Post subject:  Re: Rambo-1 Test ROMs

...hello??? :? :?

Author:  Alyosha_TAS [ Mon Sep 25, 2017 3:45 pm ]
Post subject:  Re: Rambo-1 Test ROMs

Zepper wrote:
...hello??? :? :?

I lost both my files and my motivation to work on this, sorry.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group