Page 6 of 9
Posted: Mon Oct 24, 2011 1:16 pm
by BitWise
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.
Posted: Wed Oct 26, 2011 11:19 am
by 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.
Posted: Wed Oct 26, 2011 11:32 am
by BitWise
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
Posted: Wed Oct 26, 2011 11:46 am
by 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.
Posted: Wed Oct 26, 2011 12:34 pm
by BitWise
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
Posted: Wed Oct 26, 2011 1:43 pm
by ElEctric_EyE
I see it. Thank You.

Posted: Tue Nov 22, 2011 8:51 pm
by 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
Posted: Wed Nov 23, 2011 6:29 am
by BigEd
Hi EE
I think the
.byte directive does what you want:
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.
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
Posted: Tue Nov 29, 2011 2:36 pm
by 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
Posted: Tue Nov 29, 2011 5:00 pm
by BigDumbDinosaur
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.
Posted: Wed Nov 30, 2011 3:32 am
by teamtempest
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:
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.
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.
Posted: Wed Nov 30, 2011 8:54 pm
by 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.
Posted: Wed Nov 30, 2011 9:59 pm
by BigEd
Great - thanks!
Posted: Wed Dec 07, 2011 9:51 pm
by 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?
Posted: Thu Dec 08, 2011 11:19 am
by BitWise
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