I figured as much. I imagine that these values are $00 for most writable registers, and double-$00 for any register that takes double-writes, with a few exceptions such as the first and last mode 7 matrix registers that need to be $0100. So is there a reliable list of what these values are other than the official docs? If there is a list, an emulator developer could add a feature to warn on writes of incorrect values before all registers have the correct starting values.koitsu wrote:The official docs [...] just tell you what each register needs to be set to value-wise on reset.
16bit table indexing problem
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: 16bit table indexing problem
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: 16bit table indexing problem
??? SpriteBuf1 has 4bytes per sprite (X and Y positions, character data, and extra) for a total of 512 bytes and Spritebuf2 has each sprites most significant X bit and sprite size selection bit, and it is 32 bytes long. SpriteBuf1 and 2 then get DMAed to OAM during VBlank.koitsu wrote:Your whole metasprite + sprite concept here seems very... I don't know. I sort of get the impression you don't understand what SpriteBuf1/SpriteBuf2 do (meaning what they're for and how the SNES uses them), but there's a 50% chance I'm completely wrong and it's just that you haven't written the rest of the code but have designed it somewhere (in which case I apologise + ignore me). But I now understand why you want to "move to 16-bit" -- because the MSB (9th bit) of the Y position of a sprite is separate from the remaining 8 bits. I now actually understand what's needed to make all of that work, but I wish I had a better idea ultimately what your goal was.
I don't know. He's probably making something insane.koitsu wrote:P.S. -- One of these days I wanna see what psychopathicteen has been working on for like the past 8 billion years.
By the way, I made the metasprite routine use 16 bits (I haven't implemented the 9th x, not y bit yet, as it currently just gets erased when storing the number in spritebuf1) and it worked flawlessly, but I tried to make it where you add XPosition and YPosition to the number in the table that gets stored in SpriteBuf1, but the assembler didn't like it.
Edit: I forgot to CLC before ADCing, but it didn't make a difference. (I'm really not sure why it would, but I tried.)
Re: 16bit table indexing problem
The init routine in my code (see .zip file, or my old sndoc230.zip archive (see test.lzh/test.zip within that zip)) has all the correct values per official docs. I don't know of anywhere else that lists them off. Many are zero, yes, but not all.tepples wrote:I figured as much. I imagine that these values are $00 for most writable registers, and double-$00 for any register that takes double-writes, with a few exceptions such as the first and last mode 7 matrix registers that need to be $0100. So is there a reliable list of what these values are other than the official docs? If there is a list, an emulator developer could add a feature to warn on writes of incorrect values before all registers have the correct starting values.koitsu wrote:The official docs [...] just tell you what each register needs to be set to value-wise on reset.
Re: 16bit table indexing problem
@Espozo: assembler error in question is because you forgot to .exportzp the XPosition and YPosition variables within MetaspriteTest2.asm. You have to have both .importzp (in the file where you want to use those variables) and an .exportzp (in the file where you declared them) for it to work.
Procs (e.g. subroutines) work the same way (using .export/.import).
Macros, however, don't work that way -- they're not procs, they're just raw code, hence why there's Macros.asm and why I put all macros in there. And I should note that for Macros.asm, it only needs to be .include'd ONCE for the macros to be universally available, which is convenient.
But back to variables: there is also a .globalzp ca65 directive which I didn't have time to explore or tinker with, but I wouldn't get too hung up on that right now.
I'll use this opportunity to point out how annoying the ca65 "zp" stuff is, specifically because the ZEROPAGE segment is only 256 bytes long, while on the 65816 you have direct page which is up to 65536 bytes long (depending on where you place it using lda/tcd). And ca65 absolutely requires a ZEROPAGE segment (incl. in the config template). For 6502/65c02 this works wonderfully, but for 65816 it's irritating. Maybe tepples/thefox have some ideas on how to tweak the template to work better with it, but I simply don't. So basically once you exhaust the ZEROPAGE segment (i.e. you exceed 256 bytes there), it's gonna start throwing errors during link-time, in which case your variables need to end up in the BSS segment (like where the SpriteBufs are).
Procs (e.g. subroutines) work the same way (using .export/.import).
Macros, however, don't work that way -- they're not procs, they're just raw code, hence why there's Macros.asm and why I put all macros in there. And I should note that for Macros.asm, it only needs to be .include'd ONCE for the macros to be universally available, which is convenient.
But back to variables: there is also a .globalzp ca65 directive which I didn't have time to explore or tinker with, but I wouldn't get too hung up on that right now.
I'll use this opportunity to point out how annoying the ca65 "zp" stuff is, specifically because the ZEROPAGE segment is only 256 bytes long, while on the 65816 you have direct page which is up to 65536 bytes long (depending on where you place it using lda/tcd). And ca65 absolutely requires a ZEROPAGE segment (incl. in the config template). For 6502/65c02 this works wonderfully, but for 65816 it's irritating. Maybe tepples/thefox have some ideas on how to tweak the template to work better with it, but I simply don't. So basically once you exhaust the ZEROPAGE segment (i.e. you exceed 256 bytes there), it's gonna start throwing errors during link-time, in which case your variables need to end up in the BSS segment (like where the SpriteBufs are).
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: 16bit table indexing problem
Besides from Bad Apple, I've been working on a game called Alisha's Adventure. As to why I keep giving up on projects and starting new ones, it's because there is always that one little architectural problem that makes it difficult to program anything without rewriting a whole bunch of code.
- Attachments
-
- Alisha's Adventure.zip
- (31.56 KiB) Downloaded 536 times
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: 16bit table indexing problem
You seem to really like female characters, but I guess I'm not one to talk? I've already shown this on the SNES Pixel Art thread, but I fixed it up a bit more. (I'm way to nitpicky for my own good. )
I think it's really funny how when you hold down the dash button against a wall how the dashing animation still plays even when you aren't moving. Also, about the plasma Grinch thing, does it use real-time sprite rotation for its limbs?-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: 16bit table indexing problem
It actually rotates everything during the "LEVEL 1" screen.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: 16bit table indexing problem
No wonder it takes a while to load... (I assumed it was graphics decompression or something) How do you store all the animation for it moving? WRAM?
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: 16bit table indexing problem
The rotating limbs take up half of wram. The dynamic animation system is kind've like what you described in that other thread, but instead of looking for a box for every individual sprite, it looks for a box for every metasprite.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: 16bit table indexing problem
Then in that case, it would be way easier, just like calculating x and y because you wouldn't need to have the "second y" that I made. You know psychopathic teen, have you worked on the Genesis before, because something about your art style and the fact that you are pretty much only using half of wram kind of reminds me of the Genesis. I guess the advantages to both my code that looks for tiles in vram and yours is that mine is a bit more flexible, meaning it doesn't assume every metasprite uses the same size, but I imagine is a bit more costly. (Only the sprites that are undergoing any kind of animation change are going to go through, so it shouldn't be that big of a deal.)psycopathicteen wrote:The rotating limbs take up half of wram. The dynamic animation system is kind've like what you described in that other thread, but instead of looking for a box for every individual sprite, it looks for a box for every metasprite.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: 16bit table indexing problem
It doesn't assume every metasprite is the same size. It just assumes that all metasprites are rectangular.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: 16bit table indexing problem
So it allocates different sized metasprites to different sized slots?