nesdev.org

The bonus levels of DKC1 are far more "banana-" [actually, a substitute: miniature animal-buddy statue-] intensive, so one grid = one object makes sense. (DYDDY on save screen to have easy access).

So are bananas essentially treated like coins in the Super Mario Bros. games?

I'm suprised you can't change the sprite vram bank address during hblank.

psycopathicteen wrote:I'm suprised you can't change the sprite vram bank address during hblank.

Like I said, you can on my SNES, unless I've gravely misunderstood something.

Anyone who wants to can download my test code and try it. PLEASE DO, as this is critical information for my game, and I can't tell for sure if my console is a 1CHIP or not...

...it's got a printed EJECT label, a molded FCC label, and two feet on a heavily yellowed bottom half; there's no locking tab hooked to the power button but there is a warning sticker, the gap beside the expansion port shows two dots and the edge of a ring on a green background, and the serial number is UN231084565...

...

Also, if you think this test is a softball - ie: that it could be giving me a false positive - please speak up. I have limited hobby time, but if a better test is necessary, so be it. I need to know this.

Sorry if I was giving misleading information, but the banana bunches count as objects, where the banana groups and bananas singular don't count toward the object limit at all.

This is a banana bunch:



Whereas a banana group would be like if a bunch of singular floating bananas were arranged into a "3" shape or something. When I was talking about the banana limit, I was talking about the entire level, (which I think I remember changes level to level) not just how many bananas appear on screen. Like I said, I think a banana group only counts as one banana toward the level limit, so I'd imagine it's the same way for what's on screen. I remember I was goofing off and I filled an entire banana grid and filled the whole screen with them, and not all of them would appear (possibly sprite limit) or even be able to interact with the player, so they really didn't even spawn.

93143 wrote:Anyone who wants to can download my test code and try it. PLEASE DO, as this is critical information for my game, and I can't tell for sure if my console is a 1CHIP or not...

I've tested this on two SNES consoles (I can open them up to verify PCB model if needed, but I believe neither are 1CHIP): a UN24xx ad a UN25xx. ROM was run via an SD2SNES adapter. I'm not sure what exactly I'm looking for, other than a sprite changing colour (as it moves down the screen), gradually from red to green, starting at a specific screen scanline. I see no other behaviour and no oddities, no matter where I place the sprite.

P.S. -- I'm happy to alpha/beta test anything you need, just lemme know in a thread somewhere or drop me a PM if you need for something to remain private (incl. special ROM builds, etc.).

koitsu wrote:

93143 wrote:Anyone who wants to can download my test code and try it. PLEASE DO, as this is critical information for my game, and I can't tell for sure if my console is a 1CHIP or not...

I've tested this on two SNES consoles (I can open them up to verify PCB model if needed, but I believe neither are 1CHIP): a UN24xx ad a UN25xx. ROM was run via an SD2SNES adapter. I'm not sure what exactly I'm looking for, other than a sprite changing colour (as it moves down the screen), gradually from red to green, starting at a specific screen scanline. I see no other behaviour and no oddities, no matter where I place the sprite.

That's exactly what's supposed to happen, and if it worked on two consoles, great! (If you open it with a vram viewer, you can see 2 different colored squares, so it isn't a palette swap.) Do you know what version your consoles are? You can see if you have the SNES Lion King game. (There's some sort of secret menu, but I don't remember how to access it. It should be easy to look up.)

I put it in my SNES PowerPak on a launch console (CPU:1 PPU1:1 PPU2:1), and it showed a red square that turns into a half red and half green square and then a green square as I move it up and down.

From The Lion King on TCRF: Open the options menu and press the B, A, R, R, Y buttons.

The red/green sprite thingy works on my SFC-TV.

Red on top half, green on bottom half of screen.

1 : 1 : 1 USA Launch Console.

Thanks for all the help! This is looking very promising.

By way of explanation: the first entry in OAM is the only one on the screen, and it uses palette #0. There are two sprite tiles in VRAM; a red one (referencing palette #0) at $0000 and a green one at $2000. An HDMA channel is set to write to OBSEL; at the top of the screen it writes $00, and halfway down it writes $01. Only the bottom two bytes in OAM are ever changed, and at no point is CGRAM touched. The idea is that when the square turns green, it is switching from the primary sprite table being at $0000 to the primary sprite table being at $2000.

So I'm not testing the behaviour of the second table's offset, just the first table's position. I should probably tweak it to test the offset too. But it's still encouraging that the name base seems to behave as expected on multiple revisions - if I had to guess, I'd say both my scheme and Espozo's idea should work.

Does anyone see any holes in my test protocol, other than what I just noted?

...

It does still bug me that higan doesn't work... have we really stumbled onto something ZSNES gets right and bsnes doesn't?

...

Re: Lion King - if I'm not mistaken, a 1CHIP will still report itself as a 2/1/3. There are physical telltales, but I don't know of a way to find out for sure without taking it apart.

93143 wrote:It does still bug me that higan doesn't work... have we really stumbled onto something ZSNES gets right and bsnes doesn't?

I have a version of BSNES that said it was made on 6/26/2010 and it works, but it doesn't give a product version when I look under "properties".

I have bsnes v072 (10/25/2010) and higan v094 (the latest, 1/20/2014). The former works (except for the top scanline in accuracy core); the latter doesn't (it behaves exactly like v072 but with the colours flipped).

93143 wrote:I should probably tweak it to test the offset too.

...well, that didn't take very long. I should have just done it earlier.

New feature - pressing one of the four face buttons will switch sprite #0 between the main and secondary sprite tables, by writing the appropriate value to OAM during VBlank. The HDMA now sets OBSEL to $08 at the top of the screen, meaning it picks up the green square at $2000 when it's using the secondary table above the split. But it still sets it to $01 halfway down, which means it picks up a yellow square at $3000 when using the secondary table below the split.

Works on my SNES. And this time it works in higan too (except for that top scanline in the accuracy core)...

EDIT: As might have been expected, the mid-screen split also happens one scanline lower in the accuracy core. So it's a timing issue...? Does higan cache the sprite graphics one scanline early as well as the OAM data? I just stared at my TV at close range for a bit, and it looks like there are indeed 8 scanlines worth of red tile when the program first starts up...

On the subject of fiddling with stuff midframe, has anybody actually tried to update the OAM during hblank? I know the oam address gets left at the hioam byte of the last sprite rendered, but can you manually change the oam address to where you want it? Sorry if this has already been tested, I am just frustrated with the way SNES sprites are laid out. I just want to use a huge load of 8x8s, like an NES on steroids.