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.
A SOS binary had situation were an instruction was being reformatted
as inline data by an extension script. The code that was supposed
to detect and prevent this had a bug that caused it to only look at
the first byte. The resulting confusion caused the program to crash.
(issue #150)
The JavaScriptSerializer class throws an exception if the JSON data
exceeds a certain size. The default limit is 2MB, which is relatively
easy to hit because of the verbosity of the serialized data.
Super Mario Bros needs about 1MB of JSON for a binary with 32KB + gfx.
Using that as a guide, we need 32x the source file size for a
thoroughly-documented project. We currently limit the max binary size
to 1MB for practical reasons, so a cap of 32MB should cover us.
This change raises the limit to 64MB, with a slightly higher limit on
the deserialization side because we add newlines for readability.
This is more of a workaround than a fix, but it should do for now.
(issue #137)
Added an address mask to support mirroring of I/O registers.
Changed to specify the access direction of address.
Fixed a definition with different addresses but duplicate label names.
(`OAMDATA`, `VMDATAL`, `VMDATAH`, `CGDATA`)
If you edit an existing symbol, the "is the label unique" test will
always false-positive match itself, so we have to explicitly handle
that case. Dialogs like Edit Instruction Operand make things a bit
more complicated because they don't flush results to the symbol
table immediately, which means the symbol we pass into the Edit Def
Symbol dialog to edit isn't necessarily the one we need to exclude
from the label uniqueness test.
The dialog was using the initial value as both "original" and
"initial", which caused some issues. We now pass both values in.
Also, removed some dead code identified by VS.
The recent tweaks to improve operand editing broke a common case
when creating a project symbol.
Also, tweaked the operand edit case a little more, for the case where
the operand's symbol was entered manually.
Minor change to solution. Removed CodeLab project stub, which was
still targeting .NET Framework 4.6.1.
The other projects with WPF code target 4.6.2, and I haven't updated
them to 4.8 out of a fear that it might make 6502bench harder to
install on older systems. The down side is that it requires an
extra "dev pack" download to build the source code. 4.8 is the end
of the line for .NET Framework, so at some point we should make that
the official target.
If a symbol is marked as "exported", it is added to the symbol table
generated at the end of the HTML output. If the symbol identifies a
non-addressable location, we need to show that.
Also, added a header row.
Double-clicking on an entry in the symbols window is supposed to take
you to the place where that symbol is defined. This worked for code
labels but not for project/platform symbols. We now jump to the
appropriate EQU statement, if one exists.
The instruction operand editor has a shortcut button for editing a
project symbol. Attempting to change the comment field twice
without closing the operand editor in between would result in a
complaint about duplicate symbol names.
