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.)
Created the "all ops" tests for W65C02. Filled in enough of the
necessary infrastructure to be able to create the project and
disassemble the file, though we're not yet handling the instructions
correctly.
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.
The handful of 6502-based Atari coin-op systems were very different
from each other, so having a dedicated entry doesn't make sense.
Also, enable word-wrap in the New Project text box that holds the
system description.
We're generating names that nothing links to. The names aren't
guaranteed unique, so they're of dubious value anyway.
Also, fixed the Atari 2600 visualizer script filename in sys defs.
First swing at a visualizer for Atari 2600 sprites and playfields.
Won't necessarily present an accurate view of what is displayed on
screen, but should provide a reasonable shape for data stored in
the obvious way.
The Adventure playfields looked squashed, so I added a simple row
duplication value.
Also, minor improvements to visualizers generally:
- Throw an exception, rather than an Assert, in VisBitmap8 when the
arguments are bad.
- Show the exception in the Visualization Edit dialog.
- If generation fails and we don't have an error message, show a
generic "stuff be broke" string.
- Set focus on OK button in Visualization Set Edit after editing,
so you can hit Enter twice after renaming a tag.
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.)
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.
Instead of providing no-op CheckJsr/CheckJsl, plugins now declare
which calls they support by defining interfaces on the plugin class.
I added a CheckBrk call for code like Apple /// SOS calls, which
use BRK as an OS call mechanism. The formatting doesn't work quite
right yet because I've been treating BRK as a two-byte instruction.
Hardly anything else does, and I think it's time I stopped (but not
in this commit).
Note: THIS BREAKS ALL PLUGINS that use the inline JSR/JSL feature,
which is pretty much all of them.
The instruction operand editor and data operand editor are very
different, but there's no need to impose that distinction on the
user. They want to edit the operand either way. We now provide a
single "edit operand" menu item, and open the appropriate dialog
based on what they have selected.
This uses Ctrl+O as the keyboard shortcut, stealing it from
File > Open.
(issue #11)
If set, the first word of the file is used to set the load address.
The initial code entry hint is placed at offset +000002 instead of
the start of the file.
Set it to true for the C64 system definition.
(issue #23)
