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.
This was an attempt to add a "loading..." dialog during the initial
open of the project. This can have some lag because we create a
sandbox (which is currently taking about 300ms) and do a full project
refresh (which can take more than a second on a large 65816 project).
The trick is that we need to do these things on a background thread
while the main thread manages the UI. We can't manipulate the UI
from the background thread. For the most part this works, as the
project refresh stuff isn't tied to the UI, but we run into trouble
when generating the line list. As currently implemented, the line
generator interacts directly with DisplayList, which is acting as an
ItemsSource for the main ListView.
To make this work correctly we'd need to dissociate DisplayList from
LineListGen, e.g. by having DisplayList record but defer changes
until a "go" method is called on the main thread.
The speed is only an issue for large programs, which aren't really
supported yet -- the UI is awkward to use with large files -- so I'm
not going to pursue this further for now.
Also, an unrelated fix: there was an issue where the current ListView
scroll position would be retained if you opened a project while one
was already open. Harmless but weird. We now scroll to the top.
The ListView control provides a ScrollIntoView() method that ensures
the specified item is on screen, scrolling the ListView if needed.
Unfortunately this method is very slow (50-100 ms) and sometimes
fails entirely on larger lists. (Yay WPF.)
Because the ListView is scrolling by fixed-height item, it's possible
to use the underlying ScrollViewer to move the list instantaneously
and reliably. So now we do that.
Also, fixed a bug with select-all, where we weren't clearing the
previous selection before calling SelectAll(), leading to a mismatch
with the secondary data structure that we maintain because WPF
ListViews can't deal with large selections efficiently. (Yay WPF.)
There's still some weird behavior, e.g. sometimes hitting F5 clears
the current selection and sometimes it doesn't. I think it's related
to which item has focus and the fact you're hitting a key; using the
debug menu item doesn't cause the behavior.
Also, increased MAX_SEL_COUNT from 2000 to 5000. That takes about
200ms to restore to a ListView on my 5-year-old system.
Whenever the display list gets regenerated, we need to restore the
code list view scroll position to the previous location in the file.
This gets tricky when multiple lines are appearing or disappearing.
We were saving the file offset of the line, but that works poorly
when there's a multi-line comment associated with that offset,
because we end up scrolling to the top of the comment whenever any
part of the comment is at the top of the screen.
We now track the file offset and the number of lines we were from
the top of that offset's content. This works well unless we remove
a lot of lines. If the adjusted line index would put us into a
different file offset, we punt and just scroll to the top of the item.
Also, fix a crasher in Edit Note.
Also, fix behavior when the list shrinks while a line near the end
of the file is selected.
Also, change a few instances of "Color.FromArgb(0,0,0,0)" to use a
common constant.
While I was at it, I noticed that the ASCII chart and hex dump
viewer windows were always in front of the main app window. It looks
like child windows are always in front. The easy fix is to not
set an owner.
This causes a new problem: the windows don't get closed automatically
when the parent window closes, and the app won't exit until all
windows are closed. So we now explicitly close the hex dump and
ASCII chart windows when the main window is closed, and we now keep
track of all the external-file hex dump windows. (It always sort of
bothered me that we were creating hex dump windows and not keeping
track of them. Itch has now been scratched.)
Also, changed the ascch-mode setting to be an enum rather than an
integer. Renamed the setting to ascch-mode1.
The contents of cdlv-col-widths and hexd-char-conv have changed. The
app correctly ignores things it doesn't understand when going either
forward or backward (between SourceGen and SourceGenWPF), but it's
nicer to just not have the settings get clobbered.
If you select a note, delete it, select some nearby lines, and hit
undo, then the next time you hit up/down arrow the list will jump
back to the first line. The workaround for this appears to be to
set the focus on a selected ListViewItem from an obscure event.
Maybe there's a simpler way that I just missed? This is absurd.
(Yay WPF.)
