Skull & Crossbones - Split Screen Shakes - Nestopia

Under Nestopia (Undead) 1.45 (and older versions), as well as the (un)official releases (I.E. 1.40-1.42), when you split the screen by starting the second player in Skull & Crossbones in-game, the bottom portion shakes and there's some graphic corruption.

The ROM dump, per Nestopia's launcher shows it as a "Good" dump. Presuming then, it's an emulation issue (?)

Trying Nintendulator (Aug 10, 2014 beta), there's some minor graphic corruption (Just below 2nd player/"RED DOG" status info), but no shaking screen with the 2nd players enabled utilizing the same ROM.

I don't think we understood exactly how the RAMBO-1's IRQ worked until James tested recently, which postdated the original author abdication. Rdanbrook has probably not had this pointed out to him yet?

Just opened this ticket for him. :-)

Also for lidnariq: check out the Discussion part of the RAMBO-1 Wiki page please. Zepper proposed a different methodology that may help with Hard Drivin' and no real follow-up to that discussion took place (at least on the Wiki). If it took place here on the forums, if you could find me the discussion that would be great.

Wait for fixed

Sorry to bring this back up but i think i found another bug with this mapper and shinobi on nestopia.

Everything is fine until you get to the last set of levels. The masked ninja set on the bamboo forest level the mirroring becomes screwed up on sideways scrolling. I opened this ticket on rdanbrook :

https://github.com/rdanbrook/nestopia/issues/181

Could these 2 games be related with the issues? They are both mapper 64, unless i am crazy here. Everything starts off fine in that level until you get about midway then the scrolling issues start and the next level seems to be screwed too.

I wonder if there's an easy fix for this or maybe its related to the database entry for shinobi.

I hope it helps. All the games work with no glitches.

-edited- Code removed.
Please, read the wiki discussion page!

Thanks zepper, is this a patch for nestopia or code that you are using in your own emulator?

Nope. Just the info you'll need to the proper fix. The IRQ isn't triggered when the counter expires. It'll trigger after 4 CPU cycles.

Im currently parsing through the nestopia source and I see the source file NstBoardTengenRambo1.cpp. Maybe I can get someone to help me a little bit, its very difficult to parse where to put a patch. And thanks again zepper for posting the code, guess its a matter of deciphering what goes where with what you posted.

Sorry for the double post, im looking through nestopia undeads source to try to do this myself,

https://github.com/rdanbrook/nestopia/b ... Rambo1.cpp

if you scroll down to this part:

if (!count && enabled) {
/* wait one M2 cycle, then trigger IRQ */
return true;

do i just need to wait 3 more cycles or am i way off? I never claimed to be an expert but am trying my best here.

I believe this is dragon2snows experimental code, but im not seeing where i can actually change the cycle count to 4. This also might explain why part of the odometer is cut off in hard drivin.

Argh... fine. I'll take a look later... and make the necessary changes in the code. You should be able to do that, by the way.

ahh zepper. You rock man! And yes, im a noob but I am trying.

Hey zepper, do you know by chance if this might help fix the top of the odometer missing in hard drivin?

Hey Zepper, am I still lucky enough to get your help with this? If not, that's obviously ok. Just figured I would check.

Sorry, I'm definitely unfamiliar with nestopia code style.

Thanks zepper, no worries. Just to clarify I did not mean the odometer from hard drivin, it was about the shinobi patch.

Who can provide the real machine video for skull & crossbones.
or provide real machine video for all mapper 64 game;

I try fix.......

http://v.youku.com/v_show/id_XMTYzMDQzMzMxNg==.html

is working fine?

is this your video dragon? Have you been able to successfully fix this or something? This is obviously one of your builds (nestopia plus) so can you share your fix?

I've updated my mapper 64 IRQ code. It was broken, so Hard Drivin' now works as it should be.
The wiki has been updated with this information.

I'm having trouble understanding that code. In particular, when is irq_rambo1 called? Every M2 cycle, with ppuflag set when at the end of a scanline? Then why is the //IRQ reset part in there, when according to the updated wiki, the IRQ reload business should be happening at the end of a scanline, not every M2 cycle.

As far as a glitch-free performance is concerned, here are a few things to look out for in Skull & Crossbones:

Correct (according to these real-machine-captured videos: 1, 2):

Wrong:


Look for a rogue scanline above the status bar in the left picture, a garbled "CONTINUES" lettering in the middle picture, and the level selection rectangle being one scanline off in the right picture. I have never seen an emulator that could get all three right AND run Hard Drivin' glitch-free (This video shows that at least during Hard Drivin's title screen, the top scanline of the lower part of the screen should be cut off.) Does your emulator manage to do that?

