Home Page Forums MAME MAME The SNES WIP topic

That seems to be the case. A few games will break using stock (official spec) speeds:
- American Tail: Fievel Goes West
- Breath of Fire 2: German vocal intro
- Clayfighters supposedly has sound skip issues
- Earthworm Jim 2: European sound effects

Running the S-SMP at 32040*768hz instead of 32000*768hz fixes everything, except R. Belmont is saying there's still some slight issues with Clayfighters.

The first two break if you change CPU<>SMP skew by 768hz more than what I use now.


S-SMP stock is 24576000hz. Clocked at 24606720hz. That's a skew of 30720hz. Which is closer to 1,000ppm skew. In fact, almost all SNES units we've clocked have ended up right around the latter. It seems more like the spec was wrong than all the crystals.


I try and explain this, but people assume that because it worked on at least one SNES, that emulators are flawed if they don't also run it.

There are really flat out *broken* commercial games out there. Death Brade/Blade and this European racer won't work unless you initialize WRAM to non-0x00s. It checks a certain byte without initializing it, and if it's zero, the game doesn't work. Given the variable nature of DRAM on power-on, there's probably a 1:256 chance that will be the case on the real thing.

So, if we know console X can run these titles, and we match its oscillators, then we can rule out clock issues if the games still break in emulation.

Signal is noisy as hell on both pins 72 and 71; freq meter says 2842.888 khz, I think this 4/3 of the actual clock due to some weird harmoinics (clock xtal says D214J1), that would put the clock at 21.32166Mhz which seems awfully low...
Maybe I need to run it through a bandpass or something...

EDIT: with the more low-tech non 10:1 probe i get a much cleaner signal, but its still showing as 2842.888khz for clock. now that i can see the waveform i see why its getting confused, there are two places where the slope is appropriate for triggering the edge sensor...

LN

r5432 /src/mame/video/snes.c: [SNES]: Fixed a blending bug involving main/sub color maths

brilliant!!!!

I hope to be able to fix my hardware problems (my macbook died at last), and to come back to give my small contributions... but you're doing a much better work! (see my silly mode 7 direct color mistake )

It's not about mistakes calculations, it's just to go forward. And I've did a mistake with direct color calcs too (see r5431).

Anyway...new OPT cases (both gfx mode 2):

Dead Dance, Rolf stage (6):

(rocket actually moves with the sprite)

Super Double Dragon, later in the stage 1:

(there's actually another elevator on the right, people enters from the glass "hole")

Still don't have a plan for OPT

Try different GND point - I'd go with pin #79 and then try something closer to the oscillator circuit if it's not clean enough. If that is still too noisy you can try bleeding the signal to ground a bit (with 100-1k pulldown resistor), this will lower the amplitude of course but it tends to eat up any parasite signals faster than the main one so it might just work.

Well, keep in mind the PAL CPU supposedly runs at 21281370hz. Another thing we need tested. But yeah, 21321660hz breaks Earthworm Jim 2 (U)'s sound effects, so that's probably not right.

What are the relevant crystals/CMOS oscillators actually rated at? (On a real board, not in theory

r5434 /src/mame/video/snes.c: [SNES]: Fixed interlace mode gfxs when not in gfx modes 5/6

Found that Ranma Nibunnoichi - Chonai Gekitou Hen / Street Combat uses interlace without hires, aspect ratio on screenshots is shitty as the rest of the game...



(Now the SNES Test program stars sprites are identical when switches from non interlace to interlace, dunno at the current time how they squeeze in half like bsnes does)

what about the black square moving in front of the stars?