Home Page Forums MAME MAME The SNES WIP topic

in fact, since last August, the structure between MESS and BSNES is more similar than it was before: BSNES rendering design was so elegant and simple that I modified MESS to work the same way, rendering one mode after the other and calling a common set of functions for each mode.

the main difference is that BSNES handles directly each single pixel (making "easier" to implement effects like offset-per-tile) while MESS does not (and hence OPT is still missing).

That said, moving the whole video emulation to a device in order to better sync things is probably a good idea... just don't count on me to do it (in the short term) because I keep being a bit busy with real life

*fixed*, why you don't put yourself in that since you started the video emulation logic and I've simply followed your logic?
In my humble opinion, I don't think that our snes codebase it THAT hard to follow. Problem is that we need good plans to fix the remaining issues that are: mosaic effects, OPT and the obj limit flag (the latter actually shouldn't be in the video code in the MAME/MESS logic anyway), that's all. All the rest is machine/timing related plus small quirks here and there...

I didn't say that they sucked, I said that I ran away from it because its architecture was way outside of my comfort zone. If anyone or anything sucks, it's my ability to read unfamiliar code.

I'm just saying, as far as the code's structure, it seems unfamiliar to me, and could possibly stand a code clean-up pass - for example, the debug switches to turn layers on and off do not appear to work.

iirc, they got broken when we passed in video_update from


to


(notice the y+1). I've never gone back to fix them

r5865 /src/mame/machine/snes.c: [SNES]: Fixed an incorrectly setted DMA register read, fixes DMA Memory in the test cartridge




Just three errors now. As a result, Clay Fighter and NHL '9x are working again.





(and don't ask to me why people should use an undefined DMA register bit as RAM, guess is again a SNES compiler issue....)

Clay Fighter and NHL 9x put the inner loop of their sprite decompression in the DMA registers so it runs 3.58 MHz instead of 2.6.

Why not use my renderer entirely? It should be almost as fast as others (the bottleneck is in S-CPU IRQ processing), and it's feature-complete. No worries about color add/sub bugs, mosaic, OPT, Mode7 EXTBG, glitched sprite height in interlace mode, etc etc.

Only the S-CPU and S-SMP rely on cothreads, you can easily detach the ~6 lines regarding them from the current renderer and use it in a state machine.


I use DMA registers for JMP (indirect) inside proportional font routines. Say you want to move a line of a letter six places over:

Or:

Can't use $0000-1fff because the game itself may be using them, plus it's slower to access than $43xx.

$43xb (and its mirror, $43xf) make nice temporary storage registers. I kind of wish $43xb-$43xf were all valid, ah well.


That's unfortunate. Darren and I were hoping MESS would take the torch eventually. At any rate, I think you'll reconsider when compatibility reaches >99%. I've had games break because I was off by literally a single cycle. Yes, being off by 6hz a frame at 21477272hz caused Mortal Kombat II to go crazy, it was just barely missing an IRQ.

And what some of these bastardized games do with IRQ and NMI should be a crime. There's a half-dozen games that only work because of a severe edge case involving the pipeline, the six-clock /IRQ and /NMI line holding delay, and a strange case where it keeps the acknowledge bit set during that time across reads. And if you don't get it right, games will deadlock on you.

You're right that they are forgiving, but only in one direction. Some games break if you're a little too slow, but not if you're way too fast, and vice versa. With over 4,000 games it's very hard to get them all working at the same time without being perfect.

What RB said. It's not a SNES compiler issue, it was pretty well-known that unused DMA registers can be treated as RAM, and have a faster access time for such speed-critical things as, say, streaming the vocals in Clay Fighter's music.

and I thought I'd dealt with things which were fussy over timing ...

the Megadrive is much more forgiving, I think the only real case where implementing the delays between register write and effect even matter on that is Sesame Street. (which is lucky, because there really is no comprehensive, verified, guide to the timing on that anywhere)

I do wonder how well any of this will work in MAME/MESS tho, I seem to remember slight fluctuations in the timing between frames due to slight precision errors and rounding last time I tried to do anything (which was a long time ago..)

I think we should take it eventually. But I also think we have a fairly long way to go otherwise before we consider that. The steps as I'd imagine them are like this (not necessarily in this exact order, although #4 obviously goes last):

1) Master cycle-based 65c816 so all operations and memory accesses take the correct number of master cycles
2) Audit SPC700 for cycle accuracy
3) Fix remaining rendering issues (offset-per-tile, range over, tile over, mosaic). Maybe we do just use the bsnes code - there's a fairly compelling story there, but are we willing to completely trash what we have?
4) Once cothreads are added to the MAME core (Aaron is interested, but I don't know what all would be involved), go ahead and schedule the 65c816, spc700, and video correctly