65816: Direct Page vs Absolute Operand

[oziphantom]

Sorry I've been away from Console land for a while, could have saved you some pain.
The problem is you are looking at Console tools and not Computer tools. SNES and NES land is rather barren compared to C64 land.

64Tass is what you want.

It has N stack structs, so you can do

Code Select Expand


sScoreValues .struct
digit65 .byte ?
digit43 .byte ?
digit21 .byte ?
.ends

and then latter you have
Score .dstruct sScoreValues
HiScore .dstruct sScoreValues
or even
.block Scores
  Current .dstruct sScoreValues
  HiScore .dstruct sScoreValues
.endb

which you can access in code as

LDA Scores.Current.Digit21


You might notice the ?s above. This tells the assembler that I want some space but it doesn't need to actually put it into the output. If I put a 0 there then it would make sure the output covered that area and it was internalised to 0.

It has sections

Code Select Expand


*       = $02
        .dsection zp   ;declare zeropage section
        .cerror * > $30, "Too many zeropage variables"

and then later if I want to add a variable for some code I can do

.section zp
PlayerHasCape .byte ?
.send zp

awardPlayerCape
   inc zp.PlayerHasCape
   rts


This was I can declare the variables used by some code, even in a different file, and have it put into the Zero Page/Direct Page. without needing to worry about exactly where it is.

This becomes more useful when combined with .proc which declarers a procedure, and if it doesn't find any label references to it, then it will not be assembled. Using Sections means it data needs are also not assembled.

You can do Org and Logical ( which stacks ) so if you want to put code to 8000, that is loaded into 7F2000 to be run in ram you can do this

Code Select Expand


* = $8000
.logical =$2000
lda #1
jmp Ahead
Lda #3
Ahead

.here

and Ahead will be $2008

It lets you do

Code Select Expand


.as, .xs a and or x/y is 8 bit
.al .xl a and or x/y is 16bit
.autsiz track the rep/seps
.mansiz ignore and take your values

It has Databank and ProgramBank control
You can also set them be ? which disables the addressing modes, forcing abs at all time
you can also use ,b and ,d addressing modes to force
lda $8005,d will give you lda $05 regardless if the current bank is set to $80

There is a --shadow-check option that tells the compiler to warn if one label is forced over another

You can use the @b,@w or @l to force 8,16 or 24 bit addressing, so
lda @w$0000
force AD 00 00
you can also use the ~ form so lda $~0000

you can use .page .epage to error if code crosses a page and hence changes timings
you can use .align if you need it for speedcode so

Code Select Expand


.algin $ff <- forces next instruction to be the first byte in a page


It has psudeo opcodes
GEQ, GNE, GCC, GCS, GPL, GMI, GVC, GVS, GLT and GGE.
GRA for CPUs supporting BRA, which is expanded to BRL (if available) or JMP.
This will be a BXX instuction if it is range or the assembler will invert the XX and put a jump so
GEQ Label out of range becomes
BNE *+3
JMP Label

It has others like blt is bcc lsr lsl etc

The latest bleeding edge version has Optimisation support, in the assembler will detect and warn about unnecessary op-codes or where a branch can be used to save a byte etc
Full details can be found here http://tass64.sourceforge.net/

[jonk]

64Tass is what you want.

Glad to see your response. I'll take a serious look at the tool. Sounds very interesting! (I do note the .dpage and .databack pseudoops, as well.) I will definitely look at it.

I'm trying to consider a syntax to support a universal binary-file semantic regarding patching ROM files directly. I don't think I can reasonably do that for ROM files which are segmented in complex ways and support a variety of internal data structures. But I think I can do that for ROM files which are essentially binary streams, with the only imposed aspect being the association between file addresses and assumed memory addresses (without a requirement that memory addresses are unique, but instead that named assembled segments can be directed to binary file areas regardless of their assembled address locations.) Since the source is there, it could be modified. However, since it also outputs several format types, including Motorola S-records, it may be enough to simply add an external tool there.

EDIT: 2:45PM PT: Just noticed a thread question on tass64 about the use of LDA #-5, for example. The author suggests that the assembler gives an error for this syntax. Is that true?

[oziphantom]

Yeah the #-5 is a pain, but it is due to it doing type checking. but you can make a custom function to handle it like
neg .function a
       (256-a)
.endf

then do lda #neg(5)

