1
0
mirror of https://github.com/fadden/6502bench.git synced 2024-11-04 15:05:03 +00:00
Commit Graph

9 Commits

Author SHA1 Message Date
Andy McFadden
bb23bf82d1 Instruction operand editor rework, part 4 (of 4)
Updated the manual, and changed tutorial #2 to use local variables
for pointers.

If the symbol text box isn't empty, use the string as the initial
value for the Label when creating a new project property.

Fixed a crash when editing a project property.
2019-09-08 21:56:47 -07:00
Andy McFadden
4d9d5e2ecf Instruction operand editor rework, part 3
Implemented editing of labels and project symbols.

Also, cleaned up the local variable edit code.
2019-09-08 16:41:54 -07:00
Andy McFadden
e8ae534879 Instruction operand editor rework, part 2
Implemented local variable editing.  Operands that have a local
variable reference, or are eligible to have one, can now be edited
directly from the instruction operand edit dialog.

Also, updated the code list double-click handler so that, if you
double-click on the opcode of an instruction that uses a local
variable reference, the selection and view will jump to the place
where that variable was defined.

Also, tweaked the way the References window refers to references
to an address that didn't use a symbol at that address.  Updated
the explanation in the manual, which was a bit confusing.

Also, fixed some odds and ends in the manual.

Also, fixed a nasty infinite recursion bug (issue #47).
2019-09-07 20:56:43 -07:00
Andy McFadden
2633720c82 Instruction operand editor rework, part 1
Rearrange the UI elements, and convert the code-behind to a more
XAML-style form.  The basic stuff works, but the old "shortcut"
system is still in the process of being replaced.
2019-09-07 13:39:22 -07:00
Andy McFadden
7bbe5692bd Add C64 encodings to instruction and data operand editors
Both dialogs got a couple extra radio buttons for selection of
single character operands.  The data operand editor got a combo box
that lets you specify how it scans for viable strings.

Various string scanning methods were made more generic.  This got a
little strange with auto-detection of low/high ASCII, but that was
mostly a matter of keeping the previous code around as a special
case.

Made C64 Screen Code DCI strings a thing that works.
2019-08-15 17:53:12 -07:00
Andy McFadden
f33cd7d8a6 Replace character operand output method
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.
2019-08-11 22:11:00 -07:00
Andy McFadden
975b62db6b Treat low and high ASCII as two distinct formats
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.
2019-08-10 14:59:24 -07:00
Andy McFadden
0d0854bda7 Change the way string formats are defined
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.
2019-08-07 16:19:13 -07:00
Andy McFadden
c64f72d147 Move WPF code from SourceGenWPF to SourceGen 2019-07-20 13:28:37 -07:00