This uses the same (very weak) string search as the current Find
feature, but does it over the entire file. Matches are added to a
table of results and displayed in the same dialog used by the
References panel "copy out" feature.
The reference table now jumps to a Location rather than just the
closest offset, so that we can jump to the middle of a multi-line
comment.
It's annoying to have to go digging for the dialog. The default
setting is "true", and the value is remembered for the duration of
the current session.
If an instruction or data operand has been given an explicit symbol,
the user will expect to edit the label at that address rather than
the numeric address. Same for project symbols. If we detect that
a symbol has been set, edit that directly. If the symbol doesn't
exist, or isn't a user label or project symbol (e.g. platform symbol
or address region pre-label), we open the full operand editor instead.
The "edit operand target label" feature now handles local variables.
The individual symbol is edited in the table, the same way it would
if the appropriate option were selected from the Edit Instruction
Operand dialog.
Also, show the address in the Edit Label dialog. It feels
unobtrusive and is occasionally useful.
The References window is handy for seeing everything that refers to
a particular address or symbol, but walking through the list is
annoying because the window gets reset every time you double-click
on an entry and the selection moves.
This adds a "copy out" button that copies the references to a
floating window. References can be double-clicked as usual, but the
list doesn't update unless you click "copy out" again.
This might be better if it were somehow integrated into the main
window, e.g. as a tab in the Info panel, so that the focus isn't
bouncing between two independently Z-ordered windows.
This adds a shortcut for editing the label at the address referenced
by an instruction operand or data address pseudo-op. This can be
activated from the Actions menu, or with Ctrl+Shift+L.
For references inside the file, the Edit Label dialog is opened. For
external addresses, the project symbol editor is opened.
Local variable table entries are currently not supported.
(issue #166)
The code that allowed easy editing of project symbol operands wasn't
handling overlapping multi-byte regions correctly.
This adds a new section to the 20200-ui-edge-cases test case that has
instructions with various kinds of address operands.
Merlin32 v1.2 requires DSK and TYP directives. We now add these if
version 1.2 is detected. (Earlier versions of Merlin32 accept them,
so at some point we may just want to output them always.)
The version-parsing code has been updated to deal with pre-release
version strings.
By default, implicit acc operands are shown, e.g. "LSR A" rather
than just "LSR". I like showing operands for instructions that
have multiple address modes.
Not everyone agrees, so now it's a setting. They're shown by default,
but enabling the option will strip them on-screen, in generated
assembly, and in the instruction chart.
They are always omitted for ACME output, which doesn't allow them.
(issue #162)
Two main changes:
- "Seek nearby targets" is no longer enabled by default.
- The application asks the user to save new projects immediately.
Various minor edits were also made.
A couple of the images are slightly stale, showing ".org" rather than
".addrs", but they're in the advanced section and the difference
isn't notable.
When creating a new project, we now put up a "save as" dialog. If
you cancel out of the dialog, and have auto-save enabled, we post a
strange message about being unable to create a file with an empty
filename string.
Added the recovery file check when a project is opened, and the GUI
elements for choosing which file to use.
If a recovery file exists but can't be opened, presumably because it's
open by another process, offer to open the project read-only. (This
is a generally good idea, but we don't hold the project file open
in normal usage, so it only works when auto-save is enabled.)
After making a choice, auto-save is disabled until the first manual
save.
One thing we don't do: if we find a recovery file, but auto-save is
disabled, the recovery file won't be deleted after the user makes a
choice. This might be a feature.
Updated documentation.
(issue #161)
Periodically save the project to the recovery file if changes have
been made and the project is "dirty".
We need to handle a couple of things specially. If the user uses
"Save As" to change the project name, we need to recreate the recovery
file as well. If auto-save is enabled or disabled in app settings, we
need to create or discard the recovery file, and possibly change the
timer interval. If the project is modified, auto-saved, and then the
change is un-done, the project won't be dirty, but will have a stale
recovery file with a newer modification date; we handle this by simply
truncating the stale recovery file.
To reduce the amount of auto-saving, we don't do an initial write to
the recovery file, and we reset the timer every time the user does a
manual save. A user who saves diligently will always have an empty
recovery file.
Added configuration option to app settings. It's in the "code view"
tab, which isn't quite right, but none of the others fit better.
Also, force a Save As when a new project is first created.
The pop-up that lets you choose which assembler to set configuration
options for looked like it let you choose an assembler generally.
Changed some wording and visuals for better clarity.
It's really handy for certain types of programs, but it's a
distraction in many others. I find myself turning it off for most
things.
Some changes will be needed in the tutorial, which makes use of
the feature. (The "odds & ends" section discusses it in detail.)
I'm putting that off until other changes are in.
The address table formatter tries to map the calculated addresses
to offsets within the file. When that fails, it currently just
gives up.
We now try to resolve external addresses to project/platform symbols.
(issue #160)
Added a "format help" button to the long comment edit window. This
brings up a quick summary of the format tags in a modal dialog.
Updated documentation and tutorial.
Started implementing the fancy formatter. It currently doesn't do
anything fancy, just word-wrapping.
Moved the static DebugShowRuler field into Formatter, so that the
cached data is discarded when the setting changes.
Also, updated SourceNotes with instructions for publishing a release.
Added a "fancy" flag to MultiLineComment. If set, we will use
formatting commands embedded in the text itself. The max width pop-up
and "boxed" flag will be ignored in favor of width and boxing
directives. (See issue #111.)
The current "fancy" formatter is just a placeholder that folds lines
every 10 characters.
Removed FormattedMlcCache (added two changes back). Caching the
rendered string list in the MLC itself is simpler and more efficient
than having a separate cache, and it works for Notes as well.
Added anchors for more comments in the 20090 test.
This was used to prefix boxed lines with a comment delimiter, but
in practice we just need to do this whenever the box character
doesn't match the full-line comment delimiter.
This has no effect on generated assembly output, but the on-screen
(and exported HTML) form will now reflect the current settings.
Multi-line comments (MLCs) can span multiple lines, and are formatted
with word-wrapping. This isn't too expensive now, but languages
with immutable strings aren't ideal for this sort of thing. Before
we introduce fancier formatting, we want to ensure that we're not
going to adversely affect rendering performance.
The cache entry for a given offset is tied to the MLC object and the
Formatter; if either are changed, the cached string list will not be
used.
While it's okay to use ';', the classic Merlin editor will treat it
as an end-of-line comment and shove the entire thing off to the right
side of the screen.
This adds a configuration item to the app settings, with a default
value of ';'.
It was defined as a struct with exposed fields. Now it's a class
with simple properties. Default values are set explicitly, and
the contents are copied with a copy constructor instead of using
the struct member assignment.
The only functional change should be that the DelimiterSet members
are now properly cloned. The bulk of the changes are just refactoring
renames for the property names.
This also adds comments for all the properties.
This adds a new data format option, "binary include", that takes a
filename operand. When assembly sources are generated, the section
of file is replaced with an appropriate pseudo-op, and binary files
are generated that hold the file contents. This is a convenient way
to remove large binary blobs, such as music or sound samples, that
aren't useful to have in text form in the sources.
Partial pathnames are allowed, so you can output a sound blob to
"sounds/blather.bin". For safety reasons, we don't allow the files
to be created above the project directory, and existing files will
only be overwritten if they have a matching length (so you don't
accidentally stomp on your project file).
The files are not currently shown in the GenAsm dialog, which lets
you see a preview of the generated sources. The hex dump tool
can do this for the (presumably rare) situations where it's useful.
A new regression test, 20300-binary-include, has been added. The
pseudo-op name can be overridden on-screen in the settings.
We don't currently do anything new for text/HTML exports. It might
be useful to generate an optional appendix with a hex dump of the
excised sections.
(issue #144)
Note that address region isolation doesn't prevent explicit label
references from working (add update the test to prove it).
Added a note about pre-label xrefs.
If an address resolves to a user label in an isolated region, we
don't want to use it. However, we still want to try to match it
to a project/platform symbol.
For example, suppose the isolated code wants to reference address
$1C00, which is a memory-mapped I/O location in one area, but a
regular bunch of code in the other. We don't want it to map to
the regular code, but we do want it to resolve to our table of
platform I/O addresses.
We now handle this correctly. The regression test has been updated
to check this. The current implementation does a linear scan through
the symbol table, but I'm hoping this is not a common situation.
The reference manual has been updated to describe the new feature.
Added an address-to-offset test in the GeneratePlatformSymbolRefs()
method, which sets the operand symbols for anything that lands outside
the scope of the file. Because the region isolation code prevented
symbols from being associated with the operands in the initial code
scan, those operands were being examined here. Without the additional
test, the inappropriate label associations were getting a second chance.
Added "[!in]" and "[!out]" to the comment field of .addrs lines. This
is only for the on-screen display and text exports, not asm gen.
Bumped the project file CONTENT_VERSION.
Added a regression test (20290-region-isolation).
The test turned up an existing problem: pre-labels are emitted by the
asm generators on their own line, but the code that puts excessively
long labels on a separate line wasn't taking that into account. This
has been fixed. No changes to existing regression tests, which didn't
happen to use long labels.
This adds a pair of flags to address regions that control how
address resolution is performed.
Generally, when we're trying to convert an address to a file offset,
we do a depth-first search through the hierarchy of address regions
to find a match. For certain situations, such as multi-bank ROMs or
when code is executed in a separate subsystem, we don't want the
address resolver to specify an offset for something that's in a
different address space.
The search for a matching address starts from the region where the
address is referenced. The flags will prevent the search from
progressing "outward" (to parent or sibling regions) or "inward"
(from parent or sibling regions). Setting both flags effectively
makes the region an island.
Descending farther into the tree is not restricted by the "outward"
flag, i.e. addresses will still be found in child regions (assuming
they don't have the "disallow inward" flag set).
(issue #139)
The build flag causes the application to run as a 32-bit app on 64-bit
systems, which we don't want. We're still using "Any CPU" as the
platform target, so it will continue to work on 32-bit x86 systems;
we just no longer force it to always be 32-bit.
This only affects the main .NET Framework application executable.
The setting is not relevant for the libraries.
(Note to future self: the way things work changed with .NET Core,
which requires different executables for different targets, specified
with the RID. The older .NET Framework is Windows-only, which makes
it easier to have a single multi-target EXE.)
