16bit table indexing problem

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu »

thefox wrote:I'd guess that it doesn't know LoadPalette is a macro, and then assumes it must be a label, and then craps out because there's no ":". Is the macro included into the file, or assembled separately? If assembled separately, it won't be visible in other modules.
It's assembled separately, because I figured the assembler would be smart enough to deal with that. Obviously I need to use .include instead. Yup, that fixed it. *sigh* Thanks.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu »

Code comment in passing: this 2input.asm file is utter shit. I seriously want to punch whoever decided to name the equates and the variable names the same thing (JOY1 vs. Joy1). This is just awful.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino »

Thank bazz! :P I have the original here, if this is any better:
InitSNES.asm
(7.25 KiB) Downloaded 555 times
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu »

Here you go. To build, just run build. You don't need to specify any arguments; just run "build" from within the directory where everything is. You will find that assembly listings for most of the files are generated (.lst files). map.txt will contain a "map" of what memory (ROM) vs. file offset locations contain what "segments" of stuff (I found this extremely useful, as did tepples apparently). Built object files (which the linker put together) are stored in the dir objs\.

You can some of the .proc routines into their own files if you wish, then make appropriate changes to the build.bat script.

Two things to note, bugs which need to be fixed:

1. Sprites do not appear. Unsure why, did not investigate.
2. "Main ship" location appears incorrectly offset somehow; maybe BG X/Y offset issue? Unsure why, did not investigate.

Hope someone can delve into those + figure them out. It's probably something obscure. This was a "fun" learning experience in the sense that 80% of my time I spent cursing loudly. "Fun"...

I'm bowing out of this thread entirely at this point. I've helped out as much as I think I can bear at this point.

Footnote: I'm kinda disgusted how ca65 has no real concept of 65816 direct page (only 6502 zero page). The best you can do is declare zero page in $0000-00ff and then the rest as BSS. I kept rolling my eyes over this. But hey, at least the assembler can generate sane listings. :-)
Attachments
MetaspriteDemoKoitsu.rar
(253.69 KiB) Downloaded 609 times
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino »

Thank you! :) (Seriously, It got to the point where I just wrote out registers. At that point, I might as well have just used machine code. :roll: )
koitsu wrote:1. Sprites do not appear. Unsure why, did not investigate.2. "Main ship" location appears incorrectly offset somehow; maybe BG X/Y offset issue? Unsure why, did not investigate.
I think this has something to do with it...
Oam....png
(Why it's acting like this is beyond me.)

I want to try and figure out what's up, which leads me to my main question. What is the main file? Is it Main, or is it MetaspriteTest2, because they both have a lot of the same code.

Edit: Oh, wait, I'm stupid. Main is just saying what is going on and is not actually assembled. (I need to pay attention more often. :oops: )
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino »

After poking at the code for two more seconds, I found the reason the BG was off:
BG scroll.png
I had thought it would be a problem of where the map data was, but I made it to where you can move the camera vertically to and the full ship is in tact. I wonder how that happened. :? One thing I find peculiar about it is that BG1 vertical position (not BG0) has all 16 bits set, while the x position doesn't. (I guess there's a whole bunch of junk before all that doesn't effect anything, but it just stops right there) I still don't know what's up with the sprites, but moving around the d-pad doesn't effect them, which means it probably doesn't have to do with the metasprite routine, but the routine at the begging that puts them all off screen.
Edit: Oh, wait, I'm stupid. Main is just saying what is going on and is not actually assembled. (I need to pay attention more often. :oops: )
Apparently, I'm even dumber than I thought, because metaspritetest2 doesn't actually do anything. main does.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu »

Sorry, I thought I deleted all those damn files before I made the .rar. Delete MetaspriteTest2.asm -- it does not get used as you've found.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino »

A quick little discovery... I found that not transferring MapX and MapY to the BG scrolling register causes the BG to act normally, so there must be a problem with MapX and MapY. Did you move all the "defined" registers from their original positions? I guess MapX and Y already have a value loaded in them from something else, but it only gets loaded before the infinite loop, because it still scrolls like normally. Otherwise, the BG wouldn't move.

Oh, and another thing. Oam is completely filled with #$55, which is kind of odd... (I made it to where I completely skipped the Medasprite routine and the SpriteInit, and nothing changed.) I got rid of the Oam uploading code, and it acted normally if you did that, having everything be #$00. I then though of the similarities between the BGs and sprites on my code and remembered that both are transferring data in NMI, so maybe the problem resides there? If someone, besides koitsu, would mind helping me, I would greatly appreciate it. :oops:
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu »

I can try to take a look at it later tonight, assuming I don't want to murder someone after work (Ruby code pisses me off). I don't think anyone else will step up to the plate.

I would not be surprised if I didn't "port" something over correctly or made a mistake with a minor change somewhere -- the latter is likely, because I remember when first doing this, I had the background up on the screen correctly but no sprites.

Kudos to you for giving the debugging a shot and narrowing it down possibly to the NMI routine. *thumbs up* :-)
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino »

