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.
The setting determines whether bulk data is displayed as an unbroken
string of hex digits, or as "$xx,$xx,...". The latter is easier to
read and should be the default.
One place in the code did consider it to be the default, so if the
config file didn't have a value for the setting, the settings UI would
incorrectly show it as enabled.
The existing API was better suited to direct color than indexed
color. The NES visualizer was using a slightly silly hack to avoid
duplicate colors; this has been removed.
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.
The tutorial was creating a new address region at +000002 without
removing the previous one, which leaves the 16-bit file load address
sitting at $1000 when it should be non-addressable. The text now
shows the correct procedure. Some screen shots had to be recaptured
to show the greyed-out address field.
This doesn't change anything meaningful about the disassembly -- the
PRG optimization hides the region start/end markers either way -- but
it's more correct this way, and it's an opportunity to introduce
the use of non-addressable regions for file headers.
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.
