Several meta sprites on screen

Hello, I'm using cc65 for developing SNES game (please do not comment on cc65 as I know it does not use full capabilities of SNES).

I'm having problem on putting several meta sprites on screen simultaneously. I'm sure they are properly loaded to ROM and VRAM and when I try to draw one meta sprite everything goes smoothly, but as I increase number of meta sprites some weird stuff starts to happen. (garbage on screen, joypad controlls do not work, some background tiles on screen are missing, .... ).

The function which I'm using is called oam_meta_spr() from nes.h header file (https://github.com/clbr/neslib/blob/master/neslib.h)
For every meta sprite I'm calling this function again each one after another. (several consecutive calls)

Also I've noticed when I'm using that function to draw meta sprites on snes9x with debbuger everything is shown properly but on the no$sns emulator the meta sprites are not shown at all.

Any thoughts on this subject? Anyone experienced the same kind of problems with different emulators?

That is a nes Lib, I'm honestly surprised it got you that far. I would imagine you can't really use it and you need a SNES lib, unless it has some hidden SNES support mode? But from what you are describing, its sounds like it is trashing the wrong registers/locations in VRAM, which would be expected if it is using the NES values.

Yeah, it can be done using that lib, everything else I've used so far worked without any problems. That's why I'm assuming that nothing is wrong with the library. I could be wrong. (The lib that I have is reduced, I assume those functions that are left out do not work on snes)

Post the asm of the library you are using. The one in the link above is NES specific.

(it might be .s or .asm or .sinc)

If you really are using the NES library, then you probably aren't initializing the SNES correctly, among other things.

He's using a MegaCat-internal SNES port of that; it can't be posted here.

Then we won't be able to answer any questions.

Something like that.

I'm more interested in second part of my question: has anyone experienced different outcomes on different emulators.

Yes.

Usually it's some unusual or complex thing or something that requires exact timing that is different between emulators. Just showing simple sprites should work across every emulator.

Try it on Higan/BSNES on the "accuracy" setting.

Try bsnes-plus, it includes a very thorough debugger and both standard and accuracy executables.

When something that is conceptually simple gives different results across various emulators, that usually means something isn't structured right, and even slight variations in timing (which different emulators have) can cause certain operations to happen at the wrong times.

Slight timing variations are expected to cause issues in code that exploits obscure hardware quirks to achieve results that aren't typical of the machine, but "normal" programs that are well within the boundaries of what the machine can do have plenty of time to do things safely.

Debugging your programs step-by-step is the best way to tell if everything is happening at the correct times.

It's hard to say with this little information, but my guess is that you're running out of vblank time. Certain things like VRAM can only be written to during vblank, so if your code takes too long, you won't be able to draw everything.

variance in emulators is potentially massive. It depends on how accurate an emulator is. When you get into things that don't "play by the rules", such as reading from the open bus, obscure combinations of registers, I would expect them to vary wildly.

ZSNES will let a lot slide and not do a bunch of things. SNES9X won't handle this or that, bsnes will show flaws that the others don't.

Nicole's guess is a good one, my other guess is that one emulator "inits things with random values" and the other "sets everything to 0". And you're code doesn't set something to 0 like it should.

With a help of a friend he found a solution: my lorom was set to be 256kb and the banks I used for storing sprite tiles were invalid. Simply putting them in lower banks solved the problem with emulators.

Even when I changed ROM size the problem with storing data in banks 0x90+ persists. If I load anything to them and try to write that on screen I get garbage (and also inspecting the bank I can see that the data is not loaded properly to it).

Let's say I've set 512kb ROM size that should give me 512 * 1024 / 32768 = 16 banks

And that should be banks from 0x80 - 0x95. But still I have problems with banks 0x90+.
Looking at memory map
(https://en.m.wikibooks.org/wiki/Super_N ... _map#LoROM ) those banks should be free to use.

Any thoughts on this issue? Maybe I need to initialize them in some way beside changing ROM size (but that would mean that the banks 0x88 and 0x89 are initialized in the way I don't see in my .cfg file ) ?

Prior to realizing the ROM size was smaller than I needed it to be I've used those banks 0x88 and 0x89 without any problem and I still use them that way now that the size is changed.

16 banks = 0x10.

That means you can access the ROM either by bank numbers 0 - 0x0f or 0x80 - 0x8f.*

There isn't a bank 0x90, if your ROM size is 512k.

*Edit, just to clarify, that's a mirror of 0 - 0x0f.

I really don't know what I was thinking...

EDIT: but this still does not explains how I managed to use banks 0x88 and 0x89 when ROM size was 256kb

A 256 KiB LoROM connects CPU A18-A16 to ROM A17-A15 and leaves A19 and up not connected.* This makes banks $88, $90, $98, ... mirrors of $80, and banks $89, $91, $99, ... mirrors of $81. Emulators and flash carts that don't handle this mirroring might get this wrong.


* I'm assuming it's not using the upper address bits as active low chip selects.