I've done something like the patch recently. Use the nonlinear format (see the command lines ops ) which gives you
XX XX YY YY AA BB CC ... XX XX YY ....
where XX is a 16bit Length, YY is a 16 bit Start Address and AA BB CC ... are the bytes
If you are in 65816 mode you get
XX XX YY YY YY AA BB CC
so you have a 24bit address, your code will need to be able to translate the Mapper format of choice, so you need an Address to ROM file offset converter and done.

[jonk]

Yeah the #-5 is a pain, but it is due to it doing type checking. but you can make a custom function to handle it like
neg .function a
       (256-a)
.endf

then do lda #neg(5)

That will really be a bit of a typing pain if supplying comma separated negative values to a DB or something like that. Also, I'd have to already know that it will be negative. If I'm writing an expression, I may not know that right away, nor should I necessarily always have to.

Seems like something to fix. There is no good reason I can think of why the type checking can't also do 'promotions' from a signed value to its corresponding unsigned equivalent using the usual modulo definition found in C. (In C, there is always an equivalent unsigned value in the same size format for any signed value of the same size; but there is NOT always a conversion from an unsigned value to a signed value.)

I've done something like the patch recently. Use the nonlinear format (see the command lines ops ) which gives you
XX XX YY YY AA BB CC ... XX XX YY ....
where XX is a 16bit Length, YY is a 16 bit Start Address and AA BB CC ... are the bytes
If you are in 65816 mode you get
XX XX YY YY YY AA BB CC
so you have a 24bit address, your code will need to be able to translate the Mapper format of choice, so you need an Address to ROM file offset converter and done.

This I don't think I fully apprehend. I think you are talking about my ROM patching comment here and bringing in the different mapping formats for the binary file output. But I don't really understand the details you mention, probably because I'm still mostly ignorant about tass64. I'm sure it will clear up for me as I read more, when I get a moment of time.

Thanks, again.

[oziphantom]

Oddly it is only the # case, in that it says a immediate must be unsigned char. .byte -5,-4.-3,-2,-1,0,1,2,3,4,5,6 is perfectly fine. Yes I keep telling Soci ( the maker ) its daft.

Ok given this code

Code Select Expand


;patch the loader checksum
* = $86b3
.byte $17

;patch the loader
* = $9db3
JMP $0200

;disable the PLAY button detection
* = $9da5
nop
nop

You would normally get a file like

Code Select Expand


B3 86 17 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
.snip.
00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
20 02 00 00 00 00 00 00 00 00 00 00 00
etc

Doing a non linear file gets you a file with

Code Select Expand


01 00 B3 86 17 03 00 B3 9D 20 02 00 02 00 A5 9D EA EA

[jonk]

Oddly it is only the # case, in that it says a immediate must be unsigned char. .byte -5,-4.-3,-2,-1,0,1,2,3,4,5,6 is perfectly fine. Yes I keep telling Soci ( the maker ) its daft.

Yeah. Well, it's daft. It's going to make me read code and fix it and, if necessary, start a whole new web page with a new product just to be annoying about it. And he/she won't like the way I fix it, either! I'll make sure it is very ugly, but workable. So they'd better do it before I do!

Ok given this code

Code Select Expand


;patch the loader checksum
* = $86b3
.byte $17

;patch the loader
* = $9db3
JMP $0200

;disable the PLAY button detection
* = $9da5
nop
nop

You would normally get a file like

Code Select Expand


B3 86 17 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
.snip.
00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
20 02 00 00 00 00 00 00 00 00 00 00 00
etc

Doing a non linear file gets you a file with

Code Select Expand


01 00 B3 86 17 03 00 B3 9D 20 02 00 02 00 A5 9D EA EA

Thanks. I had already understood that before you wrote about it. I just hadn't clued in on your use of the phrase "non linear" as meaning what I already understood as something else. My confusion and you've cleared it up. No problem.

I can use such files (or Mot S-records) with my own patcher program to update the ROM file, too. Or write a different one to convert one of several outputs of tass64 into a more standard rom update format used here on this site. Or modify tass64 to generate those same standard formats. Or... well, lots of possibilities, I guess. It's all good.

[oziphantom]

Soci the author of 64Tass has noted my #256-5 hack and it has been officially fixed as of r1200 so
LDA #-5 works
and it will also fail on
LDA #+140
as signed is -128/+127
and using .char will handle the "byte" case
.char 1,-5,3

[jonk]

Soci the author of 64Tass has noted my #256-5 hack and it has been officially fixed as of r1200 so
LDA #-5 works
and it will also fail on
LDA #+140
as signed is -128/+127
and using .char will handle the "byte" case
.char 1,-5,3

Thanks for the note. I'll look at r1200.