Each of the 68K series CPUs had dedicated address-generation hardware which was wired more directly to the A registers and had only limited access to the D registers. Conversely, the main ALU was more directly wired to the D registers than the A registers. It thus became a performance enhancement, allowing the main ALU and the addressing logic to operate ...
Swapping byte lanes on the physical bus would, in any case, only have an effect on naturally aligned data in memory, which happened to be the same width as the bus. Swapping the lanes of a 16-bit bus doesn't solve the problem for 32-bit data, nor on a 32-bit bus for 64-bit or 80-bit data (the latter being associated with floating point). So that is not a ...
Yes, you can use -phxass option (name of the old Amiga native assembler by Phx/Frank Wille who is also the author of the Motorola syntax module)
vasm -phxass -m68020 -kick1hunks -Fhunkexe -o test.exe main.asm
From the documentation:
PhxAss-compatibility mode. Only directives known to PhxAss are recognized. Enables the following features:
Since you mentioned the Amiga in your question, it ought to be relevant as to how this problem was solved efficiently on that system.
As I understand, the "glue" logic for the Bridgeboards consisted mainly of 128KiB of dual-ported RAM accessible by both the Intel CPU on the Bridgeboard and the Amiga's 68K. This would be sufficiently large to buffer ...
Adding command line option -spaces will do the trick by allowing spaces within operands. This means of course that comments now must be separated by ; from any instruction or directrive. Unlike with -phxass (which includes -spaces), there are no other side effects.
The option is only available with Motorola syntax (vasmm68k_mot).
On a sidenote, it may be ...
The primary advantage of the 68000 segregating address and data registers is the ability to have many instructions use three-bit register-select fields, thus saving opcode space compared with using four-bit fields. IMHO, the ARM Thumb instruction set and derivatives could have benefited from employing such a concept, since otherwise the upper registers end ...
This take a little more circuitry than the OP, in that the byte-swapper has to make use of the Function Code bus lines (FC0, FC1 and FC2) to distinguish between data transfers and instruction fetches. Bytes should only be swapped for data transfers; applying byte-swapping to instructions will wreck the execution of software.
The job is non-trivial, but I don't think it would be hard for someone 'experienced in the art'. 256k or even 512k is not a lot of code, and the ROMs are highly structured with a well-defined interface. I suspect it would be easier than cracking some of the more sophisticated copy-protection schemes used in Amiga games.
In some respects ROM code is easier ...
According to the project page on GitHub for the Open68000Relocator board:
The board has been tested and proved to be
working perfectly with a TF530 card running
at 50 MHz.
So, if you can use the same swapping of the 68k orientation in the CDTV, then this re-locator would probably have a good chance of working. Likewise, some minor variation that does not ...
Look at phase/dephase directives (also known as rorg/rend) - e.g. in the vasm manual. The whole code should like:
... (will be assembled for "org RAM_BEGIN", but stored immediately after previous code)