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? – user3840170 May 19 at 5:59
  • (By the way, this seems a pure programming question either way; regular Stack Overflow may be a better place for it.) – user3840170 May 19 at 6:00
  • @AlexHajnal Good work, if it is the one. Looks promising to provide a macro. ;-) – the busybee May 19 at 7:56
  • @user3840170 I want to perform the BE to LE while the program is running, if possible, of course. – Raoni May 19 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. – Alex Hajnal May 19 at 13:07

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. – the busybee May 19 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 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 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. – the busybee May 19 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 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) – Alex Hajnal May 22 at 14:01
  • Well, what is your command line? (Optimally you add it to your question.) – the busybee May 25 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). – Alex Hajnal May 25 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. – the busybee May 25 at 7:24
  • Adding org $0 after the macro definition makes it work fine. – Alex Hajnal May 25 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). – Alex Hajnal May 19 at 20:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.