Home Page Forums MAME MAME The SNES WIP topic

etabeta78: will you also look at the div/mul implementation for mame/mess?

I have been away in the weekend. once I manage to commit OAM progresses, I will definitely look into byuu's and blargg's new findings.

but aren't the new findings mainly CPU related? if so, maybe Arbee wants to take care of them (to avoid breaking apple2gs in MESS)

Which new findings? ADC/SBC has already been committed.

isn't mul/div being worked on as well?

http://board.byuu.org/viewtopic.php?f=16&t=569&start=0

mul/div are SNES hardware, not CPU instructions.

my bad. I must have misread some of byuu's posts here, and I while I was traveling I wasn't able to follow the discussion on bsnes board.

I'll take a look when I can.

in the meanwhile, both r-type 3 and super kick boxing have sprite issues. my first series of OAM updates won't fix them (even if they will finally implement proper sprite limits in MESS), but I'm looking for a fix. hopefully, I will find it soon

I also discovered an edge case with my implementation in v062.

It seems a lot of games are really good at parallelizing, and will write to $4202, $4204 and $4205 immediately after writing to $4203 and $4206.

What happens is when you write to $4203 and $4206, it caches the current values (WRMPYA + WRMPYB or WRDIVA + WRDIVB), and then each stage of the ALU doesn't actually employ a variable bit-shifter (obviously), but shifts those temporary values by one place each time. In other words, the internal values get decimated after the computation is complete; hence the need for the internal variables.

I guess programmers realized this and took advantage of it to edge out a little more speed.

You'll need to support this, or Seiken Densetsu 3 and Winter Gold, to name two, glitch in certain areas.

Lastly, I understand the importance of adding these things, especially while my knowledge about them is strong and I can help. But things like MUL/DIV are only going to cause new bugs, and not fix any games. With the problems you guys are having with general CPU timing, PPU rendering, etc ... it may not be the best idea to be going after these extreme edge cases, heh. I mean, there's hundreds of these things. Still, I'm happy to assist if you want this added now.

You assume we care about playing games, personally I think breaking emulator detection is way cooler

Poorly worded. I meant there are behaviors that are more important, as evidenced by the fact that a lot more software relies upon them.

Okay, I wrote this up to help you guys out:
http://board.byuu.org/viewtopic.php?f=16&t=576

And blargg's tests are here:
http://byuu.org/temp/muldiv_tests.zip

There's additional research from what was mentioned previously, but it should now comprise 100% of all possible edge cases. Eg writes during computation, reads of RDDIV inside multiplication (yes, it actually updates that too), and full cycle stepping validation.

You're definitely going to need your core broken into individual cycles (eg no word reads), but it doesn't need external synchronization between cycles. Just call the alu_edge() function between each cycle and you should be good.

which means that it will take a while

let me fix OAM and slightly clean up dma/hdma, then I will see if I can get closer to bsnes about mul/div as well.