Re: AppleWin 1.13.2.0 Beta

Chris Morse wrote:
Michael wrote:
Great work mike! I'm really glad to see the debugger side get such
good attention.

Thx. There are just _so_ many neat things to add to it, that makes my
life, and others easier. Hopefully the other devs won't mention the
additional goodies that will be in the next release. ;-)


I was reading another post of yours about disassembling
games to see what makes them tick. I've been interested in the same
thing; my first target being Lode Runner. I recall poking around at it
back in the 80's, and there was a considerable amount of code (seemed
like 12 or 16k worth) for rendering that circular screen swipe. At one
point I even had that code ripped out and usable in my own program.
Hehh..

I always wanted to locate and disassemble that section of code. Too
busy hacking other games. LOL.

The next iteration of the debugger will make it easier in dissecting
the game.


Anyhow, I have an (incomplete) idea for the debugger. I was thinking
about the idea of having an array for profiling code execution.

We already have some support in for profiling (since 1.12.8.0) Looks
like it is not officially documented ATM, sorry about that -- I've
added a stub in the Tutorial so it won't be missed in the future.
i.e.
F7
PROFILE
G
F7
PROFILE LIST
PROFILE SAVE


The array, 64k (elements) in size, would profile the 6502 instructions
executed. Each element of the array would correspond to a byte of
memory and keeps track of the number of times each byte was accessed (and how,
as an opcode/instruction or as data.)

I like this idea...
ProfileAccessInfo_t ProfileMemory[ _64K ]

where ProfileAccessInfo_t is access info
int nRead
int nWrite
int nFlags
0 = n/a
1 = data
2 = code

We won't be able to log every addressing mode if they refer to the same
memory location, but we will be able to catch the memory access.
i.e.
STA $2000
0:00 20
X=0
STA ($00,X)

We have these tables already:
256 for each opcode
17 for the opmode (addressing mode)

I'm thinking we might want this one too, for comprehensive stats.
int ProfileOpcodeOpmode[ opcode * opmode ]


As far as that's concerned, it should be easy to implement. For
example, the following new commands:

o PR - Profile Reset, resets profile array to zero
PROFILE without any args is reset. (With the next version, you can now
abbreviate commands.)


o PS - Profile Start, enables profiling
I think we'll want to specify different "mode" of profiling.
PROFILE SIMPLE // default
PROFILE MEMORY [READ | WRITE] memory_range
i.e.
PROFILE MEM W 2000:3FFF

o PH - Profile Stop/Half, disables profiling
? PD - Profile Dump, dumps profile to file (? probably not useful)
Actually it is, since we use that info to tell us what opcodes
emulation to optimize, based on usage. ;-) PROFILE SAVE can be updated
to dump extra info.


o PV - Profile Viewer, displays profile grapihcally

Ideally, though, and this is sort of the 'incomplete' section of my
idea, is a built-in profile data viewer. My initial idea is a
graphical
window/bitmap, say 256x256, that displays a color-coded version of the
profile data. For example, black for un-accessed memory, 0-255 Red
component for opcodes/instructions and a 0-255 Green component for
operands or data. In this "profile window" bitmap, clicking on a pixel
would then put the debugger display at the corresponding memory
location.

Now that is a _neat_ idea. Sort of like the lag-o-meter in quake, but
applied to memory coverage ;-)

The graphical viewer would have 1 pixel correspond to 1 byte of memory.

I like the color idea! I would touch them up, with options to allow
what to display.
PROFILE VIEW [Read] [Write] [Code] [Data]
G = Read (data)
Y = Code (code)
R = Write (data)


It's an idea I've had for a little while, in my quest to help me
"diagnose" running programs. For example, in Lode Runner, how is the
player bitmap rendered? Is it copied from a bitmap in memory? Drawn by
code? Where is that code? and/or where's the bitmap coming from?

I was able to locate the player bitmaps, years ago, but having some
sort of tool to automate this independently of the game, would be
really cool.


Another idea I can think of for the profiler might be to allow the user
to profile any code that WRITES to memory in the $2000-$2FFF range.

This is a really good extension. I only had the basic foundation for
this in the debugger, which isn't working at the moment, but I do have
flags for each instruction:
#define R_ MEM_R
#define _W MEM_W
#define RW MEM_R | MEM_W
#define _S MEM_S
#define im MEM_IM
i.e.
{"BIT", AM_Z , R_}, {"AND", AM_Z , R_}, {"ROL", AM_Z , RW}, {"nop",
0 , 0 }, // 24 .. 27


Then the profile window would show you exactly where *ALL* the code
that writes to the graphic screen is located. Then you can manually
investigate each section/area. I think that would be very handy when
poking around game code.

Definately.


Again, with a game like Lode Runner you should be able to locate
sections of code you're interested in (trying to find) much easier.

I always wanted to add a "jump" feature to the game. You got me
thinking about hacking this in... ;-)


I hope that made at least a little sense. I wonder what you think. Do
you think it would be useful? Maybe a different idea? I'm off my
rocker?

Thx for the _really_ cool idea Chris! You have some really neat stuff.
No time-frame when it will be implemented for the time being, but
we'll see how it goes. I have a few bugs with the debugger that need
to be fixed this week, still have to update the Debugger Tutorial, and
then work on the video rewrite. We'll see if I can slip this in
sometime.. ;-)

Michael

.

Relevant Pages

  • Re: Draw Performance Improvement
    ... >> same bit depth and bit masks as the primary display driver. ... >> and not the display card's video memory. ... For the display hardware to ... >> do is profile and see where the cycles are actually going. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: SmartHeap Library
    ... We have created her a new profile and a new sign on ... SmartHeap memory management library. ... Have you tried creating a new account ... Most likely she has unique program settings and ...
    (microsoft.public.windows.terminal_services)
  • RE: x86, ptrace: support for branch trace store(BTS)
    ... Is there already a per-task memory limit? ... buffer into a file - whether this is the real buffer or a bigger virtual ... The small profile cases would already be covered with a reasonably big ... Independent of how many buffers we have, we need to offer overflow ...
    (Linux-Kernel)
  • Re: Roamin Profiles Problem
    ... - Windows cannot load the locally stored profile. ... error include insufficient security rights or a corrupt local profile. ... When restart the server the problem returns but not immediately. ... never reach the top of processor or Memory. ...
    (microsoft.public.windows.terminal_services)
  • Re: AppleWin 1.13.2.0 Beta
    ... I have an idea for the debugger. ... PR - Profile Reset, ... For example, black for un-accessed memory, 0-255 Red ... In this "profile window" bitmap, ...
    (comp.emulators.apple2)