SpritesMind.Net

Hi!

As you can check in this video (9:56), Fusion 3.63 or Regen 0.95, among others, fails to render the title logo as real HW.

Are somebody aware of this issue?

Very interesting... looks like a "standard" raster effect but it's not as it doesn't work properly in any emulator so far. PAL and NTSC version doesn't behave the same in emulator...

Here's a hack-fix for Fusion (v3.64, currently) (works with Gens, too):

Sunset Riders (E) [!]
===============
00018E:4F06 (checksum fix)
0004CA:8016

As for the technicals:

In the H-INT routine, The value for the byte at $FFB062 is $4F = V-counter value at time of V-INT [$E0] + $6F. (FWIW, $6F = NTSC line count [$E0] / 2 - 1)

Obviously, disabling H-INTs around the screen's 1/3 mark doesn't make much sense (hence, the hack). Note that the game operates with the HV-counter latch mode enabled. So, either H-INTs aren't actually being disabled by the reg write at @0004C8, or the latch mode is doing something unexpected.

*EDIT*

If anyone with a flash cart cares to indulge me, I created a hack patch for the game as an experiment. Download the IPS patch here. It requires the PAL version ("Sunset Riders (E) [!]", as named by GoodGen), but the patch makes it region-free, in case that's helpful.

(FYI, if you're looking for an IPS patcher [for XP], I used ipsXP.)

How to use the hack: Run it and tell me the #1 high score. (I know, it's silly )

Nice catch, seems like there will always be room to improve emulator accuracy

I think that when the HV latch bit is set , HV counter is frozen under normal conditions (that is unless there is a transition on the TH controller input, which is normally used by lightguns).

It's documented that way for the SMS VDP by the way (Hcounter is frozen under normal condition) and it's probably the explanation: as long as HVC Latch bit is set, V counter returns a fixed value (the value at the time the bit was set maybe ?) and the jump condition is never met.

EDIT: that's it, adding proper handling of the HVC latch bit (i.e latching H and V counter when VDP reg #0 bit 1 is set) fixed it

That doesn't sound right. From what I understand, the counter is frozen when the VDP's /HL pin (input from the I/O chip) is held low. Not to say that it can't freeze otherwise, but under normal conditions, it should keep on running.

Assuming there's no issue with the counter, I'm thinking that the H-INTs keep coming because the VDP doesn't react well with interrupts on every line. Either that or the H-INT bit change doesn't take effect until the VBLANK.

I was trying to figure out the intent of the code's use of the V-counter, but that seems quite futile. I'm pretty sure it was botched.

Many games use hint on each line without problems, and i'm pretty sure i've seen games enabling or disabling hint mid-frame on purpose... i guess it would be easy to test the latch thing to clear that up but the official doc somehow says the M3 bit stops HV Counter when set and enable HVC read when cleared, which seems to indicate reads do not function normally when set...

Eke wrote:Many games use hint on each line without problems, and i'm pretty sure i've seen games enabling or disabling hint mid-frame on purpose...

Have you seen any that does both? Well, whatever it is, it's not usual. That much is clear.

Eke wrote:the official doc somehow says the M3 bit stops HV Counter when set and enable HVC read when cleared

It also says,

HV COUNTER

The HV Counter's function is to give the horizontal and vertical location of the television beam. If the "M3" Bit of Register #0 is set, the HV Counter will then freeze when trigger signal HL goes high, as well as triggering a level 2 interrupt.

Of course, HL is an active-low signal, but same diff.

I just tested my retail copy (PAL version) on my Mega Drive 2 and a Pro Action Replay with the following codes:

00BE00:8004
00C038:8004
00C044:8014
00018E:4EF0

which basically clear the M3 (HVC Latch) bit everytime the game tries to set it (at least up to the intro)

As expected, the intro now behaves like on emulators so this issue is definitively something related to this bit being set.


EDIT: here's a modified version of Charles MacDonald VCounter test program, which force the HVC latch bit to be set. It will hangs on blue screen if VC values does not change. Can someone test it on real hardware, simply press START to run the default 320x224 test (hopefully I will soon receive my Everdrive cart so I will finally be able to test all the weird stuff I'm asking )

http://www.mediafire.com/download.php?z2kmd5mkezt

Pressing START on 320x224 gives me a solid blue screen on my CDX. You then have to reset the machine.

Thank you very much.

So this confirms V Counter (and probably H Counter) reads are locked as long as M3 bit is set and new values are latched each time the /HL input is asserted from high to low.
This mean HV counters are still running internally, it's just the value returned on read that is the last latched value.

If you think about it, it's logical: guns only assert TH low during the time they detect the pixel beam, which is a very short period so it does not seem very efficient to unlock Hcounter when TH is set high again, this basically defeats the whole purpose of HVC latch.