The ListView style was using "Stretch" for TextBoxes in the code list,
which caused the background of the entire address / label / operand
field to be drawn in the highlight color, rather than just the area
covered by the text. This is fine for address and label, but it just
felt weird for the operand field because that tends to be very wide
(to accommodate strings, bulk hex data, etc).
There doesn't seem to be a way to specify HorizontalContentAlignment
per-column in WPF. (Note this is different from HorizontalAlignment,
which *is* is a per-column property.)
This changes the style to use HorizontalContentAlignment=Left, so
the highlight just covers the text. The only time this causes a
functional change is when you highlight an operand for a line that
doesn't have a label, because instead of highlighting an empty
rectangle you now see nothing at all. (The address field is still
highlighted though.)
When a code or data line is selected in the code list, if the operand
is an address inside the file, we highlight the address and label.
It's also useful to highlight the other way: when a code or data line
is selected, find all lines whose operands reference it, and highlight
the operand field.
This is a little trickier because there can be multiple references,
but all of the information we need is in the cross-reference table.
Biggest changes were to the address region handling in Tutorial1
and the use of StdInline.cs for the inline strings in Tutorial4.
Also, fixed the off-by-one error in Tutorial1.
The code that sets and removes analyzer tags allows you to select a
mix of lines. If the mix included the header comment, the negative
file offset would cause a crash.
If an end-of-line comment ended with '\', the code that "prettifies"
the JSON output would get confused, and would start inserting \r\n
after commas inside comment strings. This didn't corrupt the project
files, but it did make them look funny, and required manual cleanup.
Added a sample. This won't catch regressions of this particular
problem because it only happens when you save the file, but if
nothing else it'll act as documentation.
End-of-line comments have a couple of guidelines: keep it short, and
don't use non-ASCII characters. Violating these isn't an error, so
we should be making the text blue rather than red.
The DVG format, used for vector games like Asteroids, is the
predecessor to the AVG graphics used in games like Battlezone.
Also, added some extended error checks on wireframe vertices.
Also, minor edits to the README and daily tips.
The implementation was mapping labels to addresses, then formatting
inline data at the matching address. This may be incorrect when there
are multiple sections of the file mapped to the same address. The
correct approach is to record the offsets of the matching labels, and
then do an address-to-offset translation for each JSR.
Also, show a note in the Info window when a JSR has been marked
no-continue by an extension script.
Also, updated Daily Tips.
If you change the selection by double-clicking in one of the side
windows (References, Notes, Symbols, Messages) and then attempt
to navigate with the arrow keys, the program will appear to hang
briefly, then jump to the start or end of the project and shift the
window focus to something else (like the Help menu in the menu bar).
For reasons I don't fully understand, the behavior is fixed by
removing unnecessary calls to codeListView.Focus(). The calls were
intended to shift input focus to the main ListView, but they're no
longer necessary, and appear to upset WPF.
(issue #113)
We allow empty lines and lines that begin with ';' in .sym65. Lines
with nothing but whitespace, or comments with leading whitespace,
caused a warning. It can be aesthetically nice to line up the start
of comments, and lines with pointless whitespace aren't problematic,
so we now allow these without complaint.
Added some samples to the 20170-external-symbols data file. No
change to the test output.
It's useful for extension scripts to be able to get the file offset
of symbols in non-addressable regions. One example of this is CHR
ROM data for an NES cartridge. However, we were getting the offset
by doing an address-to-offset mapping on the plugin side, which by
definition doesn't work for non-addressable memory.
So we now add the offset to PlSymbol objects for user labels and
address region pre-labels. The NES visualizer has been updated to
use the new field.
Also, fixed a bogus complaint about bank overruns for non-addressable
regions.
Altered the address region edit UI a little to improve clarity.
Also, close the hex dump viewer window when Escape is hit. (The
tool windows don't have "cancel" buttons, so the key has to be
handled explicitly.)
The ACME assembler gets upset if you use "not" as a label. We now
avoid doing so, using a generalized implementation of the opcode
mnemonic rename code. (Issue #112.)
Renamed a label to "not" in the 20081-label-localizer test.
Fixed a crash when the listing is refreshed while a .adrend line is
the only thing selected.
Fixed .adrend lines being spammed if the last thing before it is a
multi-byte item, and you edit a comment / note / label on that line.
Harmless, but weird.
Also, added keyboard shortcuts in DefSymbol editor, so you can change
from address to constant with Alt+C.
If you put a value in the "symbol" field of an instruction with an
address operand, you're establishing a symbolic reference to a label
that may be at a different address than the numeric value of the
operand. But if you then hit the "edit label" button, you'll edit
the label at the *numeric* reference address, which can be confusing.
We now disable the create/edit label button when the format has been
set to "symbol".
The button is just a short-cut, so disabling it doesn't prevent the
user from doing anything.
The initial screen is largely blank, with just the four large buttons
for new/open/recent1/recent2. It now also has a "tip of the day" box,
with text and an optional image.
The tips and images are kept in the RuntimeData directory. They're
small enough that they could have been baked into the binary, but
there's enough other stuff going on there that it didn't seem
necessary. Also, if the tips annoy you, removing the tips file will
hide the tip UI.
The index of the tip shown is based on the day of the year, modulo
the number of defined tips. So it will be different every day (with
a bit of hand-waving at the end of the year).
Added a pop-up menu with three options: default (curly quotes),
straight, and Merlin. Removed the "reset to defaults" buttons.
Also, slightly rearranged the Display Format tab so that the quick
set pop-up is on the left, near the items it affects. Moved the
"use comma-separated format for bulk data" checkbox over as well,
since it's part of the set.
This allows regions that hold variable storage to be marked as data
that is initialized by the program before it is used. Previously
the choices were to treat it as bulk data (initialized) or junk
(totally unused), neither of which are correct.
This is functionally equivalent to "junk" as far as source code
generation is concerned (though it doesn't have to be).
For the code/data/junk counter, uninitialized data is counted as
junk, because it technically does not need to be part of the binary.
This action removes operand formatting from all code and data in the
selected range. In most cases this is equivalent to simply editing
the various items and clicking the "default" format radio button,
but the feature can be used to remove data formats that end up inside
multi-byte instructions. Instructions with such formats cause warnings
and were tricky to fix.
Labels embedded in multi-byte items are also tricky to remove, so this
clears those as well. It does not remove visible labels. This is
done in a single pass, which means that labels that would become visible
after the formatting is cleared will still be removed.
Also, fix inclusion of address range end lines when restoring the
selection. Their peculiar nature -- being associated with the offset
of the last byte of multi-byte items -- was interfering with the
selection save code. This does not add them to the selection when
an address region deletion is undone, since technically they weren't
part of the selection.
Also, moved Edit Note higher in the Actions menu.
Changed the code that generates cross-references for pre-labels to
ignore labels in regions with non-addressable parents. Also, changed
the code that complains about references to labels in non-addressable
areas to ignore pre-labels, because it was complaining about references
to pre-labels on region starts that were followed by a non-addressable
region start.
In the address region edit dialog, split up the descriptive text for
the "resize" option to make it easier to see the new end offset and
length. It doesn't look quite right because it's not using the mono
font like the text near the top, but it'll do.
When multiple lines are selected, the Info window now shows the first
line/offset, last line/offset, and bytes spanned by the selection.
This is helpful if you're trying to figure out how big something is.
Added support for "relative" address regions to the Merlin 32 and cc65
code generators. These generate "flat" address directives, and so
were a little more complicated.
Suppressed generation of relative operands for non-addressable regions.
Also, tweaked the 20250-nested-regions test to include a negative
relative region offset.
Added a warning to the index page that only appears when viewing it
over http/https. The issue is that the manual on the web reflects the
tip-of-tree sources, which may be inaccurate for whatever version the
user has.
Also, provide an alternate path to opening the manual in-app when
under development.
Move the SourceGen manual to a subdirectory in "docs", so that it can
be accessed directly from the 6502bench web site. The place where
it's installed in the distribution doesn't change.
Update documentation. Made lots of address region changes, and split
"intro" into two parts. Removed all content from "tutorials.html".
This does not update the tutorial, because that goes live as soon as
it's checked in.
Modified "jump to" code to understand address range start/end lines.
If there are multiple starts or ends at the same offset, we jump to
the first one in the set, which is suboptimal but simpler to do.
Simplified the API, embedding GoToMode in the Location object (which
is where it really needs to be, to make fwd/back work right).
Updated HTML export to grey out addresses in NON_ADDR sections.
Changed default pseudo-op strings for address regions to ".addrs" and
".adrend", after trying a bunch of things that were worse. Added
definitions for region-end pseudo-ops to Merlin32 and cc65 for display
on screen.
Added regression test 20260 for address region pre-labels.
Fixed handling of leading underscores in platform/project symbols.
These need to be escaped in 64tass output. Updated regression test
20170-external-symbols to check it.
Implemented address region pre-labels. These are useful if the code is
relocating a block from address A to address B, because the code that
does the copying refers to both the "before" address and the "after"
address. Previously you'd give the block the "after" address and the
"before" would just appears as hex, because it's effectively an
external address.
Pre-labels are shown on screen with their address, but no other fields.
Showing the address makes it easy to see the label's value, which isn't
always obvious right before a .arstart. The labels are suppressed if the
address value evaluates to non-addressable.
This defines a new type of symbol, which is external and always global
in scope. Pre-labels affect label localization and must go through
the usual remapping to handle clashes with opcode mnemonics and the
use of leading underscores. Cross-references are computed, but are
associated with the file offset rather than the label line itself.
Added a new filter to the Symbols window ("PreL").
Implemented label input and checking in the address editor. Generally
added highlighting of relevant error labels.
Implemented "is relative" flag. This only affects source code
generation, replacing ".arstart <addr>" with ".arstart *+<value>".
Only output by 64tass and ACME generators.
Added a bold-text summary to radio buttons in address region edit
dialog. This makes it much easier to see what you're doing. Added
a warning to the label edit dialog when a label is being placed in
a non-addressable region.
Modified double-click behavior for .arstart/.arend to jump to the
other end when the opcode is clicked on. This matches the behavior
of instructions with address operands.
Reordered Actions menu, putting "edit operand" at the top.
Fixed AddressMap entry collision testing.
Fixed PRG issue with multiple address regions at offset +000002.
Added regression tests. Most of the complicated stuff with regions
is tested by unit tests inside AddressMap, but we still need to
exercise nested region code generation.
Added support for non-addressable regions, which are useful for things
like file headers stripped out by the system loader, or chunks that
get loaded into non-addressable graphics RAM. Regions are specified
with the "NA" address value. The code list displays the address field
greyed out, starting from zero (which is kind of handy if you want to
know the relative offset within the region).
Putting labels in non-addressable regions doesn't make sense, but
symbol resolution is complicated enough that we really only have two
options: ignore the labels entirely, or allow them but warn of their
presence. The problem isn't so much the label, which you could
legitimately want to access from an extension script, but rather the
references to them from code or data. So we keep the label and add a
warning to the Messages list when we see a reference.
Moved NON_ADDR constants to Address class. AddressMap now has a copy.
This is awkward because Asm65 and CommonUtil don't share.
Updated the asm code generators to understand NON_ADDR, and reworked
the API so that Merlin and cc65 output is correct for nested regions.
Address region changes are now noted in the anattribs array, which
makes certain operations faster than checking the address map. It
also fixes a failure to recognize mid-instruction region changes in
the code analyzer.
Tweaked handling of synthetic regions, which are non-addressable areas
generated by the linear address map traversal to fill in any "holes".
The address region editor now treats attempts to edit them as
creation of a new region.
Updated project file format to save the new map entries.
Tweaked appearance of .arend directives to show the .arstart address
in the operand field. This makes it easier to match them up on screen.
Also, add a synthetic comment on auto-generated .arstart entries.
Added .arstart/.arend to the things that respond to Jump to Operand
(Ctrl+J). Selecting one jumps to the other end. (Well, it jumps
to the code nearest the other, which will do for now.)
Added a menu item to display a text rendering of the address map.
Helpful when things get complicated.
Modified the linear map iterator to return .arend items with the offset
of the last byte in the region, rather than the first byte of the
following region. While the "exclusive end" approach is pretty
common, it caused problems when updating the line list, because it
meant that the .arend directives were outside the range of offsets
being updated (and, for directives at the end of the file, outside
the file itself). This was painful to deal with for partial updates.
Changing this required some relatively subtle changes and annoyed some
of the debug assertions, such as the one where all Line items have
offsets that match the start of a line, but it's the cleaner approach.
Reimplemented "set address" dialog as the Address Region Editor. The
new dialog configures itself differently depending on whether the user
appears to be trying to create, edit, or resize a region. Each mode
has two options, to allow the user to choose between floating and fixed
end points.
The old dialog would allow you to delete an address override by erasing
the address field. Now there's an explicit "delete region" button.
Changed the SetAddress undoable change function to use AddressMapEntry
objects.
We now show detailed information on .arstart/.arend in the Info window
when the lines are selected.
PRG files are now created without specifying a region for the first
two bytes, so the load address exists in a NON_ADDR hole. Fixed a
couple of issues to make that look right.
Split ".org" into ".arstart" and ".arend" (address range start/end).
Address range ends are now shown in the code list view, and the
pseudo-op can be edited in app settings. Address range starts are
now shown after notes and long comments, rather than before, which
brings the on-screen display in sync with generated code.
Reworked the address range editor UI to include the new features.
The implementation is fully broken.
More changes to the AddressMap API, putting the resolved region length
into a separate ActualLength field. Added FindRegion(). Renamed
some things.
Code generation changed slightly: the blank line before a region-end
line now comes after it, and ACME's "} ;!pseudopc" is now just "}".
This required minor updates to some of the regression test results.
AddressMap API reshuffle. Added "pre-label" to class and API. Split
AddressMapEntry into two parts to make it clear when FLOATING_LEN
has been resolved.
Updated display line list generator to use in-line linear map
traversal. Previous approach was to walk through the list of regions
in a second pass, inserting .ORG directives, but that was awkward
and is no longer needed.
This is the first step toward changing the address region map from a
linear list to a hierarchy. See issue #107 for the plan.
The AddressMap class has been rewritten to support the new approach.
The rest of the project has been updated to conform to the new API,
but feature-wise is unchanged. While the map class supports
nested regions with explicit lengths, the rest of the application
still assumes a series of non-overlapping regions with "floating"
lengths.
The Set Address dialog is currently non-functional.
All of the output for cc65 changed because generation of segment
comments has been removed. Some of the output for ACME changed as
well, because we no longer follow "* = addr" with a redundant
pseudopc statement. ACME and 65tass have similar approaches to
placing things in memory, and so now have similar implementations.
The data operand editor determines low vs. high ASCII formatting by
examining the first byte of string data. Unfortunately the test was
broken, and for strings with a 1- or 2-byte length, was testing the
length byte instead of the character data. This is now fixed.
This also changes the way empty strings are handled. Before, they
were allowed but not counted, so you couldn't create an empty string
by itself, but could do it if it were part of a larger group. This
was unnecessarily restrictive. Empty L1/L2/null-term strings are now
allowed.
This means that a buffer full of $00 can be formatted as a big pile
of empty strings, which seems a bit ridiculous but there's no good
reason to obstruct it.
(issue #110)
If you select a line that refers to another line, the target line's
address is highlighted. If you select multiple lines, the highlight
is removed. The code that removes the highlight was inadvertently
resetting the selection, making it impossible to shift-click a
range that ended with a highlighted line.
The bottom of the main window shows the total bytes in the project
along with how many are code, data, and junk. The junk figure wasn't
updating if you changed a data item to junk or vice-versa, because a
simple format change doesn't require reanalyzing the file.
To make the counter "live", we need to tell the updater to refresh the
values whenever a format changes to or from "junk".
If you select a note or long comment and delete it, the selection is
lost, because the selected item no longer exists. This is inconvenient
if you're working with the keyboard, because it moves the keyboard
position to the top of the file.
If the previous selection was non-empty, and the new selection is
empty, we want to select the line that would have appeared below the
item that was deleted. Making this work exactly right is a bunch of
work, but we can make it work mostly right by selecting the first line
associated with the offset of the previous selection.
It's useful to have an example of an extension script that handles
multiple types of things. It's also good to show that scripts can
handle data types other than strings, and can chase an address to
format data items elsewhere in the code.
This required updating the tutorial binary, adding the new script,
and updating the tutorial text and associated screen shots.
If a DCI string ended with a string delimiter or non-ASCII character
(e.g. a PETSCII char with no ASCII equivalent), the code generator
output the last byte as a hex value. This caused an error because it
was outputting the raw hex value, with the high bit already set, which
the assembler did not expect.
This change corrects the behavior for code generation and on-screen
display, and adds a few samples to the regression test suite.
(see issue #102)
On the 65816, if you say "JSR foo" from bank $12, but "foo" is an
address in bank 0, most assemblers will conclude that you're forming
a 16-bit argument with a 16-bit address and assemble happily. 64tass
halts with an error. Up until v1.55 or so, you could fake it out
by supplying a large offset.
This no longer works. The preferred way to say "no really I mean to
do this" is to append ",k" to the operand. We now do that as needed.
I didn't want to define a new ExpressionMode for 64tass just to
support an operand modifier that should probably never actually get
generated (you can't call across banks with JSR!), so this is
implemented with a quirk and an op flag.
64tass v1.56.2625 is now the default.
(issue #104)
This is another attempt to fix the ListView keyboard position
behavior. Basic problem: if you change something in the ListView,
the keyboard position is lost, and WPF doesn't expose a nice way to
save and restore it. It appears the way to set the position is by
calling Focus() on the specific item you want to have as the "current"
keyboard position, but you can only do that at certain times.
This attempt removes the grid-splitter resize hack, in favor of just
setting a "needs refocus" flag when we restore the selection set.
This causes Focus() to be called from the StatusChanged callback on
the next event with status="containers generated".
During testing I noticed some other odd behavior: if you used "goto"
to jump to an address, up/down arrows would change focus to a
different control (menu items, grid splitters, etc). The problem
there was that we were setting focus to the ListView control rather
than to a ListViewItem, so arrow keys were in control-traversal mode
rather than list-walk mode. That is also fixed.
(Issue #105)
The DCI string format uses character values where the high bit of the
last byte differs from the rest of the string. Usually all the high
bits are clear except on the last byte, but SourceGen generally allows
either polarity.
This gets a little uncertain with single-character strings, because
SourceGen can't auto-detect DCI very effectively. A series of bytes
with the high bit set could be a single high-ASCII string or a series
of single-byte DCI strings.
The motivation for allowing them is C64 PETSCII. While ASCII allows
"high ASCII" as an escape hatch, PETSCII doesn't have that option, so
there's no way to mark the data as a character or a string. We still
want to do a bit of screening, but if the user specifies a non-ASCII
character set and the selected bytes have their high bits set, we
want to just treat the whole set as 1-byte DCI.
Some minor adjustments were needed for a couple of validity checks
that expected longer strings.
This adds some short DCI strings in different character sets to the
char-encoding regression tests.
(for issue #102)
The code for formatting an address table allows you to specify that
code start tags should be placed on all targets. However, unnecessary
tags are undesirable, and it's not necessary to add a tag if the
target is already treated as executable code. So the implementation
tested to see if the target address was already an instruction.
The code was incorrectly testing for "is instruction", rather than "is
instruction start", which meant that if the table entry pointed at an
instruction embedded inside another instruction we would conclude that
the tag wasn't necessary, when in fact it was. Not only weren't we
getting a useful table entry, we were adding a symbolic reference to a
hidden label.
(issue #103)
When formatting one or more strings with the Edit Data Operand dialog,
the code must determine which options to present. If the selected
bytes appear to represent one or more null-terminated strings, that
option is enabled in the UI.
The "format recognizers" enforce some strict rules, e.g. null-
terminated strings must end in $00, and also try to confirm that the
data looks like a printable string. The algorithm rejects strings
with "illegal" characters in them. This is simpler on some systems
than others. For example, C64 PETSCII defines quite a few control
characters in ways that make them useful for embedding in printable
strings.
The "recognizers" are only used by the operand edit feature, not as
part of an automated string detector, so there's no real upside in
overriding the user's desire to form a string with arbitrary bytes.
This removes the quick rejection from the four recognizers (null-term,
len8, len16, dci). It does not alter the high-level code, which
still insists on a certain percentage of the string being printable;
that may be worth revisiting as well.
(issue #100)
64tass wants to place its output into a 64KB region of memory,
starting at the address "*" is set to, and continuing without
wrapping around the end of the bank. Some files aren't meant to be
handled that way, so we need to generate the output differently.
If the file's output fits nicely, it's considered "loadable", and
is generated in the usual way. If it doesn't, it's treated as
"streamable", and the initial "* = addr" directive is omitted
(leaving "*" at zero), and we go straight to ".logical" directives.
65816 code with an initial address outside bank 0 is treated as
"streamable" whether or not the contents fit nicely in the designated
64K area. This caused a minor change to a few of the 65816 tests.
A new test, 20240-large-overlay, exercises "streamable" by creating
a file with eight overlapping 8KB segments that load at $8000.
While the file as a whole fits in 64KB, it wouldn't if loaded at
the desired start address.
Also, updated the regression test harness to report assembler
failure independently of overall test failure. This makes it easier
to confirm that (say) ACME v0.96.4 still works with the code we
generate, even though it doesn't match the expected output (which
was generated for v0.97).
(problem was raised in issue #98)
The initial implementation was testing the byte value rather than
the converted value, so backslashes were getting through in high
ASCII strings. PETSCII and C64 screen codes don't really have a
backslash so it's not really an issue there.
The new implementation handles high ASCII correctly. The various
201n0-char-encoding-x regression tests have been updated to verify
this.
The code generator outputs an optional comment specifying which
version of which assembler the code was generated for. This was
handled inconsistently and, for the most part, incorrectly. We now
report the correct version.
Two things changed: (1) string literals can now hold backslash
escapes like "\n"; (2) MVN/MVP operands can now be prefixed with '#'.
The former was a breaking change because any string with "\" must
be changed to "\\". This is now handled by the string operand
formatter.
Also, improved test harness output. Show the assembler versions at
the end, and include assembler failure messages in the collected
output.
If you have multiple overlapping segments (say, four 8KB chunks
that all load at $8000), and you use the "goto" command to jump
to address $8100, it should try to jump to that address within
whichever segment you happen to be working (based on the current
line selection). If that address doesn't exist in the current
segment, it's okay to punt and jump to the first occurrence of that
address in the file.
The existing code was always jumping to the first instance.
(related to issue #98)
Code generated by one of the C compilers sets up the stack frame and
then maps the direct page on top of it. If the value at the top of
the stack is 16 bits, it will be referenced via address $ff. The
local variable editor was regarding this as illegal, because lvars are
currently only defined for direct page data, and the value doesn't
entirely fit there (unless you're doing an indirect JMP on an NMOS
6502, in which case it wraps around to $00... but let's ignore that).
The actual max width of a local variable is 257 because of the
possibility of a 16-bit access at $ff.
Older versions of SourceGen don't seem to have an issue when they
encounter this situation, as worrying about (start+width) is really
just an editor affectation. The access itself is still a direct-page
operation. You won't be able to edit the entry without reducing the
length, but otherwise everything works. I don't think there's a need
to bump the file version.
Added a compiled C implementation of strlen(). The most interesting
part about this is that it references a 16-bit value via direct-page
address $ff, which means you'd want a local variable with
address=$ff and width=2. The current UI prevents this.
We were using a very simple regex pattern for the label part, and
not performing additional validation checks later. This allowed
a symbol that started with a number (e.g. "4ALL") to get much farther
than it should have.
This change modifies the regex pattern to match only valid label
syntax.
Replaced the link at the top of the manual. Remove reference to
old tutorial doc. Added an obsolescence notice to the top of the
old tutorial. Updated tutorial message and link in README.
Also, fixed sidenav style.
If you changed the width of a column, and then clicked the "toggle
display of cycle counts" button in the toolbar, the column width
would revert. The problem appears unique to that toolbar button,
so for now the fix is localized there. The more general fix is to
ensure that column width changes don't get stomped, but that's a
larger change.
There's no need to use XHTML Transitional. The only change outside
the template was to use "id" for anchors instead of "name", as the
latter is deprecated.
The calculations were wrong for certain situations, generating
answers that were useless or that caused a false-positive overflow
error.
This adds a couple of simple regression tests, modeled after layout
of the Lode Runner sprite sheet (which worked fine before) and the
Empire II EWS3 font (which failed).
This also bumps up some of the arbitrary limits in the visualizer.
(issue #94)
The $Cxxx I/O locations are mapped into banks $E0/E1, and are usually
configured to appear in banks $00/01 as well. Direct access to
locations in banks $E0/E1 is common in 16-bit code, but we only had
definitions for $E0.
This adds a clone of definitions for $E1, and renames the symbols
to be _E0/_E1 instead of _GS.
This can also be solved with MULTI_MASK, but that will always use
$E0 as the base address, so references to $E1/Cxxx will have a large
adjustment added ("+$10000"), which is kind of ugly.
Note we still don't have definitions for $01/Cxxx. I'll add those
if I run into them in 16-bit code. (That might be a reasonable use
of MULTI_MASK; feels less ugly somehow.)
The test for max allowed value was assuming 16-bit addresses.
We had no tests for 24-bit values, so this adds a 65816-specific
version of 20170-external-symbols.
