Skip to content

Commit

Permalink
Various doc fixes
Browse files Browse the repository at this point in the history
  • Loading branch information
fadden committed Jul 29, 2019
1 parent 330b4a2 commit 4aee3af
Show file tree
Hide file tree
Showing 3 changed files with 33 additions and 25 deletions.
41 changes: 24 additions & 17 deletions SourceGen/RuntimeData/Help/analysis.html
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,11 @@
<h1>6502bench SourceGen: Instruction and Data Analysis</h1>
<p><a href="index.html">Back to index</a></p>

<p><i>This section discusses the internal workings of SourceGen. It is
not necessary to understand this to use the program.</i></p>

<h2><a name="analysis-process">Analysis Process</a></h2>

<p>Analysis of the file data is a complex multi-step process. Some
changes to the project, such as adding a code entry point hint or
changing the CPU selection, require a full re-analysis of instructions
Expand Down Expand Up @@ -42,16 +46,16 @@ <h2><a name="analysis-process">Analysis Process</a></h2>
attributes, or "anattribs", with one entry per byte in the file.
The Anattrib array tracks most of the state from here on. If we're
doing a partial re-analysis, this step will just clone a copy of the
Anattrib array that was made at this point in a previous run. (This
step is described in more detail below.)</li>
Anattrib array that was made at this point in a previous run. (The
code analysis pass is described in more detail below.)</li>
<li>Apply user-specified labels to Anattribs.</li>
<li>Apply user-specified format descriptors. These are the instruction
and data operand formats.</li>
<li>Run the data analyzer. This looks for patterns in uncategorized
data, and connects instruction and data operands to target offsets.
The "nearby label" stuff is handled here. All of the results are
stored in the Anattribs array. (This step is described in more
detail below.)</li>
stored in the Anattribs array. (The data analysis pass is described in
more detail below.)</li>
<li>Remove hidden labels from the symbol table. These are user-specified
labels that have been placed on offsets that are in the middle of an
instruction or multi-byte data item. They can't be referenced, so we
Expand Down Expand Up @@ -105,12 +109,12 @@ <h3><a name="auto-format">Automatic Formatting</a></h3>
L1003 NOP
</pre>

<p>We haven't formatted anything yet. The data analyzer sees that the
JMP operand is inside the file, and has no label, so it creates an
<p>We haven't explicitly formatted anything yet. The data analyzer sees
that the JMP operand is inside the file, and has no label, so it creates an
auto-label at offset +000003 and a format descriptor with a symbolic
operand reference to "L1003" at +000000.</p>
<p>Now we edit the label, changing L1003 to "FOO". This goes into the
project's "user label" list. The analyzer is
<p>Suppose we now edit the label, changing L1003 to "FOO". This goes into
the project's "user label" list. The analyzer is
run, and applies the new "user label" to the Anattrib array. The
data analyzer finds the numeric reference in the JMP operand, and finds
a label at the target address, so it creates a symbolic operand reference
Expand All @@ -119,8 +123,9 @@ <h3><a name="auto-format">Automatic Formatting</a></h3>
<p>Even though the JMP operand changed from "L1003" to "FOO", the only
change actually written to the project file is the label edit. The
contents of the Anattrib array are disposable, so it can be used to
add labels and "fix up" numeric references. Generated labels and
format descriptors are never added to the project file.</p>
hold auto-generated labels and "fix up" numeric references. Labels and
format descriptors generated by SourceGen are never added to the
project file.</p>

<p>If the JMP operand were edited, a format descriptor would be added
to the user-specified descriptor list. During the analysis pass it would
Expand Down Expand Up @@ -167,9 +172,10 @@ <h3><a name="undo-redo">Interaction With Undo/Redo</a></h3>

<p>Each entry in the change set has "before" and "after" states for the
format descriptor at a specific offset. Only the state for the affected
offsets is included -- the program doesn't take a complete state snapshot
(even with the RAM on a modern system that would add up quickly). When
undoing a change, before and after are simply reversed.</p>
offsets is included -- the program doesn't record the state of the full
project after each change (even with the RAM on a modern system that would
add up quickly). When undoing a change, before and after are simply
reversed.</p>


<h2><a name="code-analysis">Code Analysis</a></h2>
Expand Down Expand Up @@ -222,9 +228,9 @@ <h2><a name="code-analysis">Code Analysis</a></h2>

