HD6303 aim, tim, oim wrong opcodes

[iddq]

                        processor hd6303

                        org $ff60

                        aim     10,10

Dasm generates 71,0a instead of 71,0a,0a
https://www.jaapsch.net/psion/mcmnemnm.htm
I think aim should be coded as the following:

aim #$80, $17 ;71 80 17
aim #$80, 0,x ;61 80 00

[andrew-davie]

Here are some specs of AIM instruction from the HD6803 handbook...

So, yes they are both 3-byte instructions, and there is an error.
Next, someone to fix this....?

[dionoid]

This seems to be a known issue, which would require major work on the parser code.

I found a workaround by PHF in the sourceforge repo, which I copied over into this github repo (in the release/2.20.12 branch).
As Peter says: "...in retrospect it seems obvious that these opcodes simply don't fit into the "regular pattern" of 8-bit CPUs we deal with in DASM".
Reference to commit on sourceforge: https://sourceforge.net/p/dasm-dillon/code/355/

Basically, the workaround is to use macros 'aimd', 'aimx', 'oimd', 'oimx', etc. Example:

.processor HD6303

.mac hack
dc.b	{1}	; opcode
dc.b	{2}	; immediate value
dc.b	{3}	; zero-page address
.endm

.mac aimd
hack	$71,{1},{2}
.endm

.mac aimx
hack	$61,{1},{2}
.endm

.mac oimd
hack	$72,{1},{2}
.endm

.mac oimx
hack	$62,{1},{2}
.endm

.mac eimd
hack	$75,{1},{2}
.endm

.mac eimx
hack	$65,{1},{2}
.endm

.mac timd
hack	$7b,{1},{2}
.endm

.mac timx
hack	$6b,{1},{2}
.endm

.org $0

; the broken DASM versions

aim	$10	; assembles to 71 10
aim	$10,x	; assembles to 61 10
oim	$10	; assembles to 72 10
oim	$10,x	; assembles to 62 10
eim	$10	; assembles to 75 10
eim	$10,x	; assembles to 65 10
tim	$10	; assembles to 7B 10
tim	$10,x	; assembles to 6B 10

; the fixed macro versions

aimd	$10,$20	; should be "aim #$10,$20"
aimx	$10,$20	; should be "aim #$10,$20,x"
oimd	$10,$20	; should be "oim #$10,$20"
oimx	$10,$20	; should be "oim #$10,$20,x"
eimd	$10,$20	; should be "eim #$10,$20"
eimx	$10,$20	; should be "eim #$10,$20,x"
timd	$10,$20	; should be "tim #$10,$20"
timx	$10,$20	; should be "tim #$10,$20,x"

.end

[thrust26]

This seems to be a known issue, which would require major work on the parser code.

As Peter says: "...in retrospect it seems obvious that these opcodes simply don't fit into the "regular pattern" of 8-bit CPUs we deal with in DASM".

IMO makes perfect sense to close this then.

[andrew-davie]

I did a bit of looking at the code, and it seems to me that you would just need to add one or more "AF_*" flags, to handle the new addressing modes presented by these instructions. I did not look deep into the parser, but instead the definitions of the opcodes for the processor involved. Is it really such a hard thing to do this properly?

[dionoid]

Maybe I have jumped to conclusions to soon; reopening the bug now....

[msaarna]

It's not just a matter of adding new AF_*. Off the top of my head... the parser is presently hard coded to take a comma and use the index after it to adjust the opcode address mode, rather than embed a value. Only one comma is expected. There's only one label/symbol per opcode.
All of this seems to be trivial when you say it, but it's happening within a character based parser that's tasked with fleshing out opcodes, operands, and expressions, as it chugs from left to right through the string.
The parsing engine is ignorant of architecture, so adding something like "[opcode] $10,$20" will make it an equally valid form for the 6502.
In short, I agree with Peter. We have a workaround, so I'm closing out the issue.