16-bit pointers on the SPC-700

[psycopathicteen]

I agree with all of the above. The not so "straight forward" part of what I said is that for data to end up in the direct page, it almost always has to take the detour through an actual CPU register. Pushing/popping stuff between direct page and the stack quickly eats up cycles.

I'm glad I don't need to pass parameters all that often.

[dalton]

Thanks for all your replies! Very helpful and interesting to read.

[Optiroc]

I wish emulators hand an option for opcode statistics when a running game; record the occurrence rate of each opcode.

That would be super easy to add to bsnes+ (and any other emulator, of course, but bsnes+ is a good candidate since the debugging side is in good shape and very malleable). I'm not sure what I'd do with the info, but my interest is piqued nontheless... (:

Some opcodes look great, but if they're not particular useful or used in most iterations that make up the larger chunks of resource, then they won't have much of an impact regardless of how nice they are to use. In such cases, macros serve the same purpose on lesser processors.

Maybe true, but I'm quite sure that most console cpu/graphics/audio features that have been overlooked over the years have had such a fate more of "not worth the hassle" reasons. The Saturn had simply astonishing audio features, but why would any commercial developer put any significant resources into that? Precisely that makes obscure and underused features more interesting to me, today.

The SPC700 was snappy enough for its tasks most of the time to make any significant optimizations and changing of habits rather moot. But if you, today, want to add software synthesis to a music engine you can't be sloppy with those cpu cycles and those new direct page addressing modes are certainly worth exploring for optimization opportunities.