aboutsummaryrefslogtreecommitdiff
path: root/xexamine.rst
blob: ea28feb7cf4b383b056c098d1ffb1f6c4ed873d6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
.. RST source for xexamine(1) man page. Convert with:
..   rst2man.py xexamine.rst > xexamine.1

========
xexamine
========

-------------------------------------------------
Show information on Atari 8-bit executables (XEX)
-------------------------------------------------

.. include:: manhdr.rst

SYNOPSIS
========

xexamine [ [**-h**] | [ [**-v**] [**-d**] [**-s** *segment*]  *xexfile* ... ]

DESCRIPTION
===========

**xexamine** reads Atari 8-bit executables (.xex files) and prints
the following information on each segment in each file:

Segment number within the file (in decimal, first segment is #1).

Offset in bytes from the start of the file (in decimal).

Start and end addresses (in hex by default).

Length in bytes (in decimal).

CRC32 checksum of the segment's data (in hex).

Segment type:

  If the segment is a run address (loads at RUNAD) or an init address (loads at INITAD), the
  type is "Run" or "Init", with the actual run or init address, in hex by default.

  Otherwise, the percentage of the segment that contains valid 6502 object
  code is printed. This is an estimate based on static analysis and some
  heuristics, and as such, isn't 100% accurate.

OPTIONS
=======

.. TODO:
.. -l
..    List code. Disassemble with da65?

-d
   Show addresses in decimal.

-s *segment-number*
   Only show information on one segment. Segments are numbered starting
   at one.

-h
   Print a short help message and exit.

-v
   Verbose operation.

NOTES
=====

Currently, **xexamine** only works with .xex files. If you have a
cartridge image as a .car file, you can use **xex2cart** to make a
.xex from it (if it's a non-bankswitched cart, anyway). If you have
a raw chunk of object code, you can use **blob2xex** to make a .xex file
from it.

The code-detection could be smarter, and probably will be pretty soon.
Static analysis will never be 100% perfect, but the heuristics could
be improved (e.g. by using something like Markov chain or Bayesian
analysis).

The CRC32 sum is handy for comparing different releases of the same
program. Example would be a game that was cracked more than once
by different cracking groups, and each crack has a different title
screen. Often, the 2nd or some further segment contains the actual
code/data, and is identical.

EXIT STATUS
===========

Exit status is zero if *xexfile* is a valid Atari .xex file, non-zero otherwise.

.. include:: manftr.rst