- MakeDist now copies CommonWPF.dll.
- Spent a bunch of time tracking down a null-pointer deref that only
happened when you didn't start with a config file. Fixed.
- The NPE was causing the program to exit without any sort of useful
diagnostic, so I added an uncaught exception handler that writes
the crash to a text file in the current directory.
- Added a trace listener definition to App.config that writes log
messages to a file, but it can't generally be enabled at runtime
because you can't write files from inside the sandbox. So it's
there but commented out.
- Made the initial size of the main window a little wider.
The filtering uses the DataGrid View filtering mechanism. The
built-in sorting only operates on a single column, and we really
want a secondary sort on label when the type is used as the key,
so we provide a custom sort method.
SourceGen creates "auto" labels when it finds a reference to an
address that doesn't have a label associated with it. The label for
address $1234 would be "L1234". This change allows the project to
specify alternative label naming conventions, annotating them with
information from the cross-reference data. For example, a subroutine
entry point (i.e. the target of a JSR) would be "S_1234". (The
underscore was added to avoid confusion when an annotation letter
is the same as a hex digit.)
Also, tweaked the way the preferred clipboard line format is stored
in the settings file (was an integer, now an enumeration string).
In the cross-reference table we now indicate whether the reference
source is doing a read, write, read-modify-write, branch, subroutine
call, is just referencing the address, or is part of the data.
This worked, sort of. The problem is that SourceGen will revert to
hex output in certain situations, such as a broken symbolic
reference. There happens to be one in the ZIPPY example, and it's
on a relative branch.
The goal with the segment stuff is to allow cc65 to treat the
source as relocatable code. In that context, a relative branch to
an absolute address doesn't make any sense, so the assembler reports
a range error.
We don't currently have a mechanism that guarantees no references
are broken (and no affordance for finding them), so we can't make
this mode the default yet.
Instead, we continue to use the generic config, but generate the
correct set of lines as comments.
(issue #39)
The system configuration you get with "-t none" works for smaller
files but fails for larger ones. This updates the generator to
produce a source file and linker script pair. (I kinda saw this
one coming -- it's why the gen/asm dialog has a combo box for the
file preview -- so it didn't require that much work.)
This currently generates a fixed script for a generic system with
64KiB of RAM, using .ORGs to set the addresses as before.
With this change, assembling a file with 65536 NOPs succeeds.
(issue #39)
In the data operand edit section, walk through selecting a single
byte vs. multiple bytes when you want to set a multi-byte format.
(inspired by issue #41)
If you double-click on the opcode of "JSR label", the code view
selection jumps to the label. This now works for partial operands,
e.g. "LDA #<label".
Some changes to the find-label-offset code affected the cc65 "is it
a forward reference to a direct-page label" logic. The regression
test now correctly identifies an instruction that refers to itself
as not being a forward reference.
The cc65 assembler runs in a single pass, which means forward
address references default to 16 bits. For zero-page references
we have to add an explicit width disambiguator. (This is an
unusual situation that only occurs if you have a zero-page .ORG
in the file after code that references it.)
With this change, 2014-label-dp passes, and no other regression
tests were affected.
(issue #40)
The 2014-label-dp test now passes. Prior regression tests are
unaffected.
Also, renamed an IGenerator interface to more accurately reflect
its role.
(issue #37)
This is primarily to exercise a Merlin 32 failure (issue #37).
However, it also exercises a problem with cc65 (issue #40).
Currently, only 64tass can assemble this project.
Change 80da6c replaced \u23e9 (black right-pointing double triangle)
with a downward-pointing triangle, because it didn't render under
Win7 or Linux. It was also being used in the "info" window. This
change replaces that occurrence with a right-pointing triangle.
To avoid confusing the assembler, expressions with a leading
parenthesis like "(foo & $ffff) + 1" are prefixed with a "0+". This
is not necessary if the operand begins with a '#'.
(issue #16)
This adds a null check on the dfd argument in FormatDataOp() to see
if we can prevent a crash. The opcode/operand are presented as
"!FAILED!" to make it obvious to the user that something has gone
wrong. Hopefully this will allow capture of a project that exhibits
the problem.
Before you could choose between Merlin-style and generic. Now
there's a combo box that lets you choose Merlin, cc65, or
"common", the latter being used for 64tass.
We now insert parenthesis as needed. This can cause problems in
some situations, so we always prefix parenthetical expressions with
"0+", which looks goofy and is unnecessary for immediate operands.
But it does generate working source code.
Renamed the "simple" expression mode to "common", as it's not
particularly simple but is what you'd expect most assemblers to do.
(OTOH, life has been full of surprises.)
(issue #16)
Gave cc65 its own expression generator, as the precedence table seems
atypical if not unique. Configured 64tass to use the "simple"
expression mode.
Added some operations on a 32-bit constant to 2007-labels-and-symbols
to exercise the current worst-case expression (shift + AND + add).
Tweaked the Merlin expression generator to handle it.
(issue #16)
Correctly handle pre-existing underscores and avoidance of
"reserved" labels.
Also, add more underscores to 2012-label-localizer to exercise
the code.
(issue #16)
Most tests pass, but 2007-labels-and-symbols fails because the
expressions recognized by 64tass don't match up with either of the
other assemblers.
This is currently using a workaround for the local label syntax.
64tass uses '_' as the prefix, which is unfortunate since SourceGen
explicitly allowed underscores in labels. (So does 64tass for that
matter, but it treats labels specially when the '_' comes first.)
We will need to rename any non-local user labels that start with '_'.
(issue #16)
We were using \u23e9, BLACK RIGHT-POINTING DOUBLE TRIANGLE, but
neither Win7 SP1 nor Linux was able to display the glyph. It also
gets all puffy in web browsers. We now use \u25bc, BLACK
DOWN-POINTING TRIANGLE, which seems to work everywhere. It also
feels more appropriate, because it appears next to the "containing"
opcode, with the embedded instruction appearing on the following
line.
Changed the "quick config" buttons for the asm config and pseudo-op
tabs into a drop-list and "set" button. The default values for
each assembler are now defined in the Asm*.cs file, rather than in
the settings code.
Rather than have each assembler get its own app config string for
the cross-assembler executable, we now have a collection of per-
assembler config items, of which the executable path name is one
member. The Asm Config tab has an auto-generated pop-up to select
the assembler.
The per-assembler settings block is serialized with the rather
unpleasant JSON-in-JSON approach, but nobody should have to look
at it.
This also adds assembler-specific column widths to the settings
dialog, though they aren't actually used yet.
Each supported assembler has an IGenerator interface and an
IAssembler interface. They're still two separate classes, but now
both are implemented in the same source file. (They'll probably
stay separate classes, since the two have little interaction.)
I'm keeping the "Asm*" filename. Seems the more natural fit.
Also, changed AssemblerInfo to try to get all assembler-specific
stuff into a single table.
Most of the decorative items associated with a file offset are
placed before the item in the display list, and given a span of
zero. This yields the correct behavior in a binary search: an
exact match finds the decorative item (e.g. a blank line), while a
match partway into the instruction or multi-byte data item causes
the binary search to move on to the next line, where it's resolved.
The problem is that we were adding a blank line *after* instructions
in the no-continue case. If the binary search found the blank line
before it found the instruction, it would guess "too high" rather
than "too low", and miss the actual instruction line.
We now set a flag and add the blank line as part of the following
item. We do a little dance at the start to ensure that the blank
line doesn't disappear during a partial update.
There's a common convention for using one of the thumb buttons on
the side of the mouse to mean "back", notably in web browsers. I
keep hitting it without thinking about it, so let's just make it
official.
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.
Updated the RuntimeData directory finder to work, and made the
stuff that crashed when the directory wasn't found crash in less
obvious ways. Under Mono+Linux it still falls over with some
complaints about ListViews. This will need some work.
The code that tries to make the last column of the Symbols and
References windows exactly fit the window goes into an infinite
loop for everybody except me. I'm removing the feature for now.
