5 replies to this topic

[carmel_andrews]

I am trying to find the run/init addresses (using atari800wins+ built in monitor) for various xex/exe and com files i've downloaded from the internet

i know that the locatipons used are 2/3,a-d and 2e0-3

the files i have problems with are mostly those european/polish games that are heavily packed, like robin (hawkeye clone) whoops 2 etc

What seems to happen is that the depacker routines seem to mask out the proper or real run/init addr, or over write it,

I do have a pc util called dissassembler 6502 by erich backer/bacher ( i think) however that program has a limitation of binary files under 256 segments

The other thing is is that it's almost impossible to view the dissassembler listing as the file/segment is packed so you can't see where the program is run/init from plus the fact that the dissassembler program doesn't have a search feature (which would be usefull)

although the dissassembler program does list the 2e0-3 locations, they mostly if not only refer to the run init addresses for the depack routines and not the program itself

Is there a program or utility out there that will unpack these files and put the data/segments back into their proper/actual mem locations

Or do these program's run/init addresses execute in 'high memory' (i.e above bfff) which means that you can't execute/initialise or hack the file out, as you would effectively be executing/initialising o/s routines

[Rybags]

Only DOS binary-load type files use 2E0-2E3.

Once a .XEX file init's once, it can take over the entire load process if it wants (which is what I suspect some demos do anyway). But, most old games (ie pirated from boot -> file) tend to be only single stage binaries.

You can't use the OS and RAM above $C000 at the same time, most software that uses that area will buffer to conventional memory, then move the code there (either in small chunks while loading or all at once).

This is an file/cartridge copy I wrote in BASIC/ASM years ago (ENTER #H:FILECOPY.BAS). It has an option to examine binary files. Only thing is, it only works on files it can fit into memory.

You could do your own binary file lister. The structure is simple:

$FF,$FF - ID bytes, must be at start of file, then optional in segments
start low, start high - start address of segment
end low, end high - end address of segment
<data> - number of bytes is equal to (end - start) +1

Init/Run segments are just 2 or 4 byte segments which get loaded around $2E0. Note that the Init address is only called once, but there may be multiple inits which will then be called. Inits are executed immediately when the segment is read.

The Run address is called at End of File. Only one Run address is valid (ie - the last one found will be used).

Attached Files

•  filecopy.zip   1.91K   48 downloads

[Rybags]

Even better ... just dug up this one:

 binaryex.zip   845bytes   49 downloads

BINARYEX - BASIC/ASM (LIST) file.

This program reads the file with a quick Asm routine. Displays start/end and run/inits. Should work with any filesize.

But back to the original problem - it would be quite hard without looking at an individual program to be able to even work out which type of data compression is in use, let alone work out where it gets depacked to.

There was never an "industry standard" packing method for the 800 (like ZIP became on the PC) in the old days. Even .ARC didn't come into the picture until the 8-bit was almost dead.

One possibility could be to dump sections of memory using the monitor - but then you'd still need to later wrap binary headers around the data - but without a custom loader it would only work for games that ran in <= 48K and could survive a warm boot.

[_Fandal_]

I'm using simple PC utility called binload to analyze structure of A8 binaries.

F.

Attached Files

•  Binload.zip   10.31K   58 downloads

[Heaven/TQA]

i am using xhead from the xasm package...

[carmel_andrews]

Thank peeps... i'll look at these prog's and see if they can shed light on things