Intel hex file to binary to MSX memory

Master (253)

18-12-2022, 20:46

Hi!

I have a doubt about how it works the process from and hex file generated by sdcc to binary to MSX.

For example, the first line of my ihx file is:
:200106003E02D3993E8FD399DB991F3E00D3993E8FD399DA0601C901000021020039799668
following the explanation of the ihx file the first part :20010600 is explanation of the line, so the binary code that I want in memory of the MSX is 3E02D3... (the last two characters (68) is the cheksum).
Translating to a binary format using hex2bin I get CDEEADC3. I was expecting that the program would remove the header and leave only 3E02D3, not to transform it to CDEEADC3. Why is that?
If the binary file is a .com file, when it is loaded in MSX-DOS it loads the binary file at 0x100 and start to run from that point, so the first bytes to appear in memory should be 3E02D3. Am I right?

By jepmsx

Master (253)

19-12-2022, 12:51

Oh! I've discovered that 3E02D3 starts at position 6. So, the hex2bin add 6 bytes as a header and then copies the text values into bytes.
A new question arises, are these 6 bytes the same as in a binary file? These are:
byte 0+1: start-address
byte 2+3: end-address
byte 4+5: execution-address
But I have a problem with my theory, because in MSX-DOS the program starts at position 100H and not in CDEE which are the two first bytes of the generated COM file.

By jepmsx

Master (253)

20-12-2022, 10:25

After some testing I can say that the .COM file does not have a header. These first bytes are the crt0 file linked by SDCC and I think it must be in another part in the ihx file and then reubicated with the hex2bin tool.
I've also checked that setting a breakpoint in address 0x100 you can see that all the code of the .com file has been written in the MSX memory

By pizzapower

Master (165)

26-12-2022, 07:05

Aren't you doing something wrong? My .COM files created with SDCC start with:

:11010000CD...

Address is 0x100 as expected. Check if you are using a crt0_*.rel file that is appropriate for .COM files, like crt0_msxdos.rel. It shouldn't add start/end/exec addresses and it usually start with a CALL (0xCD), since it reserves space for global variables at 0x103 or above:

        ;--- Initialize globals and jump to "main"

init:   call gsinit
        jp   __pre_main

        ;--- Program code and data (global vars) start here

        ;* Place data after program code, and data init code after data

        .area   _CODE

__pre_main:
        push hl
        ...

By jepmsx

Master (253)

26-12-2022, 07:33

You are right, the start address is 0x100, and the first bytes are from crt0_*rel. I was confused because I didn't take into account the crt0 file

By pgimeno

Champion (328)

07-01-2023, 22:39

Intel Hex can have records that start at a different address, out of order. I'm pretty sure that somewhere in the file, there will be a record that starts at 0100 and is 6 bytes long.

I wrote a program for myself in Python to display a map of the addresses included in an Intel HEX, because that "feature" of jumping addresses can be confusing. It tells me which contiguous areas exist and whether there are any overlapping areas.

By jepmsx

Master (253)

08-01-2023, 07:55

Thanks pgimeno. You are totally right, there was a record that started at 0100 somewhere in the hex file.

By aoineko

Paladin (1002)

08-01-2023, 14:45

Maybe it's because you didn't put your crt0 file as the first object to be linked by SDCC?

It is recommended in the documentation that it be the case (crt0 first).