I thought I could rely on hex2bin giving me the highest address in use by my program

By the way, the order of segments in SDCC is like this:

	.area _HOME
	.area _CODE
	.area _INITIALIZER
	.area _GSINIT
	.area _GSFINAL
	.area _DATA
	.area _INITIALIZED
	.area _BSEG
	.area _BSS
	.area _HEAP

I can ask on SDCC-forums too.

Hi Bengalack, it seems you are using a customized crt0, which apparently defines a saner area order than my templates' crt0.
Would you care to share it with me? Is that a a MSX-DOS project(hence 0x100 related stuff)?

By the way, Is that Visual Studio Code? If so, did you manage to get it instantianting a template automatically or you did so manually?

This special version of both the crt0 and the make-file is based off of your templates for Visual Studio! For various reasons I had to make specialized versions. Now using Visual Studio Code - it's just much leaner than Visual Studio when you get into it, I think.

Yes, you are correct, it looks funny with a start at 0x00F9. It is a bin file, working in "com"-area :-)

CRT:

	.module	crt0
	.globl	_main

	.globl  l__INITIALIZER
	.globl  s__INITIALIZED
	.globl  s__INITIALIZER

	.area _HEADER (ABS)

	;.org	0x0100 - 7
	.org	0x00F9
	.db 	0xFE
	.dw 	init
	.dw		end
	.dw 	init

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

init:
	ld	bc, #l__INITIALIZER
	ld	a, b
	or	a, c
	jp	z,_main
	ld	de, #s__INITIALIZED
	ld	hl, #s__INITIALIZER
	ldir

	jp	_main

	;; Ordering of segments for the linker.
	.area	_HOME
	.area	_CODE
	.area	_INITIALIZER
	.area	_GSINIT
	.area	_GSFINAL
	.area	_DATA
	.area	_INITIALIZED
	.area	_BSEG
	.area	_BSS
	.area	_HEAP

Due to memory constraints, I have had to make specialized crts that make it possible to place a file/executable, in DOS-environment, at the location of my choice, and not only 0x100. I "format" them as bin files.

Not sure if all this have anything to do with the current problem, but I can elaborate on the setup anyway:

All this is done because I'm running out of memory otherwise :-)

1. "launcher.com" is loaded and executed (a com-crt0, starts at 0x0100 as normal, no big size). Launcher loads a bin file header (7 bytes) into ram, looks at the start and stop-values, and loads the rest of the file into the correct location in memory, and then calls it's _main. (in practise, it will never return unless there is an error, so it is merely a jp). This file is "orchestrate.bin.
2. "orchestrate.bin" has a crt0 with a specified location at 0xCD00. The purpose of this is to load and execute several other bin-files located at various pages/addresses (in the same manner as launcher.com). I have split the game into several smaller code chunks that may be used only once, and some reused. If to be reused, I just put the code into a special/"stored" segment (mapper).
3. The last bin-file loaded, is "game.bin". The 0x00F9 is just the offset, and is used for header information only. The code will be loaded in at 0x0100.

The funky thing with this approach is that I overwrite my original values at 0x0100 with the last "game.bin". This seems to work, but I might totally be violating some dos-mechanisms by doing this. I return to dos at the end by calling call 5. Stack pointer seems happy, and everyone is happy (?) So far.

My only gripe is why game.bin-filesize is not covering the "whole executable". But maybe @Giangiacomo Zaffini 2 will clear up things.

Thanks. But --it didn't work Seems like a small fix you did, but hex2bin filesize is 25kB vs original 47kB Anyways, the difference in my file(s) ended up to be 2 bytes. In addition that the application itself stopped working, so this might be a wrong lead

I wonder if the ihx-files is the source of this?

Thanks! So the issue must be in the ihx-generation from SDCC, it seems:

C:\source\repos\noname\project\Debug\objs>hex2bin -e bin game.ihx  
hex2bin v2.5, Copyright (C) 2017 Jacques Pelletier & contributors

Allocate_Memory_and_Rewind: 
Lowest address:   000000F9  
Highest address:  00007B04  
Starting address: 000000F9  
Max Length:       31244     

Binary file start = 000000F9
Records start     = 000000F9
Highest address   = 00007B04
Pad Byte          = FF      

C:\source\repos\noname\project\Debug\objs>ihx2bineng game.ihx game.bin
IHX2BIN
===========================================
2018/02/10 t.hara, coder g.zaffini

start address     0xf9
end_address       0x7b04
execution_address 0xf9

Complete.

C:\source\repos\noname\project\Debug\objs>

And BTW: The game works using IHX2BIN