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)
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`)
