Home Page Forums MAME MAME The SNES WIP topic

This is working now.

everything is possible, but I doubt it's a rom mapping fault. I double checked the mapping and it seems fine (same as bsnes I mean). I could have overlooked something, of course...

fwiw, if it calls bank1_r (as you mentioned in the shoutbox), then it's trying to access "banks" 0x00-0x20 or 0x80-0xa0 (the latter is covered by bank6_r, but for most cases this calls bank1_r). in both cases 0x7fff is either reserved or DSP1/2/3/4 (but this game does not have special chips, iirc)

EDIT: ok, Reserved memory should fall back to open bus (as in bsnes and as explained at http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=52896#Post52896 ). it does not fix Accelebrid, but it should be an improvement to accuracy. hence, I'm going to commit this change soon

EDIT2: added to svn

Okay, I've written some tests to understand this HDMA-MDR behavior more: http://byuu.org/temp/test_mdrhdma2.zip

The good news is that we don't have a serious problem with bus timing nor HDMA execution order.

The bad news is that the behavior is flat out nonsense. In my first example, HDMA really does fetch before the S-CPU opcode cycle, and yet the subsequent open bus result is the HDMA fetch and not the S-CPU opcode fetch.

We can simulate it with some really fucked up code, but I would love to understand how the hell this is possible on a hardware level.

Also, an interesting side discovery came out of this: it wasn't storing the HDMA read value in MDR, it was storing the next HDMA counter value, even though a fetch wasn't at all needed (continuous HDMA mode was active with a high counter value.)

What this means is that for each active channel, it always fetches the next line value from the HDMA table. It will only actually use it and increment the HDMA address if the current line counter & 0x7f == 0, of course.

Makes sense from a hardware perspective, it's essentially saying there is no idle cycle, it's actually reading memory while checking the line counter at the same time.

It may explain the short-circuit behavior of HDMA indirect behaviors a bit better, but I haven't fully contrasted this finding with that one, yet.

Probably the open bus function gets faulty here ... I'm aware it's not 100% correct, but as usual it's a *cough* MAME core design quirk ...

fwiw, writing something like:
if(offset == 0x60d5) value = 0x60;
there "fixes" the problem.

Ok, I'm going thru topic hunting here for looking old and new issues ... first off Super Bases Loaded 3 / Super Moero Pro Yakyu now gives this clever message after the Jaleco logo:



I wonder what broke this ...

Copy protection is usually limited to checking that the save RAM size is correct and mirrors properly. Given the hardware there's not much else you *can* check.

it got broken by some open_bus change, I guess. I tested the game two days ago and it was working (still with the window mask bug present).

now I'm going to see a movie. I'll look for the fix it as soon as I'm back, if Kale does not find it before then

as a temporary workaround, it's enough to replace some "return open_bus_read" I added this morning in snes_bankN_r (N=1,...,7) with "return 0xff". it seems at least one of them was wrong...

Super Tetris 3 does the copy protection too:



(this screen looks neat anyway ^^U)

That makes sense, byuu mentioned some copiers would "eat" the open bus value. And that is a cool looking screen

Super Metroid has some famous anti-copier disclaimer as well (I triggered it once, while playing with SRAM mapping, almost 2 years ago)

However, it turned out to be a SRAM problem: I had changed the way SRAM is counted at start (in snescart.c), but I forgot to updated bank handlers accordingly, so those games ended up with 1024 times more SRAM than they should have... fixed now.

let me know if there is any other game which fails protection checks