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

Door Bengalack

Champion (384)

afbeelding van Bengalack

04-12-2020, 20:48

I thought "Highest address" from hex2bin gave the highest address in my program. I found out it is not. At least not when using the IHX-file coming from SDCC.

What comes out from hex2bin is indeed a file of the size 31680 bytes (0x7BC0) - ref. image. There are a bunch of variables at the end of the program (before and after 0x7CB8), these are written to as part of the initializer, and in program use... Sounds like something is wrong / something I did wrong?

The program actually operates "outside" the executable file? Or is this well known behavior?

By the way, the program runs fine :)

Aangemeld of registreer om reacties te plaatsen

Van Bengalack

Champion (384)

afbeelding van Bengalack

05-12-2020, 08:53

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.

Van Giangiacomo Zaffini 2

Master (250)

afbeelding van Giangiacomo Zaffini 2

05-12-2020, 10:04

I think hex2bin has a bug, I have encountered it. Either I will expose it here or send a patched version to You.

Van DamnedAngel

Master (220)

afbeelding van DamnedAngel

05-12-2020, 11:39

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?

Van Bengalack

Champion (384)

afbeelding van Bengalack

05-12-2020, 11:41

Giangiacomo Zaffini 2 wrote:

I think hex2bin has a bug, I have encountered it. Either I will expose it here or send a patched version to You.

Thanks, would be great!

Van Bengalack

Champion (384)

afbeelding van Bengalack

05-12-2020, 12:24

DamnedAngel wrote:

Would you care to share it with me? Is that a a MSX-DOS project(hence 0x100 related stuff)?

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 Smile (?) 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.

Van Giangiacomo Zaffini 2

Master (250)

afbeelding van Giangiacomo Zaffini 2

05-12-2020, 14:21

Hi Bengalack,
try this version of hex2bin for Windows 10.
Link address hex2bin.exe in my oneDrive

left side is original code, right side is modified code

left side is original code, right side is modified code

Van Bengalack

Champion (384)

afbeelding van Bengalack

05-12-2020, 14:45

Giangiacomo Zaffini 2 wrote:

try this version of hex2bin for Windows 10

Thanks. But --it didn't work oO Seems like a small fix you did, but hex2bin filesize is 25kB vs original 47kB Smile 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 Smile

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

Van Giangiacomo Zaffini 2

Master (250)

afbeelding van Giangiacomo Zaffini 2

05-12-2020, 15:00

Bengalak, no problem. We have other cards to play.
HRA! has his version of ihx2bin, I used it with convenience of mine, and You should try this.
Well, for brevity I post a Windows 10 compiled version on oneDrive now just click here.

Van Bengalack

Champion (384)

afbeelding van Bengalack

05-12-2020, 15:16

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

Van Giangiacomo Zaffini 2

Master (250)

afbeelding van Giangiacomo Zaffini 2

05-12-2020, 15:23

Yeah! Running Naked in a Field of Flowers