koitsu wrote:Kudos to you for giving the debugging a shot and narrowing it down possibly to the NMI routine. *thumbs up* :-)
Well, I was "sort of" right. The data that was getting uploaded to OAM was not the right place because Spritebuff1 was no longer a $0400, (it's now at $0200) so I changed any reference using $0400 to #Spritebuff1. The main problem here, however, is that for some reason, RAM is flooded with #$55 in a lot of places, including MapX and Y, and SpriteBuf1. I stored 0 is MapX and MapX+1 and also did the same thing for Y and the BG is now fixed. For the sprites, I made a loop where SpriteBuf1 is filled with 0's. (There is a 1 in the X position of each sprite to prevent a special bug or something.) This now causes a sprite to be on screen when you mess with SpriteBuf2, but it appears the metasprite routine isn't working properly, because everything appears in the upper left hand corner. You said it was messed up before hand, so switching the code with one that works (which I have since made) should fix it. My problem with this whole thing is knowing why wram is flooded with #$55 in many areas, even if I got it to work.
Sort of Fixed.rar
(266.2 KiB) Downloaded 600 times
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu »

Emulator may possibly pre-fill an entire area with certain values, hard to say. Easy enough to check...

I'm going to go back "from scratch" (sort of -- I'm going to use some of the stuff I gave you, but I'm going to re-do the porting of all the code and touch/change literally none of it, and only do little bits at a time, that way I can do a binary ROM comparison between the two and see what's changed (if some assembler mistakes, etc.)) and see if I can get this done.

I only got done with work a couple hours ago and since have been interrupted by too many people unrelated to all this, keeping me from helping. Grmf...
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu »

Figured out root cause of lots of things (incl. BG offset being wrong). Root cause was pretty funny (I missed 1 single line of code). I'll have a whole new set of code ready for you, and one which conforms more to your original filenames/etc..

The only difference is that InitSNES2.asm is gone -- that thing is ridiculous, and it's all macros now in Macros.asm (for damn good reasons -- I commented why in the code). I also used my own initialisation routine which I've been using for, what, 20 years? I WISH PEOPLE WOULD STOP SCREWING AROUND WITH THE INIT ROUTINES: THERE IS NOTHING TO FIX/OPTIMISE IN THEM. THEY ARE RUN *ONCE* DURING RESET/POWER-ON. JUST USE THE VALUES NINTENDO GIVES YOU IN THE OFFICIAL DOCS AND BE DONE WITH IT. YOU DO NOT NEED LOOPS ETC. (THOSE ARE JUST SLOWER THAN UNROLLED) AND ALL IT DOES IS OBFUSCATE THE CODE. PLEASE STOP WRITING INIT ROUTINES OR "OPTIMISING THEM".

Sprites still don't work, but I have a pretty damn good idea why now after looking at the DMA routine.

And there was so much wrong in this thing, like accidents waiting to happen all over the place, etc.. *sigh*
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu »

Wonderful IBS screwing up my sleep schedule. Work is going to love me tomorrow. *sigh* But I figured while I was up dealing with dumb health problems, I might as well try to figure out the rest -- and I did, so sprites work now.

I fixed/simplified your start_metasprite routine as well (I'm pretty sure it had bugs in it vs. what the comments claimed) + I clarified things in the comments. The counting should make more sense to you now, but whether or not that's really how you want to implement it is up to you. Honestly that routine would, I think, greatly benefit from indirect addressing (so you could have multiple metasprite tables, effectively, and change which one you're referring to by a single load/store pair -- yes really!). I got rid of YTemp/XTemp too (once you see the changes you'll understand why).

I also added a crappy something if you press/hold the Y button, just for sprite movement testing.

There were other bugs/things I had to fix too but at this point I'm so tired and feeling so ugh that I can't remember.

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.

And 2input.asm is just... I don't even know what to do with that mess. ;-)

And this time I used .zip just to make Tepples happy (BTW the reason I used RAR: because Espozo did in his posts, so why you pickin' on me brah? j/k).

P.S. -- One of these days I wanna see what psychopathicteen has been working on for like the past 8 billion years.
Attachments
MetaspriteDemoKoitsu.zip
(236.41 KiB) Downloaded 496 times
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 16bit table indexing problem

Post by tepples »

koitsu wrote:I WISH PEOPLE WOULD STOP SCREWING AROUND WITH THE INIT ROUTINES: THERE IS NOTHING TO FIX/OPTIMISE IN THEM. THEY ARE RUN *ONCE* DURING RESET/POWER-ON. JUST USE THE VALUES NINTENDO GIVES YOU IN THE OFFICIAL DOCS AND BE DONE WITH IT..
I wonder if people screw with them in order to make it clear that they have intentionally avoided official docs.

I'll look at the zipfile sometime today.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu »

tepples wrote:I wonder if people screw with them in order to make it clear that they have intentionally avoided official docs.
The official docs don't include any code -- they just tell you what each register needs to be set to value-wise on reset. So no, it's simply people being ridiculous and for some reason thinking that this one-time-called routine deserves loops and other nonsense (like "don't bother initialising some registers because we set them in the near future anyway" -- WHO CARES, do the init exactly like Nintendo says, do it one time, and stop worrying about the rest!)
I'll look at the zipfile sometime today.
The latest version I posted is worse (formatting-wise) than the previous one, because I went back and started from scratch (thinking I had accidentally lost some code or changed something without fully testing each step of the way, thus causing the BG and sprite problems) and was doing a large amount of copy-pasting. I also kept a lot of the original labels and variable names and filenames from Espozo's original code (while the better-formatted one I released with BG/sprite issues had some variables and labels and files renamed).
Post Reply