| AppleWin debugger visibility of aux mem [message #410058] |
Sun, 18 July 2021 10:35  |
|
|
Originally posted by: Andrew Roughan
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
|
|
|
|
| Re: AppleWin debugger visibility of aux mem [message #410060 is a reply to message #410058] |
Sun, 18 July 2021 11:14  |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: AppleWin debugger visibility of aux mem [message #410089 is a reply to message #410058] |
Mon, 19 July 2021 09:20 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: AppleWin debugger visibility of aux mem [message #410508 is a reply to message #410089] |
Sat, 14 August 2021 01:24 |
|
|
Originally posted by: mykel
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.
|
|
|
|
| Re: AppleWin debugger visibility of aux mem [message #410509 is a reply to message #410508] |
Sat, 14 August 2021 15:37 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
