One more tab completion fix: made it work when the character before the
label wasn't a space (e.g. "pr *w" now completes to "pr *WSYNC")
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@562 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
name, description, argument count & types, and a method pointer to
actually execute the command. Instance method pointers in C++ are even
more annoying that function pointers in C...
The actual parser (the run() and getArgs()) methods don't use the new
stuff, so the actual operation of the debugger is unchanged.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@561 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Also, minimum length command line to attempt label completion is now 2.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@560 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
have labels "food" and "foobar", and no others starting with "f", and you
type "pr f<TAB>", it will show you both of them, then leave your prompt
looking like "pr foo" with the cursor after the 2nd "o".
Differences from bash:
- In case of multiple completions, bash's default behaviour requires you
to press Tab twice to see them. We only need one Tab. bash can actually
be configured to only need one Tab, too.
- We don't beep. Ever.
- We're case-insensitive. bash is case-sensitive by default, though it
can be configured to be insensitive.
There's one remaining bug in the completion: when we get to the bottom of
the scroll buffer, and the buffer is full (e.g. when the scroll bar handle
is at its minimum size), *and* there's only one possible completion, the
console prints a new blank line after the new (completed) prompt.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@559 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
DebuggerParser flag-setting commands now take one optional argument, to
support the above.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@557 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
want to navigate with the TAB key will actually receive the key (ie, it
won't be swallowed).
Updated PromptWidget to use the TAB key for command completion (Escape
is still used as well).
Added 'Alt t' and 'Alt s' for 'Trace' and 'Step' (respectively) to the
debugger area. These keys are accessible while in any tab, since the
buttons (and associated actions) don't belong to any particular tab.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@554 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
between widgets, I used Escape as the completion key. It's almost working
correctly, but the implementation should be cleaned up.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@552 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
instead of editing values, you toggle values.
Implemented the processor status register as a ToggleBitWidget, since most
people are more familiar with the separate bits (vs. the actual value of the
byte).
Currently, the toggle signal is sent to the CpuWidget, but the register
itself isn't changed. Brian, I only see toggleX() methods for 5 of the
bits, but there are 7 used. Is that intentional, because if the other two
aren't meant to be used, I need to remove the visual cue that they're
being toggled.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@551 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
updates are actually two separate things (and often done independently).
Previously, the only overlay was the menu, and since this was always drawn
over the TIA, updating one or the other was the same thing.
Now, the debugger area can be updated without affecting the TIA, since
technically it isn't really an overlay (it doesn't sit on top of the TIA).
There are still some TODO's wrt using dirty rectangles instead of full
updates, but at least the full updates are now restricted to just the
overlay area.
Fixed multiple frame step in the PromptWidget by changing
FrameBuffer::advance() to advance a given number of frames.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@550 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
PromptWidget gets reset, but not the Debugger itself, so any breaks,
traps, or watches are still there (though watches might depend on
symbols that aren't defined in the newly-loaded file).
When reloading, we do NOT check to see whether the ROM has changed.
This is deliberate: the user might leave the debugger open while he
assembles a new version of his game (I probably would).
TODO: reload symbol file if it doesn't get autoloaded the first time
TODO: don't reset the prompt history on reload
TODO: after the symbol file's loaded, clear any watches that are no
longer valid (e.g. symbol not defined any more)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@549 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
least 6 months now. This shouldn't affect anyone running Stella on a
CPU faster than a pentium-166 or -200 anyway.
Implemented a few new debugger commands: "listtraps", "saveses", "savesym",
"undef", and renamed "label" to "define"... See the console help for
details.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@546 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
than 24 characters. Thanks to Rich Boniface for pointing out the bug.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@544 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Added decimal, binary, and label fields to the RamWidget, which contain
values for the currently selected cell.
Added label, current instruction, cycle count, and status (breakpoint or
trap set) fields to the CpuWidget.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@543 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
occur in libraries, so there's not much I can do about those.
Eliminated memory leaks in DebuggerParser by using the GUI::Array class.
This is basically a dynamically sized array implementation. As a result,
there's no longer a hardcoded limit on the # of arguments or watches.
Brian, this new array class is a bit different than raw arrays in the
following ways:
1) You add to it with push_back(). You *can* add to it with index
notation, but it will assert and exit if you attempt to walk past the
end of it.
2) Because it's dynamically sized, you can't assume it has 100
elements (or even 1 element). That's why push_back() should be used
for assignment, unless you check the bound of the index first.
2) It has a size() method, so you always know how far to walk it.
3) You can erase all items with clear().
4) It makes use of templates, so is quite fast.
5) The syntax is close to STL containers. so when we eventually
move to a faster container (hashmap, etc), minimal syntax changes
will be required.
6) And finally, it frees you from having to deal with memory issues
(new/delete or malloc/free).
Have a look at gui/Array.hxx (which probably should be moved to
common/Array.hxx at some point).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@541 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Fixed some memory leaks in EquateList, and moved to using a dynamic array.
This greatly simplifies the code and abstracts away all new/delete
operations. More cleanup can still be done, since the symfile no longer has
to be scanned for # of lines. Still TODO is similar code for the watchlist
stuff, so all memleaks can be eliminated.
Changed launcher so that if Stella is started with no romdir specified
(maybe first time it's been used), the launcher options are shown so
you can select the romdir. Thanks to Brad for the advice.
Updated LauncherOptionsDialog to send a signal when a romdir has been
set. When that happens, the launcher automatically reloads the rom listing.
Again, thanks to Brad for the advice.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@539 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Unfortunately, there's no way to trap a memory access before it happens.
Unlike breakpoints, traps can occur in mid-instruction. We can't stop
the 6502 in mid-instruction, and wouldn't want to if we could (for one
thing there's no way to continue from that point). This means that, when
you hit a trap, the current instruction is the one *after* the one that
triggered the trap. (This is different from a breakpoint: when you hit
a breakpoint, the current instruction will be the one at the breakpoint,
which hasn't executed yet).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@538 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
trap, the PC keeps getting reset to the start of the frame. FYI,
traps are like breakpoints, only they trigger on any access of the
trap location (e.g. loading data from it, rather than executing it
as a breakpoint).
Fixed two nasty bugs:
1. Debugger::disassemble() was printing hex bytes from the wrong address.
This is because I used readRAM(), which wants a parameter of 0-127, and
reads only from RAM. I *should* have been using peek(), which takes a
16-bit address. In fact, readRAM() is only for the GUI.
2. D6502::disassemble() was printing wrong operands in zero,x and
zero,y addressing modes, due to me passing a wrong number of places
(and thus creating a wrong format string).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@537 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
evaluated and printed before each prompt. Since they're evaluated at
print-time, you can say e.g. "watch a" or "watch *myCounter" and it'll
do what you want.
Added "dump" command. This dumps any address you give it, not just RAM,
and it respects the current base setting (bin, dec, hex). Actually I may
rename the "ram" command to "mem" and allow it to work on non-RAM, and
merge the "dump" command with that.
The debugger state() now respects the default base (the registers are
printed in whatever base the user has selected with the "base" command).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@535 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Added PC, SP, A, X, Y registers to the CpuWidget. These registers
can now be changed and viewed while stepping/tracing.
Still TODO is add a ToggleBitWidget to enable toggling of the
individual bits in the Processor Flag register.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@534 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Renamed ByteGridWidget to DataGridWidget, because it can be used to accept data
other than bytes (also words).
Further work on making the GUI use whichever base you set as default. This
one seems to be a hard nut to crack.
Changed behaviour of '-debugheight' to specify the number of lines to use
for the debugging area, vs the absolute pixels to use. So '-debugheight 20'
would make the debugger be 20 lines tall (in the PromptWidget). The minimum
height is now 15 lines, and all GUI elements will be drawn according to this.
Still TODO is get the 'height' command to work in the debugger.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@533 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
which defaults to kBASE_DEFAULT (which means to use the DebuggerParser's
current input base, set with the "base" command).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@532 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Added -debugheight command line option. The height may not be set to
anything below 383 (which is the default).
Attempted to implement a "height" command in the prompt, but either I'm
doing something wrong (most likely), or the debugger can't be resized
after it's started.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@531 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
another class. Also added decimal support, plus default base support. As
a side benefit, there's much better syntax checking.
Also you can now do a word-pointer dereference with "@address". This
works just like "*address" except that it returns a 16-bit value.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@529 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
They work just like the ones in DASM: "<1234" is "34" and ">1234" is "12".
They can of course be used with labels, and they can be prefixed with "*"
for dereference.
Implemented binary input in CLI. Like DASM: prefix with "%" to treat
your argument as binary. "%10101010" means hex "ff". Can be stacked with
other prefixes.
Stacking order of prefixes is important. "*" must come first, if present.
Then ">" or "<" if present (but not both!). Then "%" if present. Currently
there's no real error checking for this.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@528 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
location 80 to the contents of the X register by saying "ram 80 x". This
also means that there's a small conflict: if you're inputting the value
0x0a (decimal 10), you need to either say "0a" or "A". Otherwise the
parser thinks you're talking about the "a" register instead of the hex
number "a".
Added dereference operator to arg processing. This works the same way as
in C: you prefix a "*" to an argument. So "80" means a literal hex 80,
as before, but you can say "*80" to mean "the memory location pointed to
by location 80"... this also works with the registers. Example: if the X
register holds the value ff, you can say "*x" and it will be treated as
the value ff. Unlike C, multiple levels of dereference are not supported.
Also, the result of a dereference is always a byte for now.
Added "eval" command to debugger prompt. This evaluates one or more
arguments (which may hex values or a labels, and may have a * in front)
and prints the results in hex, binary, and decimal, along with the label
that has that value, if any.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@527 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
out the M6502's breakPoints, so any speed decrease caused by breakpoint
checking logic should go away after breakpoints are cleared.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@526 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
in RAM tab from "~" to "Neg". ~ is the invert/complement operator in C,
not negation. I thought about using a minus sign, but it's visually too
similar to the -- for decrement...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@523 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
is currently somewhat broken, and I'm thinking this may be related to the
mysterious OpenGL Linux problems as well.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@522 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
code than the current line.
On ROM load, we replace the file extension with .sym and attempt to load
that as a symbol file for the debugger. No harm is done if the file is
missing.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@521 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
buttons to the RamWidget. They operate on the currently selected memory
location.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@520 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
the frame by 1 can be very useful, in that you can change a memory location,
do a frame advance, and then see any results graphically.
Eventually the trace and step will work the same way, and show changes
to the scanline as it's being drawn.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@518 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
of Stella. It defaults to true/on, so if you don't want centering, use
'-center false' on the commandline at least once (or edit the config file).
Some more work on the RamWidget and ByteGridWidget. Entering values in hex
now works correctly, and 128 byte RAM area is now updated.
More work on the automatic updating of the tabs. Tabs are now updated when
debugging mode is entered, or when a new tab is selected.
Shortened the width of the debugging tab area and added an area for commonly
use actions/buttons on the right. Currently it contains 'Step' and 'Trace'
buttons.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@517 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
now: set/clear a breakpoint, clear all breakpoints, list breakpoints
(including labels in the output!). The 6502 no longer gets "stuck" on a
breakpoint if you quit the debugger while the current PC is a breakpoint.
Some work on the prompt console. The CPU state information shouldn't be
stale any more.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@516 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
may not be able to add column labels because we need the vertical space
for buttons. Also, the ByteGrid is now drawn correctly.
Added initial infrastructure for a tab to reload itself, either on command
or when a new tab is selected.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@515 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
urchlay