But then you have to include CMake in the list of dependencies you have to download.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.
16bit table indexing problem
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: 16bit table indexing problem
Re: 16bit table indexing problem
How is having MinGW as a dependency any better? (given it's only being used for mingw32-make)
Re: 16bit table indexing problem
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.tepples wrote:But then you have to include CMake in the list of dependencies you have to download.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.
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
Re: 16bit table indexing problem
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?tepples wrote:Did someone say template?koitsu wrote:I'd honestly suggest just asking someone like Tepples to write you a ca65 template and use that instead.
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.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: 16bit table indexing problem
I felt the same way you do, I just didn't want to say anything. I think tepples brain is wired differently from ours. 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.
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.
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.
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.
Re: 16bit table indexing problem
My comment was with regards to tepples' "template" ca65 example.
The one piece of WLA DX code I cannot figure out is this:
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)
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.
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.
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
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
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).
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.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: 16bit table indexing problem
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.
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? (I'll use comments on it next time I upload a file.)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.
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.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.
Last edited by Drew Sebastino on Sat Jan 31, 2015 3:33 pm, edited 1 time in total.
Re: 16bit table indexing problem
I want to make it less "Ho Lee Fuk". I'd appreciate your thoughts here.koitsu wrote:My comment was with regards to tepples' "template" ca65 example.
Re: 16bit table indexing problem
Where did you get this code? With WLA DX? I can't find it with either 9.2 or 9.4.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
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: 16bit table indexing problem
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:
SNES starterkit here:
http://wiki.superfamicom.org/snes/show/ ... nvironment
Custom LoadGraphics code here:
Re: 16bit table indexing problem
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.tepples wrote:I want to make it less "Ho Lee Fuk". I'd appreciate your thoughts here.koitsu wrote:My comment was with regards to tepples' "template" ca65 example.
Re: 16bit table indexing problem
Oh, you added that. Yeah, then I know where it is from, thanks.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:
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: 16bit table indexing problem
Don't mention it!
Re: 16bit table indexing problem
Well shit, I'll just post it here. Maybe thefox or someone else knows.
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:
BG_Palette comes from the same file, but in segment RODATA3:
And finally the macro, which comes from a different file called Macros.asm and is assembled first (NOTE: ca65 assembles this just fine):
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.
Code: Select all
Main.asm(266): Error: `:' expected
Main.asm(266): Error: Unexpected trailing garbage characters
Code: Select all
LoadPalette BG_Palette, 0, 16
Code: Select all
BG_Palette:
.incbin "GamePictures\hovertransport.clr"
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
The ca65 error, given the complaint about a colon, seems to imply it's having issues comprehending labels.
Re: 16bit table indexing problem
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.koitsu wrote:The ca65 error, given the complaint about a colon, seems to imply it's having issues comprehending labels.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi