I'm trying to write a binary file using vasm68k_mot (Motorola 68k) writing File-Size and File-Offset everything goes well, except that M68K is Big-Endian, there's a way I can change to Little-Endian in a simple way?

Let's say that the FileZ.bin has a size of 30Kb, this in hex should be 0x7530 in my binary file it writes in hex value "00 00 75 30", but I need to mirror that value to "30 75 00 00" The same applies for the file offset address.

I'm sorry if this is confusing, I'm not a programmer nor expert in ASM.

My code is like this:

dc.l    0,(FILEY_END-FILEY_START)               
cnop    0,2048

    incbin C:\FileZ.BIN
    cnop    0,2048

    incbin C:\FileY.BIN
    cnop    0,2048
    incbin C:\FileX.bin

EDIT: The documentation provided by @AlexHajnal is the same i'm using, thank you! I also will link it here: http://sun.hasenbraten.de/vasm/release/vasm.pdf

EDIT: All I need to is SWAP those "dc.l" values, they are 4 bytes long, I tried writing

ROL.W   #8,D0
SWAP    D0
ROL.W   #8,D0

but i got some random numbers, it may be related to vasmm68k_mot, but i really don't know....

  • 1
    Do you want to perform endian conversion while the program is running, or do you want it hardcoded in your file already endian-converted? May 19, 2021 at 5:59
  • (By the way, this seems a pure programming question either way; regular Stack Overflow may be a better place for it.) May 19, 2021 at 6:00
  • @AlexHajnal Good work, if it is the one. Looks promising to provide a macro. ;-) May 19, 2021 at 7:56
  • @user3840170 I want to perform the BE to LE while the program is running, if possible, of course.
    – Raoni
    May 19, 2021 at 11:43
  • I'm not sure how this file is intended to be used but I think the first line should be dc.l FILEY_START,(FILEY_END-FILEY_START) rather than dc.l 0,(FILEY_END-FILEY_START). That's assuming that the first 2kB block contains pointers and lengths within the file. May 19, 2021 at 13:07

3 Answers 3


My original take on the question:

For longs (32-bit), this is answered here. For shorts (16-bit) just use ROL.W #8, D0.

If @thebusybee's interpretation of the question is correct (which appears to be the case) then the answer would appear to be "No" (when targeting MC68000). From page 6 of the vasm manual:

... a constant is built according to the endianess of the target.

However, if you change the target to something little-endian (e.g. x86 instead of 68000) then computed values will be stored as little-endian.

To use a different target you'll need to change the syntax of your assembler source file. For example, the x86 equivalent of the source you posted (as of 2021-05-19 21:45Z) is:

.balign    2048

    .incbin C:\FileZ.BIN
    .balign    2048

    .incbin C:\FileY.BIN
    .balign    2048
    .incbin C:\FileX.BIN

The above should be placed in a file named file.s

To create your output file (to be named file.bin) run:

vasmx86_std -Fbin -o file.bin file.s

You may need to tweak the file names/paths above (I tested on Linux then added the C:\ prefixes to what I posted above).

  • 1
    I understand the question this way: The bytes should be stored in LE directly. The OP did not ask for some code to swap. Just my 2 cents. May 19, 2021 at 7:42
  • @AlexHajnal, i'm using both dc.w and dc.l, Where can I add the ROL and SWAP into my code?
    – Raoni
    May 19, 2021 at 11:27
  • @thebusybee I won't mind a code to swap, if this mirrors the value :-), But I don't know how can I use the ROL and SWAP functions into the .asm file...
    – Raoni
    May 19, 2021 at 11:41
  • 5
    @Raoni Code swaps during runtime by execution of the processor. And if you don't know how to apply the suggestions, you have a bigger problem. You need to learn, honestly. BTW, ROL and SWAP are not functions, they are instructions to the target processor. May 19, 2021 at 11:47
  • On the original 68000, the rotate-left instruction is sufficiently slow that loading two bytes separately and then storing two bytes separately will sometimes be faster than loading a 16-bit word, performing a rotate left, and then storing the result.
    – supercat
    May 19, 2021 at 16:04

This is just an alternative for the poor lost souls coming here for help. ;-)

Instead of code to be run by the processor, this solution generates a 32-bit value in little endian right in place.

The assembler has macro capabilities, and a macro can be used:

  • dc_l_le is the name of the macro. Look at it as a new pseudo instruction. It means "define constant, long, little endian".
  • The macro handles different number of expressions, tested with 2, but I'm sure there is a limit.
  • The number of expressions is obtained by \# and used for a repetition loop.
  • The n-th expression can be obtained by \+. This special value inserts one expression after the other. On each repetition the local symbol .value is set to the expression.
  • Shifting and masking separates the bytes.
dc_l_le macro
        rept    \#
.value  set     \+
        dc.b    (.value>>0)&$FF
        dc.b    (.value>>8)&$FF
        dc.b    (.value>>16)&$FF
        dc.b    (.value>>24)&$FF

    org $12345678

    dc_l_le 0,(FILEY_END-FILEY_START)               
    cnop    0,2048

    incbin FileZ.BIN
    cnop    0,2048

    incbin FileY.BIN
    cnop    0,2048
    incbin FileX.bin

Note: This otherwise good looking assembler cannot handle whitespace in expressions. I'd love to write (.value >> 24) & $FF but this led to irritating error messages. It took some time to find the reason.


The command line for this suggestion is:

vasmm68k_mot.exe -Fbin -o test.bin -L test.lst test.S

The specific output format is not important, I think, and the listing is generated just to see that the solution works. The "S" source extension is deliberately chosen out of habbits.

The assembler shows these versions, I used the provided binary on Win10:

vasm 1.8k (c) in 2002-2021 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.4 (c) 2002-2021 Frank Wille
vasm motorola syntax module 3.15a (c) 2002-2021 Frank Wille
vasm binary output module 2.1 (c) 2002-2021 Volker Barthelmann and Frank Wille

To avoid relocation errors, an org pseudo instruction is added just for demonstration, but the real thing is most probably allocated in other ways.

  • I tried assembling this using vasm68k_mot but got illegal relocation errors for the dc.b lines. What command line did you use? (also, adding -cnop=0x0000 to the command line might be desirable) May 22, 2021 at 14:01
  • Well, what is your command line? (Optimally you add it to your question.) May 25, 2021 at 6:59
  • I used ./vasmm68k_mot -Fbin -o test2.bin test2.s but got the same result with ./vasmm68k_mot -Fbin -o test2.bin -L test2.lst test2.s The errors are: error 39 in line 2 of "REPEAT:dc_l_le:line 7": illegal relocation called from line 7 of "dc_l_le" called from line 12 of "test2.s" > dc.b (.value>>0)&$FF ... The assembler was compiled on Linux from the latest source release (source release 1.8k: vasm 1.8k, vasm M68k/CPU32/ColdFire cpu backend 2.4, vasm motorola syntax module 3.15a, vasm binary output module 2.1). May 25, 2021 at 7:11
  • Since I presumed that you showed us just a cut-out, there is no ORG in my source. I'll add it. May 25, 2021 at 7:24
  • Adding org $0 after the macro definition makes it work fine. May 25, 2021 at 7:39

Unless you know something about the file data, I think the simple answer is 'no'. If the data was bytes, they would be in the same order. If it was 16-bit words, they would be swapped in pairs. If it was 32-bit words, then 4 bytes would be reversed.

I would imagine you could look at a dump of the data and make a reasonable guess most of the time. But there is no simple swapEndian.exe tool that can do it for you.

[Off-topic, but I am now intrigued: I wonder how good a neural net might be at guessing and swapping?]

  • 1
    From the OP's later comments it sounds like they want to force the endian-ness of the values computed by vasm, not the values read from external files (i.e. from C:\FileZ.BIN et al.). With vasm, the endian-ness used for computed values is determined by the chosen target (MC68000 in this case, which is big-endian) and vasm provides no option to change this behaviour. To get the computed values in little-endian they need to switch to a little-endian target (such as x86). May 19, 2021 at 20:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .