16bit table indexing problem

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 16bit table indexing problem

Post by tepples » Tue Jan 27, 2015 7:19 am

thefox wrote:Personally I prefer using a "Makefile generator" like CMake, because CMake is able to take care of the platform differences. On top of that, CMake has builtin tools for writing and running tests, and packaging the build results.
But then you have to include CMake in the list of dependencies you have to download.

Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: 16bit table indexing problem

Post by Sik » Tue Jan 27, 2015 7:29 am

How is having MinGW as a dependency any better? (given it's only being used for mingw32-make)

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: 16bit table indexing problem

Post by thefox » Tue Jan 27, 2015 7:38 am

tepples wrote:
thefox wrote:Personally I prefer using a "Makefile generator" like CMake, because CMake is able to take care of the platform differences. On top of that, CMake has builtin tools for writing and running tests, and packaging the build results.
But then you have to include CMake in the list of dependencies you have to download.
If your opinion is that the disadvantage of adding one more dependency (possibly removing a bunch of other ones at the same time) balances out the advantages of platform compatibility, and ease of writing the build scripts, and the n+1 other useful features provided by CMake, then certainly that's a valid complaint.

BTW, I'm not saying CMake is perfect. I've used it enough to know it has a number of problems, but I would choose it over handwritten makefiles every time. But to each his own.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
koitsu
Posts: 4216
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu » Sat Jan 31, 2015 3:02 am

tepples wrote:
koitsu wrote:I'd honestly suggest just asking someone like Tepples to write you a ca65 template and use that instead.
Did someone say template?
I finally got around to looking at this code. Ho-ly-shit. Really? God dude, I don't even know where to begin. The code itself is fine (sort of -- very bad init routine from the look of it), but it's nearly impossible to follow given formatting, things in files that don't make any sense (like why is the reset vector code in snesheader.s), and a ton of other things. Can you honestly read this given the formatting and almost "inline" comments without any actual structure?

I at least got part of Espozo's code assembling (writing the Windows batch file was about 70% of the work), but I'm having to go through one thing at a time and it's very very painful. I had no idea ca65 would be this... I don't know... powerful yet absolutely and totally ridiculous. There's even some WLA DX code (a macro) that makes zero sense to me at this time and not having a listing file from WLA DX makes me sit here going "how the hell does this even work?"

What the hell happened to SNES development? How is it we had more or less better assemblers and sane tools than now? Wow.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino » Sat Jan 31, 2015 6:46 am

I felt the same way you do, I just didn't want to say anything. I think tepples brain is wired differently from ours. :roll: I don't think my work environment is way too complex.

Edit: What follows is my work environment, which I think is easier to understand. I originally forgot to mention this, so my post made no sense.
Work Environment.png
Work Environment.png (2.93 KiB) Viewed 16719 times
In this, 2input does something with the controllers, (I honestly don't know, but it works, so...) Header is the header (no duh) InitSNES2 just sets all the registers back to 0, LoadGraphics is a macro that makes it easy to DMA graphics to vram, Metasprite2 is a metasprite creating routine, Metasprite Test2 is the main file, (I always specify this) and Sprites sets all the sprites off screen.
Last edited by Drew Sebastino on Sat Jan 31, 2015 3:07 pm, edited 1 time in total.

User avatar
koitsu
Posts: 4216
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu » Sat Jan 31, 2015 3:02 pm

My comment was with regards to tepples' "template" ca65 example.

The one piece of WLA DX code I cannot figure out is this:

Code: Select all

;============================================================================
; LoadBlockToVRAM -- Macro that simplifies calling LoadVRAM to copy data to VRAM
;----------------------------------------------------------------------------
; In: SRC_ADDR -- 24 bit address of source data
;     DEST -- VRAM address to write to (WORD address!!)
;     SIZE -- number of BYTEs to copy
;----------------------------------------------------------------------------
; Out: None
;----------------------------------------------------------------------------
; Modifies: A, X, Y
;----------------------------------------------------------------------------

;LoadBlockToVRAM SRC_ADDRESS, DEST, SIZE
;   requires:  mem/A = 8 bit, X/Y = 16 bit
.MACRO LoadBlockToVRAM
    lda #$80
    sta $2115
    ldx #\2         ; DEST
    stx $2116       ; $2116: Word address for accessing VRAM.
    lda #:\1        ; SRCBANK
    ldx #\1+\4      ; SRCOFFSET
    ldy #\3         ; SIZE
    jsr LoadVRAM
.ENDM
What is \4 here? It refers to the 4th argument to the macro, but the comment preceding the macro doesn't mention it. The code clearly uses it (note 2nd SpriteTiles load; it's the only call where it's non-zero)

Code: Select all

        LoadBlockToVRAM SpriteTiles, $0000, $0040, $0000
        LoadBlockToVRAM SpriteTiles, $100, $0040, $0040
        LoadBlockToVRAM BackgroundPics, $2000, $3620, $0000     ; 384 tiles * (8bit color)= 0x6000 bytes
        LoadBlockToVRAM BackgroundMap, $7000, $1000, $0000      ; 64x64 tiles = 4096 words = 8192 bytes
I fully understand what LoadVRAM does -- the contents of X make it into $4302, which is the 16-bit portion of the 24-bit address that DMA channel #0 is going to read from when populating VRAM, but I do not understand why the logic in the macro is to add argument 1 and argument 4 together to make up the 16-bit base address of where the source data is. Argument 1 = SRC_ADDR, which should be a full 24-bit address (according to the comments).

The WLA DX docs, as I expected, don't shed any light on this either.

Code: Select all

Also, if you want to use macro arguments in e.g., calculation, you can
type '\X' where X is the number of the argument. Another way to refer
to the arguments is to use their names given in the definition of the
macro (see the examples for this).
To me, ldx #\1+\4 when doing SpriteTiles, $100, $0040, $0040 (assume SpriteTiles full 24-bit address is $02f3f0 would result in ldx #($20f3f0 + $0040) (the bank byte is effectively stripped), thus ldx #$f430. What I don't understand is what the purpose of the 4th argument actually is. If I had seen ldx #\1 I might think "the lower 16-bits of the 1st argument", but again the WLA DX docs don't shed any light on this, going back to the need for a listing generation.

I think it's used as an "additional offset" within whatever you provide in argument 1, i.e. SpriteTiles+$0040, but the fact the macro doesn't properly document the use of the 4th argument worries me.

Edit: and your code isn't very well organised either. :-) But it's at least something I can follow a lot easier than the ca65 lorom example.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino » Sat Jan 31, 2015 3:05 pm

Oops, I was saying that I think he should set his code up to be a little more organized like mine, but I forgot to say anything about that and just said how my code was set up. :oops:
I think it's used as an "additional offset" within whatever you provide in argument 1, i.e. SpriteTiles+$0040, but the fact the macro doesn't properly document the use of the 4th argument worries me.
Correct! I was tired of making 3,000 different pictures for a single frame and whatnot, so I just made that. Pretty nifty, don't you think? :wink: (I'll use comments on it next time I upload a file.)
Edit: and your code isn't very well organised either. :-) But it's at least something I can follow a lot easier than the ca65 lorom example.
Do you know what I could do better? I upload stuff enough, so I just want to have it as organized as possible so I don't frustrate people.
Last edited by Drew Sebastino on Sat Jan 31, 2015 3:33 pm, edited 1 time in total.

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 16bit table indexing problem

Post by tepples » Sat Jan 31, 2015 3:29 pm

koitsu wrote:My comment was with regards to tepples' "template" ca65 example.
I want to make it less "Ho Lee Fuk". I'd appreciate your thoughts here.

DoNotWant
Posts: 83
Joined: Sun Sep 30, 2012 3:44 am

Re: 16bit table indexing problem

Post by DoNotWant » Sat Jan 31, 2015 3:49 pm

koitsu wrote:

Code: Select all

;============================================================================
; LoadBlockToVRAM -- Macro that simplifies calling LoadVRAM to copy data to VRAM
;----------------------------------------------------------------------------
; In: SRC_ADDR -- 24 bit address of source data
;     DEST -- VRAM address to write to (WORD address!!)
;     SIZE -- number of BYTEs to copy
;----------------------------------------------------------------------------
; Out: None
;----------------------------------------------------------------------------
; Modifies: A, X, Y
;----------------------------------------------------------------------------

;LoadBlockToVRAM SRC_ADDRESS, DEST, SIZE
;   requires:  mem/A = 8 bit, X/Y = 16 bit
.MACRO LoadBlockToVRAM
    lda #$80
    sta $2115
    ldx #\2         ; DEST
    stx $2116       ; $2116: Word address for accessing VRAM.
    lda #:\1        ; SRCBANK
    ldx #\1+\4      ; SRCOFFSET
    ldy #\3         ; SIZE
    jsr LoadVRAM
.ENDM
Where did you get this code? With WLA DX? I can't find it with either 9.2 or 9.4.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino » Sat Jan 31, 2015 4:06 pm

It's from the LoadGraphics code on the SNES starterkit. Well, mostly. I took some stuff bazz did to the palette uploading macro (it was truly useless beforehand) and I added a 4th argument on the LoadBlockToVram that serves as an offset in the picture.

SNES starterkit here:

http://wiki.superfamicom.org/snes/show/ ... nvironment

Custom LoadGraphics code here:
LoadGraphics.asm
(4.86 KiB) Downloaded 660 times

User avatar
koitsu
Posts: 4216
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu » Sat Jan 31, 2015 4:32 pm

tepples wrote:
koitsu wrote:My comment was with regards to tepples' "template" ca65 example.
I want to make it less "Ho Lee Fuk". I'd appreciate your thoughts here.
Are you available online for real-time chat somewhere? I need to talk to you about some syntax errors with macros I'm getting in ca65 which aren't making any sense to me.

DoNotWant
Posts: 83
Joined: Sun Sep 30, 2012 3:44 am

Re: 16bit table indexing problem

Post by DoNotWant » Sat Jan 31, 2015 4:37 pm

Espozo wrote:It's from the LoadGraphics code on the SNES starterkit. Well, mostly. I took some stuff bazz did to the palette uploading macro (it was truly useless beforehand) and I added a 4th argument on the LoadBlockToVram that serves as an offset in the picture.

SNES starterkit here:

http://wiki.superfamicom.org/snes/show/ ... nvironment

Custom LoadGraphics code here:
LoadGraphics.asm
Oh, you added that. Yeah, then I know where it is from, thanks.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino » Sat Jan 31, 2015 5:05 pm

Don't mention it! :twisted:

User avatar
koitsu
Posts: 4216
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu » Sat Jan 31, 2015 5:18 pm

Well shit, I'll just post it here. Maybe thefox or someone else knows.

Code: Select all

Main.asm(266): Error: `:' expected
Main.asm(266): Error: Unexpected trailing garbage characters
This lines correlates with the following line that uses a macro (and I'll include the segment it's in, etc.). This is in the CODE segment:

Code: Select all

  LoadPalette BG_Palette,     0, 16
BG_Palette comes from the same file, but in segment RODATA3:

Code: Select all

BG_Palette:
  .incbin "GamePictures\hovertransport.clr"
And finally the macro, which comes from a different file called Macros.asm and is assembled first (NOTE: ca65 assembles this just fine):

Code: Select all

.macro LoadPalette src, start, size
.if .PARAMCOUNT <> 3
.error "LoadPalette: incorrect number of parameters"
.endif
  lda #.LOBYTE(start)
  sta $2121                  ; Start at START color
  lda #.BANKBYTE(src)        ; Bank byte of src (upper 8-bits of 24-bit address)
  ldx #.LOWORD(src)          ; Address of src   (lower 16-bits of 24-bit address)
  ldy #(size*2)              ; 2 bytes for every color
  jsr DMAPalette             ; see main.asm
.endmacro
DMAPalette comes from Main.asm and is just a .proc within the CODE segment.

The ca65 error, given the complaint about a colon, seems to imply it's having issues comprehending labels.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: 16bit table indexing problem

Post by thefox » Sat Jan 31, 2015 5:27 pm

koitsu wrote:The ca65 error, given the complaint about a colon, seems to imply it's having issues comprehending labels.
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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

Post Reply