When you edit the operand of an instruction that targets an in-file
address, you're given the opportunity to specify a shortcut that
applies the symbol to the instruction's target address in addition
to or instead of defining a weak symbol reference on the instruction
being edited.
This didn't work right for operands with adjustments, e.g. the store
instructions in self-modifying code. It put the label at the
unadjusted offset, which does nothing useful.
We now correctly back up to the start of the instruction or multi-
byte data area.
Change acf19870 fixed one bug but introduced another: the call to
update the highlight happened before the selection was restored, so
it could potentially refer to a line that no longer existed.
Worked around two crashes in Mono 5.16's WinForms implementation.
(See mono/mono#11070 for the details.)
Still very unstable, but it no longer crashes on startup.
Also, tweaked the "about" box title.
There are some useful interactions between C/N and maybe Z. Added
a quick test to 1003-flags-and-branches.
Also, updated the 2008-address-changes tests. Change b37d3dba
extended the nearby-target range of out-of-file symbols by one, so
one line that didn't get an operand label now does.
Once upon a time, symbol files and extension scripts could only be
defined in the RuntimeData directory, so having the documentation
there made sense. Since both of these things can now be defined in
project directories, the documentation belongs in the manual.
(issue #27)
If PTR is defined as an external symbol, we were automatically
symbol-ifying PTR+1. Now we also symbolify PTR+2. This helps with
24-bit pointers on the 65816, and 16-bit "jump vectors", where the
address is preceded by a JMP opcode.
Removed the "AMPERV_" symbol I added to make the tutorial look
right.
The instruction operand editor and data operand editor are very
different, but there's no need to impose that distinction on the
user. They want to edit the operand either way. We now provide a
single "edit operand" menu item, and open the appropriate dialog
based on what they have selected.
This uses Ctrl+O as the keyboard shortcut, stealing it from
File > Open.
(issue #11)
Two changes:
(1) Code and data hints are now only applied to the first byte on
each selected line. This allows you to slap a code hint on a
string without lighting up the whole string. Inline-data hints
and hint removal work as before.
(2) Added a menu item (with Ctrl+D as shortcut) to toggle the state
of the uncategorized data analyzer. This makes it easy to turn
off the feature that put the code into a string in the first
place.
Every once in a while, SourceGen will become unresponsive when it
tries to show a MessageBox. In the debugger you can see the GC
running frantically, but the stack trace is just sitting on the
MessageBox show call. Apparently, if you don't specify a parent
window argument, the MessageBox will occasionally end up behind
everything else, and you can get stuck.
I'm not sure what the GC frenzy is about, or whether this will fix
what I'm seeing, but it's easy to do and might solve the problem.
cf. https://stackoverflow.com/q/3467403/294248
Don't enable OK unless at least one address is valid.
Don't apply code hints unless asked.
Rename a couple of things for clarity.
Add documentation to manual.
(issue #10)
Allows specification of table data in various ways, for 16-bit and
24-bit addresses. Shows a preview so you can see if the addresses
look about right. Adds permanent labels at target offsets if none
are present. Optionally sets code hints.
Works beautifully on the A2-Amper-fdraw example, but needs some
additional testing, documentation, etc. Dialog is more complicated
that I would have liked, mostly because of 65816 support, but I
think it'll do.
(issue #10)
If we set the length word to assemble at address zero, the rest of
the code will try to use it as a zero-page label, so don't do that.
Instead, we use the start address, creating an overlapping region.
Easy enough to edit if that's undesirable.
(issue #23)
First is always at zero, second is at the address. This puts an
ORG directive right at the start of the code, and avoids potentially
assembler-specific wrap-around behavior when the desired load
address is $0000 or $0001.
(issue #23)
If set, the first word of the file is used to set the load address.
The initial code entry hint is placed at offset +000002 instead of
the start of the file.
Set it to true for the C64 system definition.
(issue #23)
These *almost* match what cc65 has, and are accepted as primary or
aliases by 64tass.
This combines the LAX and LXA operations. LXA is the immediate
form of LAX, and behaves somewhat differently (and is unstable).
I was treating them as two separate operations with independent
mnemonics, but that doesn't seem to be the preferred way to
handle it.
The cc65 generator wasn't generating LAX before; now it does. This
required nudging the width disambiguator, as LAX is a second
example of an instruction with both DP,Y and ABS,Y operands.
(issue #20)
It's possible to have format descriptors on instructions that are
left over from when the bytes were treated as data. Single-byte
formats were being allowed on single-byte instructions, which
confused things later when the code tried to apply the format to
an instruction with no operand.
The Symbols window showed Type-Name-Value, which feels like the
natural order. However, the Value field has a narrow max width,
while the Name field can get pretty long. It makes more sense to
let Name fill out to the right edge, allowing the user to scroll
horizontally to view longer-than-usual names.
Also, noticed that the column sort preference wasn't being
restored. Fixed that.
(Issue #12)
We were generating code for > 2.17, with various bug fixes, but
since that's not shipping yet it won't be usable by anybody who
doesn't have a tip-of-tree cc65 installation.
If the main window was maximized before, maximize it when we
restart.
Changed the preferences to record the width of the right panels,
rather than the splitter distance, which is actually the width of
the middle of the screen.
Seems to work correctly on my non-uniform multi-monitor setup. I
added a check to confirm that the middle of the title bar falls in
the working area of the screen that WinForms thinks we're in, so it
shouldn't be possible to "lose" a window off the edge by dragging
it or by changing screen resolutions.
