It's not quite the same as the character encoding -- sometimes we
want a mix of things -- so it gets its own enum. The value is
saved to the project file, but not actually used yet.
Also, moved some combo box strings into XAML resources.
Remove left/right arrow PNGs. Remove duplicate copies of icon.
Tweak some comments. Set application icon. Adjust padding on
group boxes in first tab of app settings.
The previous code output a character in single-quotes if it was
standard ASCII, double-quotes if high ASCII, or hex if it was neither
of those. If a flag was set, high ASCII would also be output as
hex.
The new system takes the character value and an encoding identifier.
The identifier selects the character converter and delimiter
pattern, and puts the two together to generate the operand.
While doing this I realized that I could trivially support high
ASCII character arguments in all assemblers by setting the delimiter
pattern to "'#' | $80".
In FormatDescriptor, I had previously renamed the "Ascii" sub-type
"LowAscii" so it wouldn't be confused, but I dislike filling the
project file with "LowAscii" when "Ascii" is more accurate and less
confusing. So I switched it back, and we now check the project
file version number when deciding what to do with an ASCII item.
The CharEncoding tests/converters were also renamed.
Moved the default delimiter patterns to the string table.
Widened the delimiter pattern input fields slightly. Added a read-
only TextBox with assorted non-typewriter quotes and things so
people have something to copy text from.
High ASCII and other encodings will be noted in the operand field,
not the opcode, so we no longer need these.
This removes the six input fields from the Pseudo-Op tab of app
settings. Values were stored as a serialized class in settings,
which generally works correctly as far as forward/backward
compatibility goes, so no worries there.
This also adds four "delimiter pattern" fields to the Code View tab,
allowing the user to customize how encoded strings are marked up
for the code list. The values aren't actually used yet.
Also, fixed an issue where changes to text fields on the Pseudo-Op
tab weren't raising the dirty flag.
The plugin objects are MarshalByRefObject stubs, which means they
don't actually implement the interfaces we're checking for. There's
some additional overhead to do the interface check. We can avoid
it by doing the interface queries during initialization, and just
checking some bit flags later on.
Also, in the extension script info window, show a list of
implemented interfaces.
We've been treating ASCII strings and instruction/data operands as
ambiguous, resolving low vs. high when generating output for the
display or assembler. This change splits it into two separate
formats, simplifying output generation.
The UI will continue to treat low/high ASCII as as single thing,
selecting the format appropriately based on the data. There's no
reason to have two radio buttons that are never both enabled.
The data operand string functions need some additional work, but
that overlaps substantially with the upcoming PETSCII changes, so
for now all strings set by the data operand editor are low ASCII.
The file format has changed again, but since there hasn't been a
release since the previous change, I'm leaving the file format
at v2. Code has been added to resolve the ASCII mode when loading
a v1 project file.
This removes some complexity from the assembly code generators.
DCI is handled with the ".shift" pseudo-op. The .null, .ptext,
and .shift operators all work correctly with escaped characters,
so we no longer redo those.
This generalizes the string pseudo-operand formatter, moving it into
the Asm65 library. The assembly source generators have been updated
to use it. This makes the individual generators simpler, and by
virtue of avoiding "test runs" should make them slightly faster.
This also introduces byte-to-character converters, though we're
currently still only supporting low/high ASCII.
Regression test output is unchanged.
This was the result of the earlier change to eliminate "reverse DCI"
strings. On further examination, it doesn't seem like we can do
much better than a hex dump without more work than the situation
merits. So hex dump it is.
During a discussion with the cc65 developers, I became convinced that
generating "MVN $01,$02" is wrong, and "MVN #$01,#$02" is correct.
64tass, cc65, and Merlin 32 all accept this syntax; only ACME does
not. Operands without a leading '#' should be treated as 24-bit
values, and have the bank byte extracted.
This change updates the on-screen display and assembled output to
include the '#'. The ACME generator uses a Quirk to suppress the
hash mark. (It doesn't currently accept values larger than 8 bits,
so there's no ambiguity.)
We used to use type="String", with the sub-type indicating whether
the string was null-terminated, prefixed with a length, or whatever.
This didn't leave much room for specifying a character encoding,
which is orthogonal to the sub-type.
What we actually want is to have the type specify the string type,
and then have the sub-type determine the character encoding. These
sub-types can also be used with the Numeric type to specify the
encoding of character operands.
This change updates the enum definitions and the various bits of
code that use them, but does not add any code for working with
non-ASCII character encodings.
The project file version number was incremented to 2, since the new
FormatDescriptor serialization is mildly incompatible with the old.
(Won't explode, but it'll post a complaint and ignore the stuff
it doesn't recognize.)
While I was at it, I finished removing DciReverse. It's still part
of the 2005-string-types regression test, which currently fails
because the generated source doesn't match.
There's no easy way to make non-zero-bank 65816 code work, so I'm
punting and just generating a whole-file hex dump for those. This
renders tests 2007 and 2009 useless, so I'm hesitant to claim that
ACME support is fully functional.
WDM <arg> now works. MVN/MVP are still broken. Correct code is
generated for whichever version of the assembler is configured.
Regression tests updated for new version.
Also, fixed a UI bug where manual edits to the assembler path were
being ignored.
The 65816 definition makes it a two-byte instruction, like COP. On
the 6502 it acted like a two-byte instruction, but in practice very
few assemblers treat it that way. Very few humans, for that matter.
So it's now treated as a single byte instruction, with the following
byte encoded as a data value.
Instead of providing no-op CheckJsr/CheckJsl, plugins now declare
which calls they support by defining interfaces on the plugin class.
I added a CheckBrk call for code like Apple /// SOS calls, which
use BRK as an OS call mechanism. The formatting doesn't work quite
right yet because I've been treating BRK as a two-byte instruction.
Hardly anything else does, and I think it's time I stopped (but not
in this commit).
Note: THIS BREAKS ALL PLUGINS that use the inline JSR/JSL feature,
which is pretty much all of them.
- Updated the tutorial to track changes to WPF, and to clarify
existing content.
- Fixed Ctrl+H Ctrl+C, which was getting masked by the Copy command
handler.
- Fixed initial selection of address in Set Address.
- 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)
