Added a static Debugger::debugger() method, which is sort of a hack,
but is very useful when some class needs access to the debugger
and we don't want to pass the debugger object through dozens of
c'tors. Besides, there's only ever one instantiation of the
debugger anyway.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@640 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
but at least Stella doesn't crash. I have to implement dialog
resizing to take care of the remaining problem (vs. just deleting
and re-creating the debugger dialog).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@639 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
and call evaluate() on it repeatedly... Ladies and gentlemen, we have a
compiler!
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@636 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Yes folks, it's coming, and if everything works out it will be the
fastest implementation yet for any Atari 2600 debugger.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@634 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
label => address mappings. It should be faster than the linear search,
and it's a damn sight cleaner. Still TODO is to restore the case-insensitive
string matching from the original version.
Changed a few EquateList methods that used to return char*, so they now
return string or string&. Changed other classes that call them so they
work with the new return types.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@633 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
instruction at a time, and before each instruction it disassembles the
next instruction. If the disassembly result contains the string arg,
stop executing and return.
This let us say things like "runto STA" to run until the next STA
instruction, or "runto LABEL", or whatever else. It does *not* use the
breakpoint nor trap mechanisms.
Unfortunately, as written, Debugger::disassemble is *slow*... "runto"
takes about 40-50 seconds to execute one frames' worth of 6502
instructions on an Athlon 1200. Also, as written, it's uninterruptible:
while it's slowly doing its thing, the SDL main loop isn't running,
so you can't even close the Stella window to get out...
Also, it would be nice to be able to tell "runto" which field you want
to search (address label, instruction name, operand). Splitting it out
this way could also make it faster: instead of doing a full disassemble
and searching it, we could have "runto LABEL" evaluate the label and
just stop when the PC equals the target (would be almost as fast as
just using a breakpoint). We may create separate commands for this:
"runtoaddr", "runtoinstr"...?
Being able to say "run until the next RTS instruction" is a lot more
expressive than having to disassemble until you find the RTS, set a
breakpoint after it, then "run", then remove the breakpoint...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@632 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
different ways, and hence sometimes certain things were done
and not at other times. Now there's only one way to enter/exit
the debugger. This fixes the problem of locking/unlocking the
data bus in debugger mode; a lock is done on entry and released
on exit.
The above change may expose other bugs. I haven't tested
extensively, but if something has stopped working it's because
it relied on buggy code.
Cleaned up the Debugger class definition a little, adding some
documentation and making certain things private when they didn't
absolutely need to be public.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@631 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
System when it uses peek() to examine memory/TIA/etc.
I'm not entirely sure I put a lockDataBus() call where it will get
executed when the user presses ` to enter the debugger: I put it in
Debugger::start() (does everything call this, or does EventHandler do
something else?), and again in Debugger::state() (which gets called to
build every prompt string).
There are unlockDataBus() calls everywhere in the Debugger where we
execute 6502 code, including Debugger::quit(). Does the EventHandler
call quit() when it exits the debugger (if the user presses ` I mean)?
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@630 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
so it's just one test (search for STA $3E in the image) to distinguish
between the two. I still only have 3 3E images (notBD PAL and NTSC,
and Armin's test cart), but all 3 are detected, at least. Autodetection
isn't as important in Stella as it is in some other emulators, due to
the stella.pro database, so I won't try to make this too smart for its
own good...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@629 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
if this is needed for anything other than 3E type, but since it
doesn't cause any overhead, I went ahead and did it anyway (after
reading your messages on Stella list).
Please test to make sure it still works, but I don't think there'll
be any problems.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@628 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
the TIA. For 3E, this means game authors don't need to access the TIA
through a mirror (and there's no reason they should on real hardware,
either). It also means Armin's test cart image works.
3F ROMs still need to use a mirror: poking to $00-$2C writes to the
TIA *and* switches banks, which is not that you'd want to do. Stella's
behaviour now matches a real Tigervision 3F cart, for what it's worth.
Unfortunately I had to do something nasty to allow the Cart classes to
directly access the TIA: see System.hxx and System.cxx (search for
the tiaPoke() method.)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@627 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
CpuDebug. This is similar to the last commit, which moved all RAM
stuff to RamDebug.
Removed D6502, since it's functionality is provided by CpuDebug and is
no longer required.
The only user-visible change is that the CPU registers in CPU tab now
track changes. It may seem like a lot of work to just accomplish that,
but the infrastructure will make it much easier to add similar
functionality to new tabs. Besides, we needed to step back a little
and clean up the codebase.
Still TODO is turn TIADebug into a real DebuggerSystem object, and
finish the TIA tab.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@624 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
I'll be doing small commits after each subsystem is ported, to make sure
I don't do anything too destructive.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@623 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Cart3E::patch() now can patch RAM (before, it would have segfaulted if
you'd tried)
Cart3E constructor now initializes RAM to random junk instead of leaving
it uninitialized (which still means full of junk...)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@621 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
with Andrew Davies' early notBoulderDash demo.
Added entry to stella.pro for the demo
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@619 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
a reimplementation of D6502. So D6502 will disappear soon. The reason
Debugger class has been getting so big is that there was only D6502 defined,
when there should have been also DTia, DRam, etc. The DebuggerSystem
classes are now providing that functionality.
The codebase may be broken over the next few days because of this, but
it's better to do it properly (I get the feeling it may never be fixed if
we don't do it now).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@616 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Debugger class. There will be a subsystem for each GUI debugger tab,
and it will have responsibility for all thing related to that tab,
eliminating a lot of code from Debugger class.
Added RamDebug class, and changed the GUI RAM tab to use the new RamDebug
subsystem. The prompt still uses the old method, which will have to be
fixed. At that point, Debugger::(readRAM, writeRAM, ramChanged) can be
eliminated. If the Debugger ever wants to access RAM related things,
it should refer to RamDebug.
Still TODO is create a CpuDebug subsystem, and turn the current TIADebug
into a real subsystem.
Cleaned up some redundant typedefs (changed AddrList/ValueList to
IntArray). As well, we're moving away from having bspf stuff seeded
throughout the system. Integer values will be stored/passed around as
'int', and truncated where necessary as close to the given method as
possible.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@615 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
even starts, so you can enter the debugger before the first frame is
even drawn. This will be useful for everyone, but I particularly need it
for testing per-scanline TIA update code (which doesn't even exist yet).
I should eventually be able to run "stella -break kernel poker.bin" and
then advance one scanline at a time, watching the first frame get drawn.
Not even close yet :)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@614 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Increased debugger window width to 639 pixels. We've already passed the
512x384 mark, so it's no use restricting width to 512 anymore. Besides,
the extra width will come in handy for the TiaWidget, and maybe the
PromptWidget can now use one less line in the state() display.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@613 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
of RAM in the TIA, but it isn't tied to the TIA yet (so changes have no
effect). I suspect that development on this tab will now proceed quickly,
since I think I've found a way to lay everything out in one tab.
Removed the 2 second delay from configure when an invalid option is
given. There's no need to delay; printing an error is sufficient.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@612 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
for 2 seconds instead of silently ignoring wrong options. This seems
like a good compromise to me (I've typed "./configure --disable-opengl"
about 50 times now, and of course it doesn't work because it's supposed
to say "--disable-gl")
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@611 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
system, and if that doesn't work for someone, we'll fix it at that level.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@610 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
are part of the class itself. That means all DataGridWidgets (currently
RAM contents and CPU registers) get access to the key shortcuts.
Modified DataGridWidget to accept the number of bits in its cells, and
made sure the above listed operations are restricted to that number
of bits. That means when we add DataGridWidgets for Tia stuff with
weird bit lengths, changing data will work correctly.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@609 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
has sent a signal (required when there are more than one of the same type of
widget in a widget/container).
Still TODO is modify each handleCommand() method that cares about 'id' to
actually detect and act on it.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@608 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
a row/column is reached, it goes to the next row/column. The reason for
this will become apparent over the next day or so.
Still TODO is revamp the base widget to accept and return an identifier
for which widget it is, since every widget/dialog in the debugger
currently assumes that there's only one type of each widget (so if there
are two DataGridWidgets, the returned signal doesn't know which one
to use). Sorry if that sounds confusing ;)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@607 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
time to finish.
Changed colors of modified cells in DataGridWidget. They're now much
easier to see.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@606 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Inv, Neg, etc. buttons on the RAM tab. Also added Undo and Revert buttons
to the RAM tab. Undo undoes your last change only (and does not undo an
undo). Revert reverts RAM to the state it was in when the user entered
the RAM tab. These buttons are disabled when they're not useful.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@605 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
about. No use in quitting if the option wouldn't have had any effect
anyway.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@603 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Booleans in "tia" output are now +FOO or -foo (UPPERCASE is set, lower
is clear, plus there's a + or - in front).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@601 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Currently, entering the debugger turns off all the joystick and button
inputs, so we're stuck showing "(no directions)" for the sticks. This
needs a change in EventHandler to fix (assuming it can even be done).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@600 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
is in the current number base except the binary graphics data. Audio frequency
is shown both as AUDFx value and frequency in Hz. Boolean flags are now
shown with a prefixed + for true or - for false (e.g. "-delay" for a player
if it's not delayed or "+delay" if it is).
There are still a few TIA internal state values that should be displayed:
delayed graphics data and color clocks at which RESxx was strobed.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@599 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
up in the RamWidget. FrameBuffer::advance() now advances all frames and
then returns, instead of setting a flag to advance and then return
immediately (RAM wasn't being updated until the frames where advanced,
but by that point we'd returned from the method).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@596 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
CpuWidget automatically gets this support as well.
Still TODO is revamp the loadConfig() method so that updates are only made
when absolutely necessary.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@595 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
by making use of the Debugger::ramChanged() method. Still TODO is
actually 'draw' those changes.
Cleaned up Array typedefs, placing them in the Array class. Also
removed StringArray typedef, since there's already a StringList
class that does exactly the same thing.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@594 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
per line are displayed. There's room for more, but not for 8... and I
expect each line to contain a power-of-two's worth of bytes for some
reason (I tried 6 bytes/line, it was somehow jarring).
Added bool Debugger::ramChanged(uInt 8 offset) method for the GUI RAM tab
to use.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@593 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
stephena