wrong disassembly

[jotd]

This is the result of wrong coding, disassembling in winuae:

0003bc2c 1038 8260                move.b $8260,d0

but this is actually a ".W' addressing mode out of range. So it's in the $FFFF8260 range.

it should print

0003bc2c 1038 8260                move.b $FFFF8260,d0

Also found another annoying issue: CTRL+C when nothing is selected acts as "break" and quits winuae.

[Toni Wilen]

I can change it to -$xxxx if negative word address (that some disassemblers use). $ffff.. is too ugly. I also want it to be very clear if address is long (8 digits) or word (4 digits).

CTRL+C when nothing is selected acts as "break" and quits winuae.

Yes, and it is by design because I like quick way to quit winuae
But seriously, why does it matter, CTRL+C won't work as a copy (or any other command) in Windows console windows.

[jotd]

Originally Posted by Toni Wilen

I can change it to -$xxxx if negative word address (that some disassemblers use). $ffff.. is too ugly. I also want it to be very clear if address is long (8 digits) or word (4 digits).

that sounds good

Yes, and it is by design because I like quick way to quit winuae
But seriously, why does it matter, CTRL+C won't work as a copy (or any other command) in Windows console windows.

on windows 10 console it does. windows 10 console is so much better than windows 7 in terms of selection & copy/paste.

[meynaf]

$FFFF8260 might be ugly, however it has a meaning - this is Atari ST hardware register - but a negative value would be meaningless.
The correct way to disassemble it is $ffff8260.w.

[Toni Wilen]

Address != addressing mode.

I don't think there is "correct" option. I don't remember seeing Motorola documenting how short absolute should get disassembled when address is negative.

quick checks:

mon and asmone: -$xxxx.w
hrtmon: (-$xxxx).w
ar3: $ffffxxxx.S

I'll make it configurable (some other disassembler options are already configurable)

[meynaf]

16-bit "negative" addresses aren't used on the Amiga so it's clear Amiga-only disassemblers didn't care that much about them.
But they are used very often on the ST. You'll see things such as $ffff8260.w as shortcut to $00ff8260 (this always works, though theoretically incorrect). If the disassembler shows the $ffff8260 version it's easy to understand, while -$7da0 is completely meaningless. Shouldn't the most readable version be preferred ?

Quick check : MonAm (Devpac) shows $ffffxxxx.w as expected.

[BippyM]

How does this affect winuae though? It is an Amiga product, so surely the Amiga disassembley is all that matters???



Am I missing something?

Originally Posted by meynaf

16-bit "negative" addresses aren't used on the Amiga so it's clear Amiga-only disassemblers didn't care that much about them.
But they are used very often on the ST. You'll see things such as $ffff8260.w as shortcut to $00ff8260 (this always works, though theoretically incorrect). If the disassembler shows the $ffff8260 version it's easy to understand, while -$7da0 is completely meaningless. Shouldn't the most readable version be preferred ?

Quick check : MonAm (Devpac) shows $ffffxxxx.w as expected.

[jotd]

it's just a detail as those addresses are not really useful. Is there valid memory in some config at $FFFFxxxx ?

[Toni Wilen]

My point still remains: unless Motorola documented it, there is no official or correct format.

And so far it seems Amiga-only disassemblers use 4 digit format.

Only reason I can optionally support it is because Hatari uses UAE CPU core. It would make sense to have hardware matching disassembly format.

Is there valid memory in some config at $FFFFxxxx ?

I don't think so. (assuming 32-bit space). CSPPC has something nearby but I think it was FFF8xxxx or something.

on windows 10 console it does. windows 10 console is so much better than windows 7 in terms of selection & copy/paste.

I always use latest Windows version (usually pre-release even). I do know console was heavily modified but I didn't know CTRL+C has dual-function now because it has always been console break almost everywhere, not just Windows.

[jotd]

Originally Posted by Toni Wilen

I didn't know CTRL+C has dual-function now because it has always been console break almost everywhere, not just Windows.

Another example how Microsoft stole ctrl+c from unix, but still used ctrl+c to copy from clipboard (unix used mouse buttons, shift+ins...) then mixed them both together for a nice backfire...

Same goes for all the shit Microsoft invented to avoid adopting unix special characters (backslash instead of slash, CR+LF instead of LF...) then went on having to support filepaths with slashes and unix linefeeds in windows, regexes... Bill Gates - that visionnary...

[meynaf]

Originally Posted by BippyM

How does this affect winuae though? It is an Amiga product, so surely the Amiga disassembley is all that matters???

Am I missing something?

You are missing the fact occasionnal ST code remnants can be found in Amiga programs, exactly like what happened to the OP.

Originally Posted by Toni Wilen

My point still remains: unless Motorola documented it, there is no official or correct format.

Mine does too : in that case the most readable format must prevail.

[BippyM]

Originally Posted by meynaf

You are missing the fact occasionnal ST code remnants can be found in Amiga programs, exactly like what happened to the OP..

There you go I was missing something

[meynaf]

For those who want to know, $(ff)ff8260 on the ST is hardware video mode register.

[npomarede]

Originally Posted by Toni Wilen

Address != addressing mode.

I don't think there is "correct" option. I don't remember seeing Motorola documenting how short absolute should get disassembled when address is negative.

quick checks:

mon and asmone: -$xxxx.w
hrtmon: (-$xxxx).w
ar3: $ffffxxxx.S

I'll make it configurable (some other disassembler options are already configurable)

Hi
another possibility, often used in ST asm sources is to add ".w" to the address, keeping the address as it is in the opcode word :
move.w $8260.w,d0


ie : this doesn't change the address to a negative one, which as pointed by meynaf is hard to read in an ST context.


Nicolas

[ross]

Stupid Amiga snippet that uses negative addresses, too bad it only works in machines with 24 bit addressing:

	suba.l	a0,a0
	suba.l	-20.w,a0   ; <--- :)
	move.l	a0,12.w
	jmp     -1(a0)

Do not use this code! NEVER!

You have been warned

[roondar]

Only ross would show us some code and then tell us to never use it. It's almost as if he's daring us

[Thomas Richter]

Originally Posted by jotd

it's just a detail as those addresses are not really useful. Is there valid memory in some config at $FFFFxxxx ?

It may, and there are cases in which there is. If you use MuRedox, the topmost 32K of memory contain the jump-table into the FPU emulation functions. What MuRedox does is that it replaces the 4-byte FPU opcodes by subroutine jumps into the emulation functions, and these emulation functions are kept in the topmost 32K. The reason why the topmost 32K are used for that is that a JSR.W can be used to reach them, requiring as many bytes as opcode as the original FPU instruction.

[meynaf]

Originally Posted by ross

Stupid Amiga snippet that uses negative addresses, too bad it only works in machines with 24 bit addressing:

    suba.l    a0,a0
    suba.l    -20.w,a0   ; <--- :)
    move.l    a0,12.w
    jmp     -1(a0)

There we clearly see -$20.w is meaningless, where $(ff)ffffec goes in rom. And that displaying $ffec.w would be completely wrong (sorry Nico ).

Originally Posted by ross

Do not use this code! NEVER!

You have been warned

Well, the program is dead even if this code works as expected