Thread: Previously working code switches byte order when processing Motorola "S" file.

  1. #1
    Registered User
    Join Date
    Aug 2022
    Posts
    1

    Previously working code switches byte order when processing Motorola "S" file.

    G'day all:


    I'm new here and to the C language. I seek an answer about a problem I have with either C or make.


    General info:
    Pretty much a novice with C and especially make.
    Got an archive file from GitHub (Benschop 6809sbc)
    Function of the archive: a complete package of software that creates 6809 machine (object) code to be run on an Intel (PC) Linux box. In my case I'm running a 32-bit version of Linux on a 64-bit CPU.


    The problem:
    I unpacked Lennart Benshop's archive (tar) package into a folder/directory and ran 'make'.
    Works! Great! "Make" compiled an assembler (a09) from C source (a09.c)
    The assembler is used to assemble the source (monitor.asm) for a small monitor program. Benschop's monitor program worked too!


    The output of the assembler is Motorola "S" ASCII-hex format file.
    To generate the object code for the virtual machine the "S" file is processed by another program, makerom.c. Clearly works, because I can run the simulator/virtual 6809/emulator and see the sign-on message from Benschop's monitor: "Welcome to Buggy 1.0"


    The problem: I made trivial mods to the original assembly source. (Gave the modded file a new name, z.asm) Assembled z.asm. Got a Motorola "S" format file that (in my view) looks good. (see below).
    Processed the "S" file and ran the object code. !disaster - doesn't run! But it should run, I barely changed anything. (Well, I changed the sign-on message and added x2 'no-op' statements at the beginning - but hey! That is nothing!


    When I process the "S" file (through "makerom") the byte order in the machine code file appears to be switched. I made the trivial changes to the file-names in make. Ditto for the code in makerom.c, z.asm and Makefile. Clearly the code supplied in the archive is good - it compiled the assembler and the assembler created an "S" file and this was processed correctly by 'makerom'.


    Now makerom appears to switch the order of the bytes when processed by makerom.


    The first few lines of the "S" file (with spaces to facilitate reading)

    . . . . . . . . . . . . . . . V V V V
    S1 13 E400 12 12 1A FF 4F 1F 8B 10 CE 04 00 8E E5 22 CE 02 8B S1 13 E410 80 C6 1B 8D 37 etc ...

    S id cc addr data ......................................data chksum
    To calc. chksum, add the value of every byte from the character count (cc) to the end; if the sum exceeds 0xFF, then knock of the ms byte by 'and'-ing with 0xFF. When adding is done, subtract the result (here 0x74 for the first line) from 0xFF to get 8B. This is calculation used to get the checksum for every line. (but the checksum is good!)

    Here is the object dump file, got by: od -x vm09.rom | less
    0062000 1212 ff1a 1f4f 108b 04ce 8e00 22e5 02ce
    . . . . . . . . . . . . . ^.... ^
    Red markers show reversed bytes.
    Helpful comment appreciated!

    Собака
    Attached Files Attached Files

  2. #2
    Registered User
    Join Date
    Dec 2017
    Posts
    1,642
    I think you are misinterpreting od's output. Every 2-byte unit looks "reversed" because your machine is little-endian.
    Try od -Ax -tx1 -N 128 vm09.rom
    A little inaccuracy saves tons of explanation. - H.H. Munro

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 5
    Last Post: 10-26-2017, 08:25 PM
  2. Replies: 2
    Last Post: 12-23-2012, 04:52 AM
  3. Replies: 2
    Last Post: 07-22-2004, 02:25 AM
  4. "itoa"-"_itoa" , "inp"-"_inp", Why some functions have "
    By L.O.K. in forum Windows Programming
    Replies: 5
    Last Post: 12-08-2002, 08:25 AM
  5. "CWnd"-"HWnd","CBitmap"-"HBitmap"...., What is mean by "
    By L.O.K. in forum Windows Programming
    Replies: 2
    Last Post: 12-04-2002, 07:59 AM

Tags for this Thread