Basically, the whole problem is whether after a C001 write, the IRQ counter should be loaded with the latch +1 or with the unmodified latch.

The NesDev RAMBO-1 wiki article claimed, based on experiments, that it's always +1, although it admitted to a lack of knowledge on where the +1 comes from. Nocash/Kevin Horton claim the same.Klax wants always +1 as well.Hard Drivin' on the other hand always needs the unmodified latch value.Skull & Crossbones generally wants latch +1 except for the IRQ just above the status line.

I thought I was onto something when I observed that Hard Drivin' writes first to C001 and then to C000, while S&C writes to C000 first and then to C001. But Klax turns out to mix both methods, yet consistently wants +1.

Of course we cannot rule out that there are different revisions of the Rambo 1 chip that behave differently. If I understand the Japanese description of that Hard Drivin' video I linked to earlier correctly however, the guy modified a Skull & Crossbones board to put Hard Drivin on it, which speaks against that theory.

Edit: And this guy of course put Hard Drivin' on a Klax board, so I think we can shelve the the hardware revision theory.

Last edited by NewRisingSun on Wed Aug 02, 2017 8:52 am, edited 4 times in total.

From the Rambo-1 games on NesCartDB there's two kinds of PCBs, one with an extra logic chip and one without. Mapper chip has same markings on all.Skull and Crossbones and Klax don't have the chip, Shinobi, Rolling Thunder and Road Runner have a 74x32 on them.In addition to this, S&C and Road Runner have a jumper in different spot compared to others.

Attached find a Nintendulator source file that runs both Skull & Crossbones, Hard Drivin', Rolling Thunder (U.S. version) and Xybots like in the various videos I posted. Basically, I am making two assumptions that are not described in the wiki:

It's not IRQcounter=IRQlatch +1, but IRQcounter=IRQlatch |1.

The |1 part is only done if the write sequence is C000 C001 E001 (as in Skull & Crossbones). If the write sequence is C001 C000 E001 (as in Hard Drivin'), then the IRQcounter is loaded with the unmodified IRQlatch.

These two assumptions should be testable with real hardware.

This strikes me as being unlikely to be the physical implmenentation.

I tried myself to see if I could get any good results using different assumptions.

Here were my assumptions:

1. always use latch+12. IRQCounter decrements immediately when reloaded via C0013. writes to E000 clear IRQcounter as well, and thus a decrement from zero will also load latch + 1 but this will look like just latch

Using these assumptions I got Skull and crossbones and Klax to work glitch free, Hard Drivin has a blue line on the driving sections above the timer, and rolling thunder status bar moves up by 1 scanline when I shoot.

Have you checked all of the glitch candidates I posted here? When you use always latch +0 or always latch +1, you'll either get the garbage line above the status bar (visible only once you scroll down in the introductory level), or corrupted "continue" lettering in the item screen.

I think at this point definite answers from more direct experimentation with the chip are needed. The first thing to study would be to find out the specific circumstances in which writing 0 to both $C000 and $C001 will result in IRQ at the very next clock, instead of the clock after that, as found in previous experiments. This is the main thing that is important for getting Hard Drivin' working without breaking other games.

Have you checked all of the glitch candidates I posted here? When you use always latch +0 or always latch +1, you'll either get the garbage line above the status bar (visible only once you scroll down in the introductory level), or corrupted "continue" lettering in the item screen.

I think at this point definite answers from more direct experimentation with the chip are needed. The first thing to study would be to find out the specific circumstances in which writing 0 to both $C000 and $C001 will result in IRQ at the very next clock, instead of the clock after that, as found in previous experiments. This is the main thing that is important for getting Hard Drivin' working without breaking other games.

Ah, you're right the glitch line in the item screen is there. Well back to the drawing board i guess.

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?

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).

EDIT: as side note, using irq_latch ORed with 1 reduces the glitched area in Klax to 1 scanline only, though it STILL requires irq_latch+1 to work properly, glitch free. As a collateral effect, Hard Drivin' becomes glitched by 1 scanline... and interesting enough, the panel vanishes during the gameplay if the IRQ timing (down counting result) is off by -1. In short words, I couldn't get BOTH games working perfectly. If I fix Klax, then HD' becomes glitched, and so on. I tried to carefully re-read the description by Kevin Horton, but the results weren't good, as the games were really off by +2. The only interesting part is about irq_latch!=0, when the irq_counter must be ORed with 1. Perhaps it's another race condition with $2006..? Still, is the irq_counterreally counting downward rather than upward, as I had suggested?

EDIT: as side note, using irq_latch ORed with 1 reduces the glitched area in Klax to 1 scanline only, though it STILL requires irq_latch+1 to work properly, glitch free. As a collateral effect, Hard Drivin' becomes glitched by 1 scanline... and interesting enough, the panel vanishes during the gameplay if the IRQ timing (down counting result) is off by -1. In short words, I couldn't get BOTH games working perfectly. If I fix Klax, then HD' becomes glitched, and so on. I tried to carefully re-read the description by Kevin Horton, but the results weren't good, as the games were really off by +2. The only interesting part is about irq_latch!=0, when the irq_counter must be ORed with 1. Perhaps it's another race condition with $2006..? Still, is the irq_counterreally counting downward rather than upward, as I had suggested?

We have seen how Klax is supposed to work on a real cartridge, but no one has ever seen how Hard Drivin' is supposed to work on real hardware, right? Maybe HD does have a minor 1-scanline glitch that they did not resolve in the prototype.

The panel colors are different. There's some yellow-ish on it. Other than that, well, no surprises until then. Both games work with no glitches, but is the exact same board? As I said, Klax requires +1, but HD doesn't.

The panel colors are different. There's some yellow-ish on it. Other than that, well, no surprises until then. Both games work with no glitches, but is the exact same board? As I said, Klax requires +1, but HD doesn't.

How rare are these carts? I'd be willing to pitch in some money towards getting them in the hands of someone who can do some exhaustive hardware testing and pinning down the exact behaviour. Maybe they are slightly different? Maybe the behaviour is still more complicated then we expect?

It would be nice to be able to wrap this issue up definitively and move on. This has wasted the time of numerous devs already with inconclusive results.

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum