Created the 20180-extension-scripts test by cutting out the handful
of 65816-specific items from 20182. Removed some issue-specific stuff
from 20182 that didn't need to be duplicated. Renamed some stale
references to test 2022.
We were showing (relevant) [irrelevant] cycle mods in the Notes panel,
but unless you're working with a 65816 you probably don't care about
things affected by the M/X flags and D register.
Also, made the rightmost column of the Notes and Symbols panels
auto-sized to fill the window. We have to do this in the code because
we're constantly saving/restoring the column widths so that we can
record the values in the app setttings file.
The project was targeting 4.6.2, which was the current version when
work first began. This update should not cause any change in behavior.
The only real value in doing this is that it means people working on
the project won't have to install the older SDK components.
This may require performing a manual "clobber" in existing source trees:
close Visual Studio, then in each of the seven projects, manually
remove the "bin" and "obj" directories. Using the VS "clean" feature
doesn't seem to clear out all of the dependencies, and you get weird
build complaints about missing System classes.
I'm not anticipating any compatibility issues with this switch.
Framework 4.8 shipped in April 2019, and the final version of .NET
Framework was released August 2022, so anybody who has Framework
installed should have a compatible version.
This change does not move the libraries from .NET Standard 2.0 to 2.1,
because 2.0 was the last version supported by Framework.
(At some point it might be useful to upgrade to the current .NET, but
that is a more significant change.)
We generate operand adjustments automatically, and output small
values as decimal (e.g. LDA FOO-1) and large values as hex (e.g.
LDA FOO+$1000). This change adds a setting for the threshold
between small and large.
The default setting is 8. The previous threshold was 255, which
felt a bit high.
(issue #176)
Fix some typos, clarify some things, and replace a slightly incorrect
pair of PNGs.
Some of the dialogs have gained additional options, but the changes
aren't meaningful enough to warrant taking lots of screen shots.
Added assembler regression tests, for 6502 and 65816.
The "remove formatting" action now clears the flag. It's a bit of a
stretch to call it "formatting" but this feels right.
Updated the documentation, adding a new section about embedded
instructions to the intro material.
SourceGen puts a lot of effort into connecting address operands to
internal offsets and external symbols. Sometimes this is undesirable.
For example, a BIT or conditional branch instruction is sometimes used
as a dummy when there are multiple entry points that vary only in a
status flag or register value. The address in the BIT or branch is
either irrelevant or never actually referenced, so auto-generating a
label for it is annoying.
Having a way to tell the disassembler to disregard an address operand,
so that it won't generate an auto-label or be included in the list of
cross-references, provides a simple solution to this.
The operand's file offset is determined during the code analysis
pass. Setting it to -1 makes the operand look like an external address.
If we disable the project/platform symbol lookup for that instruction
as well, we can avoid label generation and cross-references.
We also need to prevent the 65816 data bank fixup code from restoring
it, and the relocation data code from doing its thing.
The flag is implemented as a new "misc flags" table, which holds a
set of bit flags for every file offset. The "disregard operand address"
flag is set on the opcode byte of instructions. The flags are expected
to be used infrequently, so they're currently output as a list of
(offset, integer) pairs.
The flag is set in the Edit Instruction Operand dialog, which has a
new checkbox. The checkbox is disabled for immediate operands.
(issue #174)
Some 16-bit operands are tracked internally as 24-bit, appending the
B (data bank) or K (program bank) register to form the full address.
For some assemblers the K-bank instructions must be output as 24-bit
values, even for 16-bit JMP/JSR, but for most we want to strip the
bank byte off before outputting the operand as hex or decimal.
This expands 20032-labels-and-symbols with a mix of 24-bit, 16-bit+B,
and 16-bit+K instructions formatted in various ways. No existing
tests were affected by this change.
(issue #172)
We were treating PEA's operand as an absolute address and attempting to
extend it to 24 bits. This wasn't very successful, and was
counter-productive when the argument was actually a constant, which is
common. Worse, if the operand appeared to reference an internal address
outside bank 0, we would output a 24-bit value, breaking 64tass and cc65.
We now treat PEA as having an immediate operand. (It was already
classified as an "extended immediate", but the operand-address
computation was still happening.)
This will have little to no effect on projects that use OMF relocation
data, because PEA arguments are explicitly identified as symbols or
constants.
New tests were added to 20032-labels-and-symbols to exercise the code
generation failures. A few other tests that used PEA were affected.
20152-local-variables was fixed by adding a symbolic reference, the
others remained as-is and the expected output was revised.
(issue #172)
It was re-using Alt+D in the instruction operand editor, which
interfered with selection of Decimal. Alt+S was taken (for Symbol),
so it's using Alt+G.
There was no assignment in the data operand editor. Alt+G was free
there as well.
These are actually 24-bit address tables, with an extra byte to pad
each entry to an even number of bytes, so the GUI refers to them as
"24-bit + pad byte". The extra byte is not included in the address
calculation, and is simply skipped over.
(issue #171)
This allows signed decimal operands to be formatted as such, e.g.
"LDA #$FE" becomes "LDA #-2". This can be applied to immediate
operands and to numeric data pseudo-ops.
Not all assemblers support this in all situations. The asm generators
will output unsigned decimal operands if so.
The 20020- and 20022-operand-formats tests have been updated.
When asked to tag an absolute JMP instruction ($4C) as code, we now
scan forward to see if it's the start of a series of JMPs. If we
find more than one, we offer the opportunity to tag the entire set
all at once.
A series of unformatted JMPs has been added to 20200-ui-edge-cases
for manual testing.
(issue #22)
The existing workaround for broken Merlin 32 behavior is sufficient
to handle the new test cases. This updates 20032-labels-and-symbols
to fully exercise all DP addressing modes with non-DP labels.
(issue #170)
Most assemblers treat '<' and '>' as byte-select operators. Merlin 32
treats them as shift operators, making '<' effectively a no-op. A
mask is applied based on the length implied by the opcode or pseudo-op,
e.g. "DFB <FOO" will mask off the high bits. This is problematic for
instructions like "LDA <FOO", where the choice between absolute and DP
addressing depends on the value of "<FOO". If FOO is >= $100, the
lack of masking will cause it be treated as absolute. There is
currently no other mechanism to force the use of a direct-page opcode.
The only recourse is to append "&$ff" to the operand, so the
assembler knows that it can be handled as a DP op. The code generator
has been updated to add "&$ff" where needed, based on the label's
value. Unfortunately the assembler doesn't accept this for certain
specific addressing modes; this appears to be a bug.
The relevant test cases (2003x-labels-and-symbols) have been updated
to exercise these situations. The current test projects side-step the
failing assembler behavior by using a DP label instead. These should
be changed to correctly exercise the full behavior, with the code
generator outputting the instructions as raw hex values to work
around bugs.
There are some deliberately broken things (like a duplicate label) in
the 20030 case that were copied into the 20032 case when it was
created. For ease of editing these have been removed from 20032.
(issue #170)
Fixed "HiAscii" macro used for cc65 output. The macro name was being
forced to upper case at the point of use when the settings were
configured to generate upper-case pseudo-op names.
Also, added upper-casing config info to comment in HTML output.
The "goto" dialog (Ctrl+G) jumps to an offset, address, or label. If
an address is specified, it is resolved relative to the first line of
the current selection, so that if the same address appears multiple
times we select the "best" one.
This turned out to be too restrictive, because if the region was marked
with "disallow outbound address resolution" we wouldn't look anywhere
except the current region. While arguably correct, it was annoying
to have to move the cursor before being able to jump to a unique
address elsewhere in the file.
Now, if the address lookup fails to identify an offset, we repeat it
with "disallow outbound" flags ignored.
The new GetOperandTargetOffset() function doesn't handle isolated
address regions quite right, because it uses a symbol table lookup
that doesn't know about them. For now, we can work around it by
tweaking the behavior.
The default width doesn't line up with the right edge of the panel,
so either you're not seeing as much text as you could, or it's
scrollable and will lurch over if you double-click in the text area.
Now the width is set to '*', which makes the column wide enough to
fill the panel, and automatically resizes as things shift.
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.
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)
We were passing a reference to MainController in, and calling a
method on it, which is a little convoluted. Now the main controller
subscribes to a "settings applied" event, and handles the update with
an event handler.
No change in behavior.
Andy McFadden