Home Page Forums MAME MAME The SNES WIP topic

I found the reason of these glitches: a "break;" had disappeared (while I was fixing a regression in Super Street Fighter 2) and we ended up changing the sprite address at the wrong time.

It's unfortunate you haven't noticed it before 0.137, but huge thanks for reporting it now.

Indeed, Super Kick Boxing suffered of the same problem as R-Type 3, but I was pretty sure the latter got broken by my new OAM code. Thanks to your report, I was able to discover that in fact both problems were present since rev.7546 and this helped a lot to spot the real issue and to fix it.

I will never repeat it enough: development and progresses would be way slower without testers.


EDIT: and, to clarify, the R-Type 3 regression which got fixed is the messed up title screen. problems reported in the advanced levels ( http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=59855#Post59855 ) are still there and will need some more debugging.

etabeta78 and byuu :

Thanks for your great effort to make the snes emulation better !

I can't wait for the first complaints now that sprite flickering is implemented (especially since most other (S)NES emulators let you turn it off).

Is there a document that breaks down the master cycles for all of the S-CPU instructions?

Master cycles are based on memory access timing.

You won't find a better algorithm than mine. Even beats full and partial lookup table variants.


As for breaking apart the S-CPU cycles, you should really use the bsnes source code. There is the W65C816S documentation that explains it (only the older version), but it has errors. Especially in WAI and IRQ timing. And it's missing the IRQ edge case condition that converts an I/O cycle into a bus read.

Really, you'll save yourselves two years of fixing IRQ bugs in golf games if you port my S-CPU core instead of writing your own ... but whatever you guys want to do

If you go your own route, you should decide on whether or not you will use cooperative threading. Save states are still possible with it. If you choose not to, you will wish for death upon attempting to implement bus hold delays and proper H/DMA bus synchronization in a state machine. I couldn't do it after 2 years, and the Snes9X team gave up on it as well.

Also, here's the code we have so far for the S-SMP TEST register:
http://board.byuu.org/viewtopic.php?p=12381#p12381

Another gem. There is absolutely no game known, not even in the demo scene, that ever writes anything at all to this register.

Twist my arm ;-)

Seriously, while we won't have cooperative threading initially, it's definitely something Aaron wants to look at. There are a number of 3D systems (e.g. Model 2) where the CPU or DSP is supposed to stall on FIFO reads/writes, and that's basically impossible without cothreads.

Back to my small contributions, I decided to temporarily stop the work on DMA/HDMA [1], and to convert the SNES sound to be a MAME device.

This allows to remove a few static variables and represents a first (small) step towards save states. The code will be added tomorrow morning (I have to review the changes and I'm definitely too tired right now)

Next target for device-fication might be the PPU...

[1] Tokimeki Memorial refuses to work properly as soon as
- I init HDMA according to docs
- I enable HDMA direction bit
- I add indirect transfer edge cases
Given that all 3 things are supposed to happen on the hardware, this means I'm missing something else. In any case, Kale did a wonderful job with the current code, and I only expect this to have a minor impact on the MESS emulation (but of course, there is no reason we should not try to follow Anomie's docs and byuu's source, for accuracy sake )

anomie left before some of my HDMA findings, so I suppose I can tell you what to look out for.

The biggest one is that during an HDMA, all of the effective bytes are written to registers for all eight channels first, and then all eight channels update the line counter and fetch new addresses if necessary. In other words, the write + address fetch for each channel is not interleaved.

The reason for that is so that all of the PPU writes are always inside H-blank, even if you have eight indirect addressed HDMA modes transferring four bytes and reloading them all on the same scanline. Believe it or not, a couple of games need this.

And I think anomie may have updated his doc for this one, but just in case, there's a short-circuit behavior that was a bit trickier than first thought. If you are on the very last active HDMA channel, and it performs an indirect HDMA address load, and the channel is now completed, HDMA does not fetch the high byte of the address. The low byte ends up in the high byte (it's shifted in) and the low byte ends up as 0x00. The part that was determined post-anomie was that it only happens to the very last active HDMA channel for that transfer. Again, this one will break one game if not correct.

You'll probably want proper DMA/HDMA <> CPU synchronization added before doing the above. Because if you're off by ~6-12 cycles on every single transfer anyway, what's 8 more in extreme edge cases going to hurt?


It'll really make your life easier if you want perfect HDMA<>CPU sync timing and bus hold delays

So you may want to hold off on your cycle-CPU until then.

the latest updates fixed the intro logo in Donkey kong country 3!

Still suffers from some priority issues though

and the 32x.

Sega never does something once. Which is why Cool Riders is such an interesting puzzle.