Here is a real-machine-captured video of the two-player mode, and what glitches should be expected (none, except some jitter at the far right side of the screen in the scanline directly below the status bar).

FWIW, for S&C there is a garbage scanline in both of the flash carts, but the item and level selection screens are correct. Hard Drivin is a glitchy mess below the driving portion of the screen in both.

At every CPU cycle, or 3 PPU cycles (NTSC), like you do with any other PPU IRQs, such as MMC3.

Correct, read it again. Once the IRQ counter is zero, wait for 4 CPU cycles, then trigger an IRQ. This isn't an hack, as it was already confirmed.

The current public version has broken IRQs for mapper 64. The unreleased version has fixed such issue.

I believe Shinobi may have similar corruption on the last line of the in-game status bar

Is there any emulator available today that can demonstrate the accurate RAMBO-1 IRQ behavior?

Not to my knowledge. As I mentioned before, no current emulator gets all screens of Skulls and Crossbones right. We'll see how that revised RockNES code actually performs once it is released.

Here's a pre-release of my emulator.
Download it.

Thank-you. Using that pre-release build of RockNES, while Hard Driving works, as you described, Skull & Crossbones still has some glitches:

Corrupt "CONTINUES" in item screen, background one scanline off against selection:


Background off by one scanline against selection on level select screen:


Refer to the videos I linked to in my earlier post for proof that the actual cartridge does not produce these errors.

And why do you think that is?IRQ?

I couldn't suit both games in a standard IRQ operation. If I fix Skull & Crossbones, then Hard Drivin' is glitched, and so on.

EDIT: it seems they do NOT use a same board..!?
S&C requires the IRQ to clock only after reset, next clock ($C001 write).
HD' requires the IRQ to clock immediately after reset ($C001 write).

You may want to ask Frank Cifaldi/TheRedEye over at LostLevels.org for a board shot.

Actually, the current info regarding RAMBO-1 IRQs is... wrong. I've updated the wiki (discussion page) with my suggestion of how it should work. Of course, I'm guessing and... it's working better than ever.

Is Kevtris around to analyse a RAMBO-1 board and its IRQ timing, like in the old days? He did even a RE of the mapper 90 IRQs!

I believe I have figured out how RAMBO-1 IRQ timing works.

http://wiki.nesdev.com/w/index.php/Talk ... IRQ_timing

Is this still accurate information Zepper? Nestopia is very close to this IRQ in the undead implementation, and i would like to implement the rest of it if it is.

writes to $E001: irq_enable=true; IRQ acknowledge by CPU.

Nestopia was missing this in $E001 and i added it, but it does not seem like hard drivin works correctly with this. Can you confirm?

What is the collateral effect?

Well i need to do a little more testing but using that write to $E001: (irq_enable=true; IRQ acknowledge by CPU) makes hard drivin lose it's status bar before passing through the first gate.

At the moment, i am using Zxbdragon's implementation of code from when he added support for hard drivin. This code here:



After looking through what is posted on the talk link for the proper behavior, it is somewhat similar to that but not quite the same. One problem i am running into is not being able to outright add the line for irq_delay firing after 4 cycles due to the level of abstraction. In the hpp file for NstTengenRambo1.hpp i do see this though:



So maybe i can just change that to 4 there after fixing the line of code above. One thing to note is martin's original code for this are used to be this:

Here's my current C code.

I'll keep messing with it, thanks for posting that up zepper, but is this info still accurate?:

http://wiki.nesdev.com/w/index.php/Talk ... IRQ_timing

It's a try-and-error result.