65Org16 Assembler (16-bit bytes, 32-bit address space)

[ElEctric_EyE]

Thanks again Bitwise!
What is actually involved in making these 'minor' adjustments to your JAVA creation? Could a layman like myself do them?

[BitWise]

If you can program in Java then the code is quite easy to fix. For example here a link to the patch for the last bug fix

http://dev65.svn.sourceforge.net/viewvc ... pathrev=16

You'd need a Subversion client, a copy of the Eclipse IDE with the 'Subclipse' plug in installed, a sourceforge account and access permission to commit changes back to repository -- All these are free downloads and registrations + me granting you repository access.

[ElEctric_EyE]

Not so easy, heh...

Are you sure that's the update? I'm getting all zero page opcodes again, even LDA$xxxxxxxx which was fixed before... I'll try the ! expression.

[BitWise]

ElEctric_EyE wrote:

Not so easy, heh...

Are you sure that's the update? I'm getting all zero page opcodes again, even LDA$xxxxxxxx which was fixed before... I'll try the ! expression.

Curious. I get

Code: Select all

FFFFF000  00BD8000FFFF      :                 LDA $FFFF8000,X
FFFFF003  00BD8000FFFF      :                 LDA !$FFFF8000,X
FFFFF006  00BD8000FFFF      :                 LDA |$FFFF8000,X
                              
FFFFF009  00B58000          :                 LDA $00008000,X
FFFFF00B  00BD80000000      :                 LDA !$00008000,X
FFFFF00E  00BD80000000      :                 LDA |$00008000,X
                              
FFFFF011  00EE8000FFFF      :                 INC $FFFF8000
FFFFF014  00EE8000FFFF      :                 INC !$FFFF8000
FFFFF017  00EE8000FFFF      :                 INC |$FFFF8000
                                                              
FFFFF01A  00E68000          :                 INC $00008000
FFFFF01C  00EE80000000      :                 INC !$00008000
FFFFF01F  00EE80000000      :                 INC |$00008000

[ElEctric_EyE]

It works. I forgot it optimizes $00000001 to $0001...

Some more observations as I am testing more opcodes on my .b core:

1) STA $xxxx,Y ($0091) is observed as STA $xxxxxxxx,Y ($0099). In fact, all odd opcodes in column 1 have this problem, i.e. ($0011,$0031,$0051,$0071... observed as $0019,$0039,$0059,$0079, etc.)

Thanks for your continued support!

[BitWise]

ElEctric_EyE wrote:

It works. I forgot it optimizes $00000001 to $0001...

Some more observations as I am testing more opcodes on my .b core:

1) STA $xxxx,Y ($0091) is observed as STA $xxxxxxxx,Y ($0099). In fact, all odd opcodes in column 1 have this problem, i.e. ($0011,$0031,$0051,$0071... observed as $0019,$0039,$0059,$0079, etc.)

Thanks for your continued support!

In the WDC datasheet $91 is STA (zp),Y. Only LDX and STX have a zp,Y addressing mode so the assembler uses the abs,Y instruction where zp,Y isn't available.

Code: Select all

FFFFF02B  009980000000      :                 STA $00008000,Y
FFFFF02E  009980000000      :                 STA !$00008000,Y
FFFFF031  009980000000      :                 STA |$00008000,Y
FFFFF034  00910001          :                 STA ($0001),Y
FFFFF036  00110001          :                 ORA ($0001),Y
FFFFF038  00B61234          :                 LDX $1234,Y
FFFFF03A  00961234          :                 STX $1234,Y

[ElEctric_EyE]

DOH, I knew that. Indirect Indexed.
Still it is an interesting feature of your assembler. Thanks, I think As65 is bug free now!

[ElEctric_EyE]

In As65, I am using simple macro's like for instance:

Code: Select all

LDBi              .MACRO          ;LDB #$xxxx
                  .BYTE $01A9
                  .ENDM

And so when I write the assembly I have to do this:

Code: Select all

LDBi
.BYTE $00FF

What is the syntax of the macro have to look like to have the assembly abit more agreeable to the eyes?

Code: Select all

LDBi, $00FF

or

Code: Select all

LDBi $00FF

or something along these lines.

Ideally, it would look like

Code: Select all

LDBi #$00FF

Is this possible?

