• AppleWin debugger visibility of aux mem

    From Andrew Roughan@21:1/5 to All on Sun Jul 18 14:35:58 2021
    I have been writing and debugging software that runs in auxmem and have had some challenges with using AppleWin for this.

    Perhaps these have answers or perhaps they need to be upgraded to feature requests. I’m new to AppleWin so I don’t know.

    The AppleWin debugger memory help section does not mention LC or Aux memory
    at all. This can potentially use some improvement for those who start
    looking there (like I did).

    On another forum someone mentioned OUT 3. I’m not sure what this is meant
    to do but I was able to see content of (some)
    auxmem after using it.

    At one point my code crashed at (aux)FF85 but I was not able to see any
    content there within the debugger. The monitor rom content was always
    displayed no matter what I tried.
    (Yes I understand that it hit a BRK as auxmem up there was not initialised)

    I would have liked to be able to copy memory content results with mouse selection from the debugger data display. It would have saved some
    retyping. Please consider adding copy into the interface.

    I’d be happy to create tickets if necessary.

    Regards
    Andrew

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael J. Mahon@21:1/5 to Andrew Roughan on Sun Jul 18 10:14:13 2021
    Andrew Roughan <no_email@invalid.invalid> wrote:

    I have been writing and debugging software that runs in auxmem and have had some challenges with using AppleWin for this.

    Perhaps these have answers or perhaps they need to be upgraded to feature requests. I’m new to AppleWin so I don’t know.

    The AppleWin debugger memory help section does not mention LC or Aux memory at all. This can potentially use some improvement for those who start
    looking there (like I did).

    On another forum someone mentioned OUT 3. I’m not sure what this is meant to do but I was able to see content of (some)
    auxmem after using it.

    At one point my code crashed at (aux)FF85 but I was not able to see any content there within the debugger. The monitor rom content was always displayed no matter what I tried.
    (Yes I understand that it hit a BRK as auxmem up there was not initialised)

    I would have liked to be able to copy memory content results with mouse selection from the debugger data display. It would have saved some
    retyping. Please consider adding copy into the interface.

    I’d be happy to create tickets if necessary.

    Regards
    Andrew




    I had a similar problem a few months ago, and I was told, and confirmed,
    that AppleWin’s debugger and its memory windows display the memory bank
    that is currently switched in.

    Since I had vectors that contained appropriate bank switching instructions,
    I just single-stepped them to gain visibility over the bank I wanted to
    see.

    --
    -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael AppleWin Debugger Dev@21:1/5 to Andrew Roughan on Mon Jul 19 06:20:09 2021
    On Sunday, July 18, 2021 at 7:35:59 AM UTC-7, Andrew Roughan wrote:
    I have been writing and debugging software that runs in auxmem and have had some challenges with using AppleWin for this.

    Perhaps these have answers or perhaps they need to be upgraded to feature requests. I’m new to AppleWin so I don’t know.

    Welcome to the debugger!

    Some things are easy, some things are not documented as well as they should be, and some things are still difficult that could be easier. Please post feedback if something is incomplete/crap/hard-to-use because we will probably agree with you that a FR
    needs to be added.

    The AppleWin debugger memory help section does not mention LC or Aux memory at all. This can potentially use some improvement for those who start looking there (like I did).

    If you search the help manual for "Language Card" or "LC" or "aux" you will find they are actually are mentioned, albeit not in a clear fashion, tucked away in a Soft-switches" section. Sorry that this information was difficult to find. Would adding a
    new "Quick overview of Apple Memory" section help?

    In the help if you navigate to "Debugger > Debugger Screen Layout > Soft-Switches" you can find a short description about the OUT commands required where it says:

    The next 6 rows describe the current MMU settings and can be interpreted as follows:
    00: $C000 - 80Sto0/1 (inverse indicates state of 80STORE)
    02: $C002-C005: Rm/xWm/x (NB. 'R' is blue and 'W' is red for readability)
    Rm Read from main mem for $0200-$BFFF; Use OUT C002 to enable
    Rx Read from aux mem for $0200-$BFFF; Use OUT C003 to enable
    Wm Write to main mem for $0200-$BFFF; Use OUT C004 to enable
    Wx Write to aux mem for $0200-$BFFF; Use OUT C005 to enable
    0C: $C00C - Col40/80 (inverse indicates state of 80COL)
    0E: $C00E - ASC/MOUS (inverse indicates state of ALTCHARSET)
    80: $C080-C087: B2/M R/W (Language Card Bank2)
    A red 'x' if ALTZP (and Alt Language Card) is set by a write to $C009.
    88: $C088-C08F: B1/M rNN (Language Card Bank1 and RamWorks 64K bank number)
    'B2' or 'B1' is inverse when that LC bank is enabled.
    If 'M' is inverse: ROM is active for reading.
    If 'M' is not inverse: LC2 or LC1 RAM is active.
    If 'W' is inverse: RAM is write enabled.
    If 'W' is not inverse: RAM is write protected.
    'rNN' will appear if a RamWorks 64K bank is active.
    'sNN' will appear if a Saturn 16K bank is active.

    On another forum someone mentioned OUT 3. I’m not sure what this is meant to do but I was able to see content of (some)
    auxmem after using it.

    As you probably know the 6502 CPU lacks dedicated IN/OUT assembly mnemonics -- all I/O is memory mapped (unlike the 8086 which has a dedicated IN and OUT mnemonics.)

    Now normally one would do a read or write from assembly language but since you can't do that from the debugger there are two debugger commands provided instead:

    * IN, and
    * OUT.

    The OUT ## command outputs a byte to the specified $C000 - $C0FF range. Which 256 byte address you need to use depends on what you are trying to do with memory -- which requires knowing the Apple 2 soft switches. When I wrote the manual I made the
    assumption that most people who use the debugger are usually already familiar with bank-switching (on the Apple 2) but looks that assumption is no longer valid.

    To help remember which C0XX address one needs to use for memory I added the bank status to the bottom right of the disassembly window -- the orange numbers refer to the C0XX address and the remaining line shows the current soft switch state.

    For example, you'll have to manually type OUT 80 (or OUT C080) to switch to LC Bank 2. To switch back to ROM type OUT 81 which will bank it back in.

    At one point my code crashed at (aux)FF85 but I was not able to see any content there within the debugger. The monitor rom content was always displayed no matter what I tried.
    (Yes I understand that it hit a BRK as auxmem up there was not initialised)

    Yes, you are correct that OUT 3 (or OUT C003) is the soft-switch that will tell the Apple 2e+ to read from aux. memory instead of main memory.

    You can check the memory bank status by inspecting these lines:

    02:Rm/x Wm/x
    80:B2/M R/W

    If you don't see those lines in the debugger please run version 2.90.6 or later version of the debugger when I added them.

    I would have liked to be able to copy memory content results with mouse selection from the debugger data display. It would have saved some
    retyping. Please consider adding copy into the interface.

    Unfortunately the DATA view is lacking many features, such as the ability to visually edit and mouse selection. Sorry.

    In the mean-time use Ctrl-PrintScreen to copy the entire debugger window as text which you can then paste into another document / application.

    I’d be happy to create tickets if necessary.

    Yes, please create new feature requests (Issues) on GitHub so the team can track them and work on them as needed since I am no longer the only one that works on the debugger. You can raise new features here:
    https://github.com/AppleWin/AppleWin/issues/new

    Thanks!

    Sorry the debugger still has some rough edges. We are slowly working on them!

    m.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From mykel@21:1/5 to All on Sat Aug 14 05:24:21 2021
    On Mon, 19 Jul 2021 06:20:09 -0700, Michael AppleWin Debugger Dev wrote:

    Have y'all considered using Apple2 built in routines for use with aux
    memory?

    IIRC, it is easier to copy text into a buffer in main memory. Once there,
    you can do whatever you want with it and/or move the buffer back where it
    came from. This is the Apple approved method for aux access and helps to eliminate problems with using aux mem.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael AppleWin Debugger Dev@21:1/5 to mykel on Sat Aug 14 12:37:16 2021
    On Friday, August 13, 2021 at 10:24:23 PM UTC-7, mykel wrote:
    Have y'all considered using Apple2 built in routines for use with aux memory?

    Mykel you are misunderstanding the original questions. Andrew's questions are about using AppleWin's debugger -- not how to use use Aux memory.

    How does using AUXMOVE @ $C311 help a user non-destructively VIEW Main / Aux memory and/or the Language Card's RAM memory **while in AppleWin's debugger** ? AUXMOVE also can't be used to access Aux Pages 0 and 1, nor the banked in RAM @ $D000-$DFFF. (
    Page 89 of the Apple //e Technical Reference Manual.)

    While XFER @ $C313 lets you run a program in Main or Aux memory what Aux. routines will let an user set a non-destructive BREAKPOINT in Aux memory? For example if you want to set a breakpoint at Aux $0300 for this (working) code snippet, how will any of
    the Aux (ROM) routines help with RESUMING AFTER the breakpoint without a bunch of manual BRKV $3F0 setup?

    D0:A9 60 8D 05 C0 8D 00 03 8D 03 C0 20 00 03 8D 02 C0 8D 04 C0 60

    In AppleWin's debugger, BPX 300, will set a breakpoint. (It has the advantage/disadvantage that it only looks at the PC address and ignores the memory bank status.) You can single-step through code, inspecting registers and memory, until you discover
    the bug.

    Sooner or later you will want to view the OTHER bank while in the debugger. The OUT command lets you do that. As long you restore the bank state you can continue running code as if nothing happened.

    m.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From mykel@21:1/5 to All on Wed Aug 18 13:40:16 2021
    Yeah, my bad. I should have read further back before I open my mouth.
    Someday I am going to learn that.

    Cheers

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)