The calculations were wrong for certain situations, generating
answers that were useless or that caused a false-positive overflow
error.
This adds a couple of simple regression tests, modeled after layout
of the Lode Runner sprite sheet (which worked fine before) and the
Empire II EWS3 font (which failed).
This also bumps up some of the arbitrary limits in the visualizer.
(issue #94)
The $Cxxx I/O locations are mapped into banks $E0/E1, and are usually
configured to appear in banks $00/01 as well. Direct access to
locations in banks $E0/E1 is common in 16-bit code, but we only had
definitions for $E0.
This adds a clone of definitions for $E1, and renames the symbols
to be _E0/_E1 instead of _GS.
This can also be solved with MULTI_MASK, but that will always use
$E0 as the base address, so references to $E1/Cxxx will have a large
adjustment added ("+$10000"), which is kind of ugly.
Note we still don't have definitions for $01/Cxxx. I'll add those
if I run into them in 16-bit code. (That might be a reasonable use
of MULTI_MASK; feels less ugly somehow.)
- Added SOS parameter block formatting.
- Normalized SOS call names to values in SOS Reference Manual.
- Added SOS call error code constants.
- (from robjustice) Added more to A3-IO.sym65.
Also, rearranged the ProDOS code slightly.
(issue #85)
Added explicit widths to the 6502 vectors.
Two changes to Apple II hi-res visualization:
(1) Allow the row stride to be any value >= 1. This is useful
when data is stored in column-major order, i.e. it's a two-byte-wide
shape, with all of the data for the first column stored before the
data for the second column. (Set the row stride to 1, and the
column stride to the bitmap height.)
(2) Modify the layout of grids (sprite sheets and fonts), so that
we're closer to square when the item counts is low. Otherwise the
thumbnail just looks like a dashed line. (This one is strictly
cosmetic.)
Added a bunch of Applesoft entry points, and updated the F8ROM
definitions.
Added a visualizer for Applesoft shape table shapes that are not part
of an actual shape table.
On an Apple IIgs, the memory-mapped I/O locations are actually in
bank $e0, shadow-copied to bank $00. This adds a copy of the
relevant definitions from Cxxx-IO.sym65, with the addresses in bank
$e0 and "_GS" appended to the labels.
This is now included by default for the Apple IIgs system defintions.
(I thought about just adding them to Cxxx-IO.sym65, but then they
pollute the namespace for 8-bit systems. Stripping them out at run
time got a little complicated because the platform symbols are only
loaded once, and we'd have to reload them every time the CPU definition
changed. Further, there are a few aliases provided as constants, and
constants are allowed to be 32 bits on all systems, so those can't be
stripped. Rather than defining a new definition I figured it was
just easier to have a second file. Maintenance shouldn't be too taxing,
as definitions for 40-year-old machines don't change all that often.)
(I also thought about trying to make the address mirroring stuff work
for me here, but that would result in accesses being made to the
canonical address with an offset of +$e00000, which looks awful.)
The Disk ][ I/O locations are generally accessed as an offset, using
something like "LDA $C08n,X". However the range from $C080-C08F is
already used for language card in slot 0. SourceGen doesn't have a
way to distinguish between indexed and direct accesses, and even if
it did there's no way to separate one peripheral card from another
without knowing the contents of the CPU register.
As a workaround, the Disk ][ definitions are now in a separate symbol
file. When loaded, the definitions replace the base slot 0 equates.
I figure Disk ][ accesses are more common than language card
manipulation, so I'm making it a default for new projects. Existing
projects that reference the Disk ][ symbols (which existed, but as
constants) will need to be updated to include the new .sym65.
Similar to the ProDOS 8 formatter, but slightly more complex due
to the variable-length parameter block layout.
Also, added Orca shell call numbers to the list of constants.
Experimented with different orders of rotation for wireframe viewer.
Made perspective projection the default behavior. Removed animation
parameters from the stored Visualization when it's not animated.
Added a new category "sprite sheet", which is essentially a more
generalized version of the bitmap font renderer. It has the full
set of options for col/row/cell stride and colors. (Issue #74,
issue #75)
Added a flag that flips the high bits on bitmaps. Sometimes data
is stored with the high bit clear, but the high bit is set as it's
rendered. (Issue #76)
Also, fixed the keyboard shortcuts in the Edit Visualization Set
window, which were 'N' for both "New ___" items. (Issue #57)
For nonzero values we were leaving Z=prev, which is wrong when Z=0
because the AND result might be zero. Now if Z=1 we leave it alone,
but if Z=0 we now set it to Z=?.
Test 1003-flags-and-branches was testing for the (incorrect)
behavior, so we're now running into a BRK. This is fine.
This adds a new class and a rough GUI for the editor. Animated
visualizations take a collection of bitmaps and display them in
sequence. (This will eventually become an animated GIF.)
Fixed the issue where changes to tags in the set currently being
edited weren't visible to the tag uniqueness check when editing other
items in the same set.
Added comments, renamed files, removed cruft.
Stop showing the visualization tag name in the code list. It's
often redundant with the code label, and it's distracting. (We may
want to make this an option so you can Ctrl+F to find a tag.)
Various changes:
- Generally treat visualization sets like long comments and notes
when it comes to defining data region boundaries. (We were doing
this for selections; now we're also doing it for format-as-word
and in the data analyzer when scanning for strings/fill.)
- Clear the visualization cache when the address map is altered.
This is necessary for visualizers that dereference addresses.
- Read the Apple II screen image from a series of addresses rather
than a series of offsets. This allows it to work when the image
is contiguous in memory but split into chunks in the file.
- Put 1 pixel of padding around the images in the main code list,
so they don't blend into the background.
- Remember the last visualizer used, so we can re-use it the next
time the user selects "new".
- Move min-size hack from Loaded to ContentRendered, as it apparently
spoils CenterOwner placement.
Report visualization generation errors through an explicit
IApplication interface, instead of pulling messages out of the
DebugLog stream.
Declare that GetVisGenDescrs() is only called when the plugin is in
the "prepared" state, so that plugins can taylor the set based on
the contents of the file. (This could be used to set min/max on
the "offset" entries, but I want special handling for offsets, so
we might as well set it later.)
Bitmap fonts are a series of (usually) 1x8 bitmaps, which we arrange
into a grid of cells.
Screen images are useful for embedded screens, or for people who want
to display stand-alone image files as disassembly projects.
Various improvements:
- Switched to ReadOnlyDictionary in Visualization to make it clear
that the parameter dictionary should not be modified.
- Added a warning to the Visualization Set editor that appears when
there are no plugins that implement a visualizer.
- Make sure an item is selected in the set editor after edit/remove.
- Replaced the checkerboard background with one that's a little bit
more grey, so it's more distinct from white pixel data.
- Added a new Apple II hi-res color converter whose output more
closely matches KEGS and AppleWin RGB.
- Added VisHiRes.cs to some Apple II system definitions.
- Added some test bitmaps for Apple II hi-res to the test directory.
(These are not part of an automated test.)
Thumbnails are now visible in the main list and in the visualization
set editor. They're generated on first need, and regenerated when
the set of plugins changes.
Added a checkerboard background for the visualization editor bitmap
preview. (It looks all official now.)
The Visualization and Visualization Set editors are now fully
functional. You can create, edit, and rearrange sets, and they're
now stored in the project file.
Implemented Apple II hi-res bitmap conversion. Supports B&W and
color. Uses essentially the same algorithm as CiderPress.
Experimented with displaying non-text items in ListView. I assumed
it would work, since it's the sort of thing WPF is designed to do,
but it's always wise to approach with caution. Visualization Sets
now show a 64x64 button as a placeholder for the eventual thumbnail.
Some things were being flaky, which turned out to be because I
wasn't Prepare()ing the plugins before using them from Edit
Visualization. To make this a deterministic failure I added an
Unprepare() call that tells the plugin that we're all done.
NOTE: this breaks all existing plugins.
Added some rudimentary bitmap creation code. Got a test pattern
generated by the plugin to display in the app. (Most of the time
required for this was spent figuring out how bitmaps are handled
in WPF.)
Got parameter in/out working in EditVisualization dialog. Did some
rearranging in PluginCommon interfaces and data structures. Still
doesn't do anything useful.
Basic infrastructure for taking a list of parameters from a plugin
and turning it into a collection of UI controls, merging in values
from a Visualization object. Doesn't yet do anything useful.
WPF makes the hard things easy and the easy things hard. This was
a hard thing, so it was easy to do (with some helpful sample code).
Yay WPF?
While disassembling some code I found that I wanted the ROM entry
points, but the zero page usage was significantly different and the
ROM labels were distracting. Splitting the symbol file in two was
a possibility, but I'm afraid this will lead to a very large
collection of very small files, and we'll lose any sense of relation
between the ROM entry points and the ZP addresses used to pass
arguments.
Platform symbols have the lowest priority when resolving by address,
but using that to hide the unwanted labels requires creating project
symbols or local variables for things that you might not know what
they do yet. It's possible to hide a platform symbol by adding
another symbol with the same label and an invalid value.
This change formalizes and extends the "hiding" of platform symbols
to full erasure, so that they don't clutter up the symbol table.
This also tightens up the platform symbol parser to only accept
values in the range 0 <= value <= 0x00ffffff (24-bit positive
integers).
An "F8-ROM-nozp" symbol file is now part of the standard set. A
project can include that to erase the zero-page definitions.
(I'm not entirely convinced this is the right approach, so I'm not
doing this treatment on other symbol files... consider this an
experiment. Another approach would be some sort of conditional
inclusion, or perhaps erase-by-tag, but that requires some UI work
in the app to define what you want included or excluded.)
- Allow user to "unnecessarily" set an address override. This is
a handy thing to do when dealing with code that does a lot of
relocations.
- Moved "save needed" text to the end of the title string.
- Updated F8-ROM syms.
- Added ProDOS 8 error code constants
Mark the "info" window as read-only.
When the project closes, clear the contents of the Symbols and
Notes windows.
Clarify some Apple II I/O definitions.
Sort of silly to have every handler immediately pull the operand out
of the file data. (This is arguably less efficient, since we now
have to serialize the argument across the AppDomain boundary, but
we should be okay spending a few extra nanoseconds here.)
We were failing to update properly when a label changed if the label
was one that a plugin cared about. The problem is that a label
add/remove operation skips the code analysis, and a label edit skips
everything but the display update. Plugins only run during the code
analysis pass, so changes weren't being reflected in the display
list until something caused it to refresh.
The solution is to ask the plugin if the label being changed is one
that it cares about. This allows the plugin to use the same
wildcard-match logic that it uses elsewhere.
For efficiency, and to reduce clutter in plugins that don't care
about symbols, a new interface class has been created to handle the
"here are the symbols" call and the "do you care about this label"
call.
The program in Examples/Scripts has been updated to show a very
simple single-call plugin and a slightly more complex multi-call
plugin.
Early data sheets listed BRK as one byte, but RTI after a BRK skips
the following byte, effectively making BRK a 2-byte instruction.
Sometimes, such as when diassembling Apple /// SOS code, it's handy
to treat it that way explicitly.
This change makes two-byte BRKs optional, controlled by a checkbox
in the project settings. In the system definitions it defaults to
true for Apple ///, false for all others.
ACME doesn't allow BRK to have an arg, and cc65 only allows it for
65816 code (?), so it's emitted as a hex blob for those assemblers.
Anyone wishing to target those assemblers should stick to 1-byte mode.
Extension scripts have to switch between formatting one byte of
inline data and formatting an instruction with a one-byte operand.
A helper function has been added to the plugin Util class.
To get some regression test coverage, 2022-extension-scripts has
been configured to use two-byte BRK.
Also, added/corrected some SOS constants.
See also issue #44.
If it's a known function, apply basic numeric formatting to the
various fields. Primarily of value for the pathname and buffer
parameters, which are formatted as addresses.
Also, enable horizontal scrolling in the generic show-text dialog.
The current AddressMap is now passed into the plugin manager, which
wraps it in an AddressTranslate object and passes that to the
plugins at Prepare() time. This allows plugins to convert addresses
to offsets, making it possible to format complex structures.
This breaks existing plugins.
If we have a bug, or somebody edits the project file manually, we
can end up with a very wrong string, such as a null-terminated
string that isn't, or a DCI string that has a mix of high and low
ASCII from start to finish. We now check all incoming strings for
validity, and discard any that fail the test. The verification
code is shared with the extension script inline data formatter.
Also, added a comment to an F8-ROM symbol I stumbled over.