[GARTHWILSON]

In that case, with the three commercial assemblers I've worked with, you would put the name of a macro variable in the macro definition line:

Code: Select all

LDBi:  .MACRO  param
       .BYTE   $1A9, param
       .ENDM
 ;---------------------

Something I liked about the 2500AD assembler is that you could have any number of parameters, and have, in essence, "If there is a fourth parameter, do this; if there is a fifth one, do that," etc..

For different address modes, you would probably have to use another parameter to tell it which addressing mode you want, or put it in the mnemonic, which is what I did in my super-simple Forth assembler, so it takes for example, LDA# or LDA_ZP or LDA_ZP,X etc.. Not being familiar with As65 though, I suspect the range of characters it lets you put in a label (as for macro names) is more limited.

[BitWise]

As65 accepts named or numbered arguments. So you can write either

Code: Select all

LDBi    .MACRO  param
        .BYTE   $1A9,param
        .ENDM

or

Code: Select all

LDBi    .MACRO
        .BYTE   $1A9,\0
        .ENDM

In both cases you invoke it with

Code: Select all

        LDBi    $1234

If you wanted to extend the assembler to understand a new opcode the you would add a block like the following but change the constants in the switch to the correct values of the LDB opcodes

Code: Select all

	/**
	 * An <CODE>Opcode</CODE> that handles the LDA instruction.
	 */
	protected final Opcode 	LDA		= new Opcode (KEYWORD, "LDA")
	{
		/**
		 * {@inheritDoc}
		 */
		public boolean compile ()
		{
			switch (parseMode ()) {
			case IMMD:	genImmd (0x00A9, arg);	break;
			case DPAG:	genDpag (0x00A5, arg);	break;
			case ABSL:	genAbsl (0x00AD, arg);	break;
			case DPGX:	genDpag (0x00B5, arg);	break;
			case ABSX:	genAbsl (0x00BD, arg);	break;
			case DPGY:
			case ABSY:	genAbsl (0x00B9, arg);	break;
			case INDX:	genDpag (0x00A1, arg);	break;
			case INDY:	genDpag (0x00B1, arg); 	break;
			case INDI:	genDpag (0x00B2, arg);	break;

			default:
				error (ERR_ILLEGAL_ADDR);
			}
			return (true);
		}
	};

You have to make a couple of other small tweaks but that's the most of it.

[ElEctric_EyE]

Code: Select all

LDBi              .MACRO  param        ;LDB #$xxxx
                  .BYTE $01A9, param
                  .ENDM

This is giving me 'invalid expression' error. Your second example yields same result. What could I be doing wrong?

[BitWise]

ElEctric_EyE wrote:

Code: Select all

LDBi              .MACRO  param        ;LDB #$xxxx
                  .BYTE $01A9, param
                  .ENDM

This is giving me 'invalid expression' error. Your second example yields same result. What could I be doing wrong?

Curious, I get:

Code: Select all

FFFFF03C                      LDBi            .MACRO  param
                                              .BYTE   $01A9,param
                                              .ENDM
                                              
                                              
                                              .EXTERN fred
                                              LDBi    $00ff
FFFFF03C  01A900FF          +                 .BYTE   $01A9,$00ff
                                              LDBi    fred
FFFFF03E  01A90000          +                 .BYTE   $01A9,fred
                                              LDBi    1+2*3
FFFFF040  01A90007          +                 .BYTE   $01A9,1+2*3

[ElEctric_EyE]

Ok. Thanks for checking...
Is this sufficient for the beginning of a 65016 boot.asm file, or am I missing something?

Code: Select all

     .CODE
  	.ORG	$FFFFC000

I'm running NMAKE from a DOS command window under Windows XP SP3.

NMAKE is giving me 13 of these identical errors if this is any clue.

[BitWise]

Send me a copy of your boot.asm file

[ElEctric_EyE]

Ah, I am dense. It works. I didn't realize when I change the macro parameters, I need to change the way the macro's are invoked. The errors were all the times the macro was improperly invoked, using the old syntax. Sorry about that.

Now, extending your assembler seems interesting, where would I add that block? You made provisions for $B2, the indirect indexed W addressing mode? Although it seems like more work, it may be worth it in order to get the assembly looking exactly as it should. I'd like to experiment with this.