XA or CA65 ?

Here you can ask questions or provide insights about how to use efficiently 6502 assembly code on the Oric.

Wich assembler do you use: XA or CA65 ?

XA
4
57%
CA65
3
43%
 
Total votes: 7

User avatar
Dom
Flying Officer
Posts: 141
Joined: Sun Nov 25, 2012 7:00 pm

Re: XA or CA65 ?

Post by Dom »

Symoon wrote: Thu Jul 21, 2022 10:24 am XA is now the (very short) majority. From what I've understood, it seems a bit simplier to start, and it's in the OSDK so I guess I'll have a go with it.
Thanks to all for your help, comments, votes, ... And I suppose, see you soon with stupid problems and a desperate Symoon ;)
Hi Simon, my vote tipped the scales in favor of XA :wink:
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: XA or CA65 ?

Post by Dbug »

Dom wrote: Thu Jul 21, 2022 10:44 am - Reports of old coding parties and difficulties in exchange code between Dbug, jede and Twilighte, because Dbug and Jede used OSDK and Twiligte used another cross assembler.
A cross assembler that he wrote himself, which unfortunately had a completely different syntax to anything else, which made it very difficult to integrate the code he produced in other demos.
Now I Wonder If this question of choice XA or CC65 is really important for a beginner ? (I hope no )
Or if this choice is really important only for high level coders, several years after having been a bebinner :-) ?

Subsidiary question : Once you are a good ASM coder, is it difficult to switch from XA to CC65 or vice-versa ?
The core thing is that XA was originally designed as an assembler for humans users, while CA65 was designed to be a back-end for a compiler.

If you understand XA, you will understand CA65, TurboAss, etc... and there are quite many of these!

Basically it all goes down to how the feature set matches the needs.

CA65 is a good choice for complicated projects using many overlays, memory banked stuff, because it has a very rich set of commands to handle all that.

The main problem is that CA65 is very verbose (for me) while XA basically can be used without any fancy required keywords and you can just add some scopes or fancy stuff here and there if you need it.

For me to be able to produce efficient assembler code, the code needs to be readable, and the less syntactic fluff there is in the way the better.

So any way, I'd say that the sane thing to do would be to start by the simpler syntax (even "frasm", the one from the original SDK from Fabrice, Alexios and Vagelis would work) and if it appears to be too limited migrate to another one.

Assuming they all use the same set of convention for immediate/absolute/hex, etc... it's generally trivial to convert from one to another using search and replace, and you can even validate that the conversion was done without any error by doing a binary compare of the resulting binary to make sure everything was converted properly.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: XA or CA65 ?

Post by Dbug »

Symoon wrote: Thu Jul 21, 2022 10:24 am XA is now the (very short) majority. From what I've understood, it seems a bit simplier to start, and it's in the OSDK so I guess I'll have a go with it.
Thanks to all for your help, comments, votes, ... And I suppose, see you soon with stupid problems and a desperate Symoon ;)
Also remember there are a few sample programs in the OSDK like the very simple hello world in sample\assembly\hello_world_assembly and that the entire libraries are also available as pure XA assembler source code in the lib subfolder.

Like "lib/tape.s" contains that:

Code: Select all

;	Tape I/O.
_cwrite			; this writes a byte to tape
        ldy #$0
        lda (sp),y
        jmp $e65e

_cread			; reads a byte from tape
        jsr $e6c9
        jmp grexit2

_cwritehdr equ $e607	; writes a file header to tape
_creadsync equ $e735	; read synchro bytes (all 0x16 bytes)	
and "lib/clock.s" entire file is:

Code: Select all

;
; clock_t clock(void)	; return the system clock
;
_clock
	php
	sei
	ldx $0276
	lda $0277
	cli			; JEDE
	plp
	rts
	
And now I'm wondering why Jede added the CLI since the PLP will restore whatever was stored before the PHP
User avatar
Symoon
Archivist
Posts: 2307
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: XA or CA65 ?

Post by Symoon »

Ha ha, thanks Dom for helping me choosing in the end ;)
And Dbug for additional explanations.

(I haven't tried yet, I've drifted towards some graphics tests)
User avatar
ibisum
Wing Commander
Posts: 1646
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: XA or CA65 ?

Post by ibisum »

Great thread, I love hearing what you guru's are discovering with these assemblers.

As a non-guru, devoted Oric lover, what I want: an onboard editor and assembler that is worth the effort to set up and learn. Cross-compiling is productive - compiling/assembling/debugging onboard, just much more fun.

I've been trying to get a MONASM.DSK built for the last few weeks in my (very few) Oric sessions, but haven't had much luck. But I continue to yearn for an Otic-onboard set of tools that would allow full assembly-based development with just the machine itself. I've thoroughly enjoyed the options on Amstrad (MAXAM, CHAMP, etc.) and would think we Oric people deserve something similar, at least ..
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: XA or CA65 ?

Post by Dbug »

ibisum wrote: Sat Jul 30, 2022 12:12 pm As a non-guru, devoted Oric lover, what I want: an onboard editor and assembler that is worth the effort to set up and learn. Cross-compiling is productive - compiling/assembling/debugging onboard, just much more fun.

I've been trying to get a MONASM.DSK built for the last few weeks in my (very few) Oric sessions, but haven't had much luck. But I continue to yearn for an Otic-onboard set of tools that would allow full assembly-based development with just the machine itself. I've thoroughly enjoyed the options on Amstrad (MAXAM, CHAMP, etc.) and would think we Oric people deserve something similar, at least ..
Imo, a reasonable way of doing that would be to use a cartridge system, like the ones used on the C64, because else you are losing quite a lot of memory, since you basically need to store the entire assembler/monitor/editor system, but also the source code of the program you are assembling.

With a cartridge which would have both 16K of ROM as well as the few components required to access the overlay memory, you could have a system that allows developing 48K Oric software by having the entire editor/assembler/disassembler in the ROM cartridge, but also having up to 16KB of source code inside the overlay memory so no main memory wasted by the source code.
Post Reply