[Z80] High 8 bits of address not exported into IHX

[Aoineko]

Hello,

I'm working on a large mapper for MSX and I'm running into what seems to be a bug in SDCC (asz80) IHX generator.
I have data blocks at addresses greater than 0x00FF'FFFF which seem to be correctly recognized by the linker since the generated .MAP is correct, but which are not correctly exported in the .IHX file.

For example, I have labels at addresses 0x01F4'5000h and 0x0320'7800 which are well defined in the .MAP (see below), but the 2 corresponding lines in the .IHX are:

:0200000400F406 // Address high 16-bit value of 0x00F4 instead of 0x01F4
:020000040020DA // Address high 16-bit value of 0x0020 instead of 0x0320

I haven't found an option in the linker to work around this bug-like problem.

Here's the part of the .MAP file with the correct addresses:

Area                                    Addr        Size        Decimal Bytes (Attributes)
--------------------------------        ----        ----        ------- ----- ------------
_SEG500                             01F45000    00000057 =          87. bytes (REL,CON)

      Value  Global                              Global Defined In Module
      -----  --------------------------------   ------------------------
     01F45000  _Seg500Func2                       s_neo8_s500_b0
     01F4500B  _Seg500Data1                       s_neo8_s500_b0
     01F4501F  _Seg500Data2                       s_neo8_s500_b0
     01F45033  _Seg500Func1                       s_neo8_s500_b0

Area                                    Addr        Size        Decimal Bytes (Attributes)
--------------------------------        ----        ----        ------- ----- ------------
_SEG800                             03207800    00000057 =          87. bytes (REL,CON)

      Value  Global                              Global Defined In Module
      -----  --------------------------------   ------------------------
     03207800  _Seg800Func2                       s_neo8_s800_b5
     0320780B  _Seg800Data1                       s_neo8_s800_b5
     0320781F  _Seg800Data2                       s_neo8_s800_b5
     03207833  _Seg800Func1                       s_neo8_s800_b5

Does anyone have a solution?

[Jakub Ladman]

Hi,

It's been some time I was dealing with something maybe a bit similar.

The ihx output wasn't properly ordered, the data was ok, but different
memory chunks were laid as encountered by linker.

The addresses of the block were jumping up and down in random manner.

I solved it by passing the file thru
https://srecord.sourceforge.net/man/man1/srec_cat.1.html which can order
the blocks by their starting addresses.

Maybe it'll help.

Cheers

JL

Dne 13.12.2023 v 1:25 Aoineko napsal(a):

Hello,

I'm working on a large mapper for MSX and I'm running into what seems
to be a bug in SDCC (asz80) IHX generator.
I have data blocks at addresses greater than 0x00FF'FFFF which seem to
be correctly recognized by the linker since the generated .MAP is
correct, but which are not correctly exported in the .IHX file.

For example, I have labels at addresses 0x01F4'5000h and 0x0320'7800
which are well defined in the .MAP (see below), but the 2
corresponding lines in the .IHX are:

|:0200000400F406 // Address high 16-bit value of 0x00F4 instead of
0x01F4 :020000040020DA // Address high 16-bit value of 0x0020 instead
of 0x0320 |

I haven't found an option in the linker to work around this bug-like
problem.

Here's the part of the .MAP file with the correct addresses:

|Area Addr Size Decimal Bytes (Attributes)

---

_SEG500 01F45000 00000057 = 87. bytes (REL,CON) Value Global Global
Defined In Module ----- --------------------------------
------------------------ 01F45000 _Seg500Func2 s_neo8_s500_b0 01F4500B
_Seg500Data1 s_neo8_s500_b0 01F4501F _Seg500Data2 s_neo8_s500_b0
01F45033 _Seg500Func1 s_neo8_s500_b0 Area Addr Size Decimal Bytes
(Attributes) -------------------------------- ---- ---- ------- -----
------------ _SEG800 03207800 00000057 = 87. bytes (REL,CON) Value
Global Global Defined In Module ----- --------------------------------
------------------------ 03207800 _Seg800Func2 s_neo8_s800_b5 0320780B
_Seg800Data1 s_neo8_s800_b5 0320781F _Seg800Data2 s_neo8_s800_b5
03207833 _Seg800Func1 s_neo8_s800_b5 |

Does anyone have a solution?

---

[Z80] High 8 bits of address not exported into IHX
https://sourceforge.net/p/sdcc/discussion/1865/thread/446beaf1f6/?limit=25#894a

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/sdcc/discussion/1865/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Aoineko]

I don't think it's the same problem.
The 8 most significant bits of the address are absent from the IHX file, so whatever processing I do on this file won't bring back the lost information.
In my opinion, the problem is that the linker handles 32-bit addresses correctly (since they are correct in the .MAP file), but only the 24 least significant bits are exported to the IHX file.
It looks like a simple bug.
Where can I find the linker source code so that I can check the IHX export?

[Aoineko]

Ok, I'm continuing to follow the track. The problem seems to be already present in .REL whose format is XL3, i.e.:

X = Hexidecimal radix
L = Least significant byte first
3 = 24-Bit Addressing

Now, I need to find out how to generate 32-bit .REL files...

[Aoineko]

I've read the documentation for SDCC, asz80 and aslink but I can't find a way to generate a relocatable file that's 32 bits instead of 24.

Can anyone help me?

[Aoineko]

Ok, I found the problem!

In the sdasz80 source code, a_bytes variable (memory space size) is hardcoded to 3 (24-bit) so REL file is generated as "XL3" format (instead of "XL4") and so lost the address highest 8 bits.
If there is any good reason for this not being set to 4 (32-bit), we need at least an option to activate the 32-bit mode.
The value is hardcoded in minit() function in z80mch.c line #2148.

Who can fix that?
Do I have to fill out a feature request form?

[Giangiacomo Zaffini]

Vanilla ASxxxx assembler/linker has assembly directives for bits addressing mode. I've never used them.
I don't know much how SDCC manage addressing/relocable addressing.

[Maarten Brock]

This is further handled through [features:#896]