Intel hex file to binary to MSX memory

Par jepmsx

Master (242)

Portrait de jepmsx

18-12-2022, 20:46


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:
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?

!login ou Inscrivez-vous pour poster

Par jepmsx

Master (242)

Portrait de jepmsx

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.

Par jepmsx

Master (242)

Portrait de jepmsx

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

Par pizzapower

Master (155)

Portrait de pizzapower

26-12-2022, 07:05

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


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

        push hl

Par jepmsx

Master (242)

Portrait de jepmsx

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

Par pgimeno

Champion (328)

Portrait de pgimeno

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.

Par jepmsx

Master (242)

Portrait de jepmsx

08-01-2023, 07:55

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

Par aoineko

Paladin (899)

Portrait de aoineko

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).