<p>There are three ways in which code can set a flag to a definite value:</p>
<ol>
<li>By explicit instructions, like <code>SEC</code> or
<li>With explicit instructions, like <code>SEC</code> or
<code>CLD</code>.</li>
<li>By immediate-operand instructions. <code>LDA #$00</code> sets Z=1
<li>With immediate-operand instructions. <code>LDA #$00</code> sets Z=1
and N=0. <code>ORA #$80</code> sets Z=0 and N=1.</li>
<li>By inference. For example, if we see a <code>BCC</code> instruction,
we know that the carry will be clear at the branch target address, and
Expand Down Expand Up @@ -274,8 +280,9 @@ <h3><a name="extension-scripts">Extension Scripts</a></h3>
are offered a chance to act.</p>

<p>The first script that applies a format wins. Attempts to re-format
instructions or data will fail. This rule ensure that anything explicitly
formatted by the user will not be overridden by a script.</p>
instructions or data that has already been formatted will fail. This rule
ensures that anything explicitly formatted by the user will not be
overridden by a script.</p>

<p>If code jumps into a region that is marked as inline data, the
branch will be ignored. If an extension script tries to flag bytes
Expand Down
15 changes: 8 additions & 7 deletions SourceGen/RuntimeData/Help/intro.html
Original file line number Diff line number Diff line change
Expand Up @@ -82,8 +82,8 @@ <h2><a name="begin">About 6502 Code</a></h2>
standard set of conventions. However, most programmers will use
subroutines, which can be identified and analyzed in isolation. Subroutines
are often interspersed with variable storage, referred to as a "stash".
Variables may be single-byte or multi-byte, the latter typically
in little-endian byte order.</p>
Variables and constants may be single-byte or multi-byte, the latter
typically in little-endian byte order.</p>

<p>Much of the data in a typical program is read-only, often in the
form of graphics or ASCII string data. Graphics can be difficult
Expand All @@ -100,14 +100,15 @@ <h2><a name="begin">About 6502 Code</a></h2>
the last byte of the data area appears to be a three-byte instruction,
the first two bytes of the next instruction area will be gobbled up.</p>

<p>Some programmers will use a trick where they "embed" an instruction
<p>To make things even more difficult (sometimes deliberately), programmers
will sometimes use a trick where they "embed" an instruction
inside another instruction. This allows code to branch to two different
entry points, one of which will set a flag or load a register, and then
continue on to common code.</p>

<p>Another trick is to embed "inline data" after a JSR or JSL instruction.
The caller pulls the calling address off the stack, uses it to access
the parameters, then pushes the address back on after modifying it to
The called subroutine pulls the caller's address off the stack, uses it to
access the parameters, then pushes the address back on after modifying it to
point to an address past the inline data. This can be very confusing
for the disassembler, which will try to interpret the inline data as
instructions.</p>
Expand Down Expand Up @@ -293,7 +294,7 @@ <h3><a name="hints">Analyzer Hints</a></h3>

<p>The three bytes following the <code>JSR $bf00</code> should be hinted
as inline data, so that the code analyzer skips them and continues the
analysis at the <code>BCS</code>. Because you need to hint *every* byte
analysis at the <code>BCS</code>. Because you need to hint <i>every</i> byte
of inline data, all bytes in a selected line will receive hints.</p>
<p>If code branches into a region that is marked as inline data, the
branch will be ignored.</p>
Expand Down Expand Up @@ -660,7 +661,7 @@ <h2><a name="width-disambiguation">Width Disambiguation</a></h2>
way. Some use opcode suffixes, others use operand prefixes, some
allow both. You can configure how they appear in the
<a href="settings.html#app-settings">application settings</a>.</p>
<p>SourcGen will only add width disambiguators to opcodes or operands when
<p>SourceGen will only add width disambiguators to opcodes or operands when
they are needed, with one exception: the opcode suffix for long
(24-bit address) operations is always applied. This is done because some
assemblers require it, insisting on "LDAL" rather than "LDA" for an
Expand Down
2 changes: 1 addition & 1 deletion SourceGen/WpfGui/AboutBox.xaml
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ limitations under the License.
<TextBlock FontSize="24"
Text="{Binding ProgramVersionString, StringFormat={}Version {0},
FallbackValue=Version X.Y.Z-alpha1}"/>
<TextBlock Text="Copyright 2018 faddenSoft" Margin="0,30,0,0"/>
<TextBlock Text="Copyright 2019 faddenSoft" Margin="0,30,0,0"/>
<TextBlock Text="Created by Andy McFadden"/>
</StackPanel>

Expand Down

0 comments on commit 4aee3af

Please sign in to comment.