nesdev.com

Not particularly weird considering that the size of each OAM entry is 4 bytes.

Exactly, so why multiply the address by 2? (I'm recalling now that it was actually 2 because that's what made it seem weird to me.)

By the way, I actually have no right to try to help here. I'm probably confusing you more. It's been 5+ years since I've done anything with the SNES.

I'm just frustrated. I just got my running shoes (everdrive) in the mail, and want to go for a jog, and then i spend 4 hours trying to tie my shoes (and failing).

_________________
nesdoug.com -- blog/tutorial on programming for the NES

You seem to be writing sprites in a straight forward way. Maybe try DMAing the sprites from a copy in RAM? Not sure if those "tutorials" have been depreciated yet or not though.

I got it to work.

I wrote to the low table, but then no follow up to the high table, thus the low table was never updated, my sprites didn't appear.

Ok, I feel better.

Edit, I think I misunderstood the wiki above, but somehow, rewriting the entire OAM (low and high) fixed it, and sprites are showing. Perhaps leaving the OAM address set mid-way screws things up.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

Yet you couldn't resist the urge to spread disinformation in the very same post?

Of course you don't multiply by 2 to index into an array of data structures of size 4.

2 what? 4 what?

To clarify things, I applied dimensional analysis. I searched superfamicom.org's page about MMIO ports for "word address", and it turns out VRAM, OAM, and CGRAM are all addressed in 16-bit units. Such address registers behave as if they multiply the address by 2 bytes per word. Thus accessing data structures of size 4 bytes per element requires multiplying the index by 2 words per element, not 4 bytes per element.

But in practice, it's more common to write to OAM using DMA from a display list in a memory that's byte-addressed, namely WRAM. For this, you do need 4 bytes per element.

At least I tried to help?

No need to be snarky.

BTW, thanks tepples for clearing that up.

Think of the high table as a separate chip that is only accessed with addresses 512..543. Only the lower table has a latch that buffers writes.

See anomie's regs.txt (e.g. on RHDN) for details.

I was still having tons of problems, bugs, making me very angry... I think I fixed it... my bad init code says this...

sep #$20 ;a 8
rep #$10 ;i 16
...
lda #$00
tcd

But, TCD transfers low AND high byte of A+B, regardless of processor status, and the value of A is not know at startup, so I was storing a random value for the high byte of the Direct Page Register.

correct init code should be...

rep #$30 ;a 16 i 16
lda #$0000
tcd


Ok, hopefully, I can get this stupid first test program up and running soon.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

Well, or
sep #$20
lda #0
xba
lda #0
tcd

Also, the 65816 datasheet says D is set to 0 on reset (although I suppose it's possible that this is not true for the 5a22?)

I assume this is still running on the Everdrive, in which case that's probably not a safe assumption.

Yes, I'm running on an Everdrive.

Here's the code that IS working on the Everdrive. Slight changes, the background auto-scrolls left (during NMI, let's me know that NMI is firing correctly). And, Controller Reads, Up/Down/Left/Right moves one of the sprites (outside of NMI, let's me know program is running outside NMI correctly).

http://dl.dropboxusercontent.com/s/n93a ... ello11.zip

Improvement still needed, pushing unused sprites offscreen. You can see them in the top left corner. I can't seem to find any documentation on this. Perhaps a Y value of $ff would do it?


Hey, should I also do this on INIT?
lda #00
pha
plb ; set the data bank to 0

EDIT: link updated to push unused sprites to Y = $f0.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

Yeah, sorry about lashing out a bit there. Especially since you stating "multiplying by either 4 or 2" is technically exactly true depending if you want the word or byte offset. (Then, of course, not having an OAM shadow buffer in RAM and DMA it during vblank is rather bonkers, so it didn't even cross my mind that you might want to use the word offset.)

Sometimes I just get a bit disillusioned with how SNES homebrew never seems to be able to get out of the ghetto...

You can use the 9th bit for the X location (located in the second OAM table) of the sprite to move it off-screen. Actually, I'm pretty sure that this is the exact purpose of having this bit there anyway as I see no other reason for it.


I agree. There's some sort of jump-start that NESDEV got that SNES didn't.