Re: AppleWin Debugger & AppleWin Ports

Hey Blurry

This is _excellent_ feedback! I really appreciate your honesty &
diplomacy.
i.e. "The debugger sucks here ___"
--> "I find it lacking here ___" :-)


BLuRry wrote:
Well, I don't really believe a debugger would be all that useful for a
small screen real-estate to begin with. I don't even see how the
current debugger would be all that user-friendly on a zarus. If you
added an on-screen cheat popup menu that was seperate from the regular
debugger it might help (mame-style)

That is a good point.


Otherwise, I personally the debugger as a programming tool and not
altogether useful for the average gamer. However, some of the features
you're adding are more "console" type features like bload,bsave,etc.
Would it make sense to keep those restricted to the debugger?

No, because at some point, there is going to be a "real" cheat UI /
interface. :-) I imagine some of functionality will be copied over,
but with a user-friendly interface.


1. Is the current debugger screen "good enough" ?

I find it constraining, actually. My computer has a mouse and I can't
use it to scroll thru code or set breakpoints. More convienent to
point-n-shoot at things.

I agree -- mousewheel support needs to be in. I've gotten so used to
using the keyboard in the debugger, didn't even notice that others
still find the rodent MUCH easier to use.

This point was brought home, after using Mame's debugger. Speaking of
Mame, I think they have a few minor "bugs" / features missing. I don't
see a way to change the starting offset of a disassembly. Also don't
see a way to "load" comments.


I've found that typing "addrG" doesn't really
keep it in debug mode whereas "G" by itself does. Maybe it's a
misunderstanding on my part. All the same, when I get it to trace thru
code it's very helpful.

Hmm, will have to look into that one. It might be a bug.




Implausible side note, of some entertainment value: Since we're dealing
with a very finite machine, it could be fun to have sort of a "sands of
time" mode, where you can jump back in time 5 seconds or so or rewind
the emulator slowly. If you implemented that, it would make the
original prince of persia VERY INTERESTING indeed. ;-) (not that I
don't know how to use the save/load states, but moreso because it would
be nice to trace backwards through the executed code when I realize
I've gone too far in a trace session)

Yes, I've noticed the same thing. You don't always remember to save
the current state, so you're forced to reload from a state "too far"
back.

Funny enough, I was playing PoP Sand of Time 2 months ago, and you
know, that's a pretty cool idea.

This is actually doable. We could allocate a few meg "delta" buffer.
We would only need to keep track of the changes
1) What Changed
2) Old Value
3) New Value

i.e.
800: A9 03 // RegA: 00 -> 03
802: 8D FF 1F // Mem: $1FFF:00 -> 03
805: 4C 01 09 // RegPC:$0805 -> $0901

The only bit of pain, would be having to keep track of the
soft-switches.



2. What are the common operations you are using the debugger for?

Code traces, breakpoints, loading binaries directly into memory to
bypass disk images. And trying to cheat at games that have pushed my
sanity past the brink of forgiveness. :-D

So it looks like we have most of the functionality in, just need a
better UI.


3. What do you wish was faster to do in it?

macros. it has a lot of functionality, but if it had user-definable
macros (maybe with assignable hotkeys like you have with space bar for
tracing code) I think I could manage to set it up in a way I'd feel is
more familiar and comfortable.

I agree. I've played a little with the macros / expression support in
Mame. VERY cool sttuff, that we "need." :-) I've been making notes.

I've been wanting custom hotkeys for a while, its just been low
priority. We really need a dialog to configure them.



there are a lot of abbreviated commands
and the online help isn't very helpful (and the help file itself is
very out of date, so if I'm away from the internets I'm stuck guessing
how things work, which is uncomfortable) -- if these things were
configurable, the average use could just rename the command set to
something more suited to their style or chain a few common expressions
together (similar to your script support, except more of a script
library so to speak, where scripts/macros could accept one or a few
parameters as input)

OK, I'll try to clean up the help, and add more examples. I first
need to change the info panel to have a "smarter" display -- only show
the current useful info, instead of taking up "dead" white-space.
After that we can have default to a full width console. That would give
better readability.

Agreed. Macros with arguments/paramenters looks like the way to go.
Blurry, I imagine you are wanting macro support something like this?

sym life = $2000
macro Life() { printf "Life: %x", life }
macro Mac() { printf "Add: %x Mul: %x", ($1+$2), ($1 * 2) }

Mac(12,34)
Add: 03A8 Mul: 0046

bp 804 Life()


4. What type of data do you (or wish you could) view the most? code?
data? source? hex dumps? ascii dumps? soft switches?

Mostly code and data dumps. The limit of 5 break points is a bit
constraining, imho.

Agreed. It's a visual organization problem, not a technical one.
Looks like cleaning up the UI is becoming important.


Also, support for browsing code/memory in
alternate memory banks would be extremely helpful since there's some
*** games that like to shove the more interesting bits in the aux
ram where you can't find it easily.

Looks like there needs to be a "bank #" command, with aliases "main",
"aux".
All commands that effect memory then should use the "current" bank.


Kegs: debugger is old-school "gdb"
No need to emulate that one, eh?

The only thing I saw interesting was that you could dump some of the IO
devices. But since most (all?) of our devices are working, don't see
the need to go there. Maybe when SCC is added or $C800 bank switching.


As you can tell, I'm very impressed with MAME. Which means that
AppleWin's debugger will be getting better in the future ;-)
All your work is very much appreciated over here behind this keyboard.
Those features are getting used.

The more people use it, and give ides, the better it gets for everyone.
:-) I can't believe no one implemented a memory text search feature
until now!


Anyways, back to updating the debugger docs. (The debugger output
window should almost be a HTML rendering window, then I could just
embed & hyper-link it in place.)

Good luck. Is there any particular image you want to see rendered in a
dhr 140x192 68-color mode?

You thinking about 'skinning" / theming the debugger window? LOL.
Come to think of it, the classic RGB color triangle would be cool to
see. ;-)


Great comments Blurry!


Debugger Wishlist Summary:
- Better UI -- lot of current "dead" or limited space
- Mouse support
- Better Help
- Banked memory support
- Advanced features: macros with arguments/parameters, better output
options

Michael

.

Loading