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

[BitWise]

ElEctric_EyE wrote:

No spaces. That worked...

Your program automatically converts a 6502 program to 65Org16? It sure seems like it does after copying and pasting a short 6502 routine I wrote using MK's assembler.

I built the 65Org16 assembler from the same Java source as my 6502 family assembler. Its uses the same parser but I stripped out support for device switching (.6502, .65C02, .65816) and extended byte to be 16-bits through out.

So if you feed it vanilla 6502 source it will come out as 16-bit code.

[ElEctric_EyE]

Excellent!

Would it be too much trouble to increase the size of the boot.asm file to 8Kx16? The reason I ask is because I have 3 assemblers/disassemblers I'm looking at, and 2 of the 3 top out at 4Kx8. I'm looking to convert Micromon-64, Supermon-64, and/or Hashmon for my project.

[BitWise]

ElEctric_EyE wrote:

Excellent!

Would it be too much trouble to increase the size of the boot.asm file to 8Kx16? The reason I ask is because I have 3 assemblers/disassemblers I'm looking at, and 2 of the 3 top out at 4Kx8. I'm looking to convert Micromon-64, Supermon-64, and/or Hashmon for my project.

Just change the start address for your code in the source file (e.g. .ORG $FFFFE000) and the linker options to reflect the new code area

Code: Select all

LK65_FLAGS = \
	-bss $$00010000-$$EFFFFFFF -code $$FFFFE000-$$FFFFFFFF

[ElEctric_EyE]

Thanks for the quick reply.
How does one go about changing the linker file/options?
I tried pasting that code in the assembly and it's giving some exceptions.

[BitWise]

ElEctric_EyE wrote:

Thanks for the quick reply.
How does one go about changing the linker file/options?
I tried pasting that code in the assembly and it's giving some exceptions.

The linker options are in the makefile

[ElEctric_EyE]

I see it. Thank You.

[ElEctric_EyE]

Bitwise, is it possible to add data tables in your 65Org16 assembler?. In MK's assembler it looks like this:

Code: Select all

coltable	.DB $00,$00,$00,$00,$FF,$FF,$FF,$00,$68,$37,$2B,$00,$70,$A4,$B2,$00	;4-bit C-64

TIA

[BigEd]

Hi EE
I think the .byte directive does what you want:

Quote:

The .BYTE directive deposits a series of 8-bit values into the object code for the current module. The values can be defined as the result of an expression (this includes simple numeric values) or as strings delimited by quotes.

Code: Select all

        .BYTE "Hello World",$0D,$0A,0

With some help from the two authors, I've been able to get Bill's TinyBasic reconstructed source (of Tom Pittman's binary) into a form which assembles with both assemblers, with the only variation being a swapping between two include headers:

Code: Select all

   .include "header-dev65.asm"
;  .include "header-hxa.asm"

I've found that HXA sometimes gives clearer diagnostics, but dev65 is an easier route to binaries for ROM images. Anyhow, it's good to have portable sources.

Those headers are simple enough:

Code: Select all

==> header-dev65.asm <==
;; assembly header for Dev65 assembler
;;    http://www.obelisk.demon.co.uk/dev65/as65.html

mesg .macro sometext 
     .byte  sometext
     .endm

Code: Select all

==> header-hxa.asm <==
;; assembly header for HXA assembler
;;    http://home.earthlink.net/~hxa/docs/hxa.htm#l7e

        .hexfile
        .listfile
        .errfile

        .cpu T_32_M16
        .assume BIT32=1032, BIT32R=3210
        .include "i6502.a"

macro mesg, ?sometext
        .str ?sometext
.endm

The other useful thing I have is a sign-extension macro, where I have a table of 8-bit bytes which are going to be treated as signed (so BPL, BMI, BIT are likely to be used)

Code: Select all

;; sign extension - will set Z and N, but disturbs C and V
signextend .macro dummy
      eor #$80
      sec
      sbc #$80
      .endm

I could preserve C and V if I use a temporary: this is untested, and suggestions for improvement are welcome:

Code: Select all

;; untested! sign extension - will set Z and N, preserve C and V
signextend .macro dummy
      php
      eor #$80
      sec
      sbc #$80
      sta atemp
      plp
      lda atemp
      .endm

(Probably this macro syntax is only good for dev65)

Both of those macros also work on 6502, but just waste some cycles.

(I've also been aiming to assemble the same source for both 6502 and 65Org16 - so far that's been possible, but I haven't yet got TinyBasic working.)

Cheers
Ed

[ElEctric_EyE]

Forgive another stupid question, but I am getting "Illegal addressing mode" when trying to use ASL, LSR, ROL, ROR...

Ah, never mind, Must enter as ASL A, etc... Sorry

[BigDumbDinosaur]

ElEctric_EyE wrote:

Forgive another stupid question, but I am getting "Illegal addressing mode" when trying to use ASL, LSR, ROL, ROR...

Ah, never mind, Must enter as ASL A, etc... Sorry

ASL A, etc., is correct MOS Technology syntax. It's based on the notion that instructions that are able to address memory and accumulator should have an operand.

[teamtempest]

Quote:

ASL A, etc., is correct MOS Technology syntax. It's based on the notion that instructions that are able to address memory and accumulator should have an operand.

Mebbe so, but there's also the notion that it's unnecessary clutter. Since no instruction on any 65xx- variant that allows implied addressing also allows accumulator addressing, and vice versa, it's no problem for an assembler to determine the proper code to emit even in the absence of an 'A' in the operand field.

Of course you already know that. Never mind

Turning to an earlier post:

Quote:

Code:
;; untested! sign extension - will set Z and N, preserve C and V
signextend .macro dummy
php
eor #$80
sec
sbc #$80
sta atemp
plp
lda atemp
.endm



(Probably this macro syntax is only good for dev65)

If you're referring to putting the macro name before the ".macro" pseudo op and any formal arguments after it, that is a very common style, so HXA supports that. I sometimes have a long name that throws off list formatting if I put it before the pseudo op, so I tend to put both name and arguments after, but whatever works.

The formal argument 'dummy' would have to be written '?dummy' to be what HXA likes to see, but that fact that it isn't used wouldn't be a problem. Simpler just to leave it out altogether, though.

Quote:

I've found that HXA sometimes gives clearer diagnostics, but dev65 is an easier route to binaries for ROM images.

I like the first part ; that's one of my areas of emphasis. Not so much the second I'd have to know more details before I could comment much beyond saying that the two assemblers have very different ideas regarding how to go about linking (dev65 seems much more traditional). Possibly too different to easily reconcile in a single source.

[BitWise]

I have updated both the 6501/6502/65C02/65816 and 65Org16 assemblers so that:

- They allow implied mode with ASL/ROL etc. as well as ASL A

- They allow reserved words as labels (e.g. BREAK)

- Don't crash when the file name is invalid (- it crashed trying to report the error)

- Allow an optional condition code on BREAK and CONTINUE commands for use in structured assembly. For example

Code: Select all

LDX #0
REPEAT
 CPX #10
 BREAK EQ
 INX
FOREVER

- Misc other small bugs and fixes

The revised 65Org16 assembler and example using NMAKE are here:
http://www.obelisk.demon.co.uk/files/65016.zip

The revised 6502 assembler and example using batch files are here:
http://www.obelisk.demon.co.uk/6502/6502.zip

The same JAR is in both but the assemblers and linkers need different class names to invoke them.

[BigEd]

Great - thanks!

[ElEctric_EyE]

Excellent, thanks for that update Bitwise! although I've not tried it yet, does it address the following:

I am having a problem with LDA $XXXXXXXX,x. More detail here.
Currently this operation is showing up as a $00B5 in the .bin which translates to a LDA $XXXX,x when it should be opcode $00BD?

[BitWise]

ElEctric_EyE wrote:

Excellent, thanks for that update Bitwise! although I've not tried it yet, does it address the following:

I am having a problem with LDA $XXXXXXXX,x. More detail here.
Currently this operation is showing up as a $00B5 in the .bin which translates to a LDA $XXXX,x when it should be opcode $00BD?

Looks like there is a bug in the direct page detection. Meanwhile use one of the override characters to get the right instruction.

Code: Select all

FFFFF000  00B5E000          :                 LDA     $FFFFE000,X
FFFFF002  00BDE000FFFF      :                 LDA     |$FFFFE000,X
FFFFF005  00BDE000FFFF      :                 LDA     !$FFFFE000,X