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.
This was supposed to select the default wrap length, but was actually
returning zero, causing a crash when a project was opened if the
settings file didn't happen to have the value specified.
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.)
The cc65 docs say VICE labels start with '.'. Also, output local
labels prefixed with '@', per ca65 convention. The default output
file is now "labels.lbl".
Added some minimal documentation.
(issue #151)
We currently have two options for assembly code output, selected by
a checkbox in the application settings: always put labels on the same
lines as the instruction or data operand, or split the labels onto
their own line if they were wider than the label text field.
This change adds a third option, which puts labels on their own line
whenever possible. Assemblers don't generally allow this for variable
assignment pseudo-ops like "foo = $1000", but it's accepted for most
other situations. This is a cosmetic change to the output, and will
not affect the generated code.
The old true/false app setting will be disregarded. "Split if too
long" will be used by default.
Added test 20280-label-placement to exercise the "split whenever
allowed" behavior.
The "export" function has a similar option that has not been updated
(for no particular reason other than laziness).
Also, simplified the app settings GetEnum / SetEnum calls, which
can infer the enumerated type from the arguments. This should not
impact behavior.
Some debuggers allow you to import a list of labels for addresses.
This adds a command that generates a file full of labels in a
specific format. Currently the VICE monitor format is supported.
(issue #151)
