Rambo-1 Test ROMs

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Rambo-1 Test ROMs

Post by Alyosha_TAS »

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.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Rambo-1 Test ROMs

Post by Zepper »

* 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).
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Rambo-1 Test ROMs

Post by Zepper »

...hello??? :? :?
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: Rambo-1 Test ROMs

Post by Alyosha_TAS »

Zepper wrote:...hello??? :? :?
I lost both my files and my motivation to work on this, sorry.
Post Reply