While it's okay to use ';', the classic Merlin editor will treat it
as an end-of-line comment and shove the entire thing off to the right
side of the screen.
This adds a configuration item to the app settings, with a default
value of ';'.
It was defined as a struct with exposed fields. Now it's a class
with simple properties. Default values are set explicitly, and
the contents are copied with a copy constructor instead of using
the struct member assignment.
The only functional change should be that the DelimiterSet members
are now properly cloned. The bulk of the changes are just refactoring
renames for the property names.
This also adds comments for all the properties.
This adds a new data format option, "binary include", that takes a
filename operand. When assembly sources are generated, the section
of file is replaced with an appropriate pseudo-op, and binary files
are generated that hold the file contents. This is a convenient way
to remove large binary blobs, such as music or sound samples, that
aren't useful to have in text form in the sources.
Partial pathnames are allowed, so you can output a sound blob to
"sounds/blather.bin". For safety reasons, we don't allow the files
to be created above the project directory, and existing files will
only be overwritten if they have a matching length (so you don't
accidentally stomp on your project file).
The files are not currently shown in the GenAsm dialog, which lets
you see a preview of the generated sources. The hex dump tool
can do this for the (presumably rare) situations where it's useful.
A new regression test, 20300-binary-include, has been added. The
pseudo-op name can be overridden on-screen in the settings.
We don't currently do anything new for text/HTML exports. It might
be useful to generate an optional appendix with a hex dump of the
excised sections.
(issue #144)
Note that address region isolation doesn't prevent explicit label
references from working (add update the test to prove it).
Added a note about pre-label xrefs.
If an address resolves to a user label in an isolated region, we
don't want to use it. However, we still want to try to match it
to a project/platform symbol.
For example, suppose the isolated code wants to reference address
$1C00, which is a memory-mapped I/O location in one area, but a
regular bunch of code in the other. We don't want it to map to
the regular code, but we do want it to resolve to our table of
platform I/O addresses.
We now handle this correctly. The regression test has been updated
to check this. The current implementation does a linear scan through
the symbol table, but I'm hoping this is not a common situation.
The reference manual has been updated to describe the new feature.
Added an address-to-offset test in the GeneratePlatformSymbolRefs()
method, which sets the operand symbols for anything that lands outside
the scope of the file. Because the region isolation code prevented
symbols from being associated with the operands in the initial code
scan, those operands were being examined here. Without the additional
test, the inappropriate label associations were getting a second chance.
Added "[!in]" and "[!out]" to the comment field of .addrs lines. This
is only for the on-screen display and text exports, not asm gen.
Bumped the project file CONTENT_VERSION.
Added a regression test (20290-region-isolation).
The test turned up an existing problem: pre-labels are emitted by the
asm generators on their own line, but the code that puts excessively
long labels on a separate line wasn't taking that into account. This
has been fixed. No changes to existing regression tests, which didn't
happen to use long labels.
This adds a pair of flags to address regions that control how
address resolution is performed.
Generally, when we're trying to convert an address to a file offset,
we do a depth-first search through the hierarchy of address regions
to find a match. For certain situations, such as multi-bank ROMs or
when code is executed in a separate subsystem, we don't want the
address resolver to specify an offset for something that's in a
different address space.
The search for a matching address starts from the region where the
address is referenced. The flags will prevent the search from
progressing "outward" (to parent or sibling regions) or "inward"
(from parent or sibling regions). Setting both flags effectively
makes the region an island.
Descending farther into the tree is not restricted by the "outward"
flag, i.e. addresses will still be found in child regions (assuming
they don't have the "disallow inward" flag set).
(issue #139)
The build flag causes the application to run as a 32-bit app on 64-bit
systems, which we don't want. We're still using "Any CPU" as the
platform target, so it will continue to work on 32-bit x86 systems;
we just no longer force it to always be 32-bit.
This only affects the main .NET Framework application executable.
The setting is not relevant for the libraries.
(Note to future self: the way things work changed with .NET Core,
which requires different executables for different targets, specified
with the RID. The older .NET Framework is Windows-only, which makes
it easier to have a single multi-target EXE.)
The cc65 docs say VICE labels start with '.'. Also, output local
labels prefixed with '@', per ca65 convention. The default output
file is now "labels.lbl".
Added some minimal documentation.
(issue #151)
We currently have two options for assembly code output, selected by
a checkbox in the application settings: always put labels on the same
lines as the instruction or data operand, or split the labels onto
their own line if they were wider than the label text field.
This change adds a third option, which puts labels on their own line
whenever possible. Assemblers don't generally allow this for variable
assignment pseudo-ops like "foo = $1000", but it's accepted for most
other situations. This is a cosmetic change to the output, and will
not affect the generated code.
The old true/false app setting will be disregarded. "Split if too
long" will be used by default.
Added test 20280-label-placement to exercise the "split whenever
allowed" behavior.
The "export" function has a similar option that has not been updated
(for no particular reason other than laziness).
Also, simplified the app settings GetEnum / SetEnum calls, which
can infer the enumerated type from the arguments. This should not
impact behavior.
Some debuggers allow you to import a list of labels for addresses.
This adds a command that generates a file full of labels in a
specific format. Currently the VICE monitor format is supported.
(issue #151)
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)
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.
End-of-line comments have a couple of guidelines: keep it short, and
don't use non-ASCII characters. Violating these isn't an error, so
we should be making the text blue rather than red.
The DVG format, used for vector games like Asteroids, is the
predecessor to the AVG graphics used in games like Battlezone.
Also, added some extended error checks on wireframe vertices.
Also, minor edits to the README and daily tips.
The implementation was mapping labels to addresses, then formatting
inline data at the matching address. This may be incorrect when there
are multiple sections of the file mapped to the same address. The
correct approach is to record the offsets of the matching labels, and
then do an address-to-offset translation for each JSR.
Also, show a note in the Info window when a JSR has been marked
no-continue by an extension script.
Also, updated Daily Tips.
If you change the selection by double-clicking in one of the side
windows (References, Notes, Symbols, Messages) and then attempt
to navigate with the arrow keys, the program will appear to hang
briefly, then jump to the start or end of the project and shift the
window focus to something else (like the Help menu in the menu bar).
For reasons I don't fully understand, the behavior is fixed by
removing unnecessary calls to codeListView.Focus(). The calls were
intended to shift input focus to the main ListView, but they're no
longer necessary, and appear to upset WPF.
(issue #113)
We allow empty lines and lines that begin with ';' in .sym65. Lines
with nothing but whitespace, or comments with leading whitespace,
caused a warning. It can be aesthetically nice to line up the start
of comments, and lines with pointless whitespace aren't problematic,
so we now allow these without complaint.
Added some samples to the 20170-external-symbols data file. No
change to the test output.
It's useful for extension scripts to be able to get the file offset
of symbols in non-addressable regions. One example of this is CHR
ROM data for an NES cartridge. However, we were getting the offset
by doing an address-to-offset mapping on the plugin side, which by
definition doesn't work for non-addressable memory.
So we now add the offset to PlSymbol objects for user labels and
address region pre-labels. The NES visualizer has been updated to
use the new field.
Also, fixed a bogus complaint about bank overruns for non-addressable
regions.
Altered the address region edit UI a little to improve clarity.
Also, close the hex dump viewer window when Escape is hit. (The
tool windows don't have "cancel" buttons, so the key has to be
handled explicitly.)
Andy McFadden