need the numbers so you can refer to them (e.g. delete them).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@673 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
configure-cross is my temporary work-in-progress of the configure
script, I don't want to replace the real configure script yet because
configure-cross is probably broken :(
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@672 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
must have static versions of all the libraries (like libSDL.a, libz.a,
libpng.a), or else you'll end up with the dynamic version(s) of them... so
you'd have a stella binary that's almost-static.
Also, the only way I could get things to link properly was to include
-lz in the LIBS twice: once before and once after -lpng. Removing either
one causes the link to fail on my Linux box. This could cause issues
for other systems though, am not sure...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@671 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
file named "romfile.stella" in the current directory, it will be run
at startup.
Fixed memory leakage in YaccParser, when there was a parse error.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@669 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Ladies and gentlemen, we have working conditional breakpoints! And they're
*fast*!
The command to use is "breakif". It takes one argument, the condition.
You can use curly braces if you want to include spaces in your arguments
(they don't do anything except help readability).
On the Athlon 2100, I was able to run the emulator at full speed, using
100% of the CPU, with *20* expressions of the form:
breakif a==101||a==102||a==103||a==104||a==105
Around 25 expressions, the game started getting noticeably jerky, but was
still playable. With 1 to 5 expressions, there was *no* noticeable increase
in CPU usage!
Actually, this can probably be improved on: I used gcc 3.2.2 for
this. With 3.3.x or 4.0.x, it should be even faster.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@665 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
command; no argument advances one scanline, else advances given #
of scanlines.
Made some methods in TIA inline. Don't know if this will have any
effect, but we'll try to be as efficient as possible.
Bumped version for the next pending alpha release.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@664 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Added rudimentary error-checking to parser and lexer: we no longer accept
invalid digits. Also fixed bug that kept YaccParser from handling hex
constants correctly.
Still TODO is to provide more friendly error messages.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@663 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
The only slight weirdness is: if you're on frame X, and you hit Frame+1,
the prompt will tell you you're on scanline 262 of frame X. It actually
should probably say you're on scanline 0 of frame X+1. If you do a Scan+1
from that point, it'll say you're on scanline 1 of frame X (still X,
not X+1).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@661 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
advance and frame advance. There are still some issues though.
Specifically, scanline advancing past the end of the frame shouldn't
be allowed, and this is partially causing the problems with frame
'jumping' when doing a scanline advance after a frame advance.
Still TODO is add some visual cue to indicate which scanline is
being drawn, and which onscreen data is 'old' data.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@660 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
except it lets you keep advancing past the end of the frame.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@659 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
getting closer. I can change a color in the TiwWidget, advance a few
scanlines, then do a frame advance. The color changes show up only
after advancing the frame, so obviously TIA::update() is doing
something that TIA::updateScanline() isn't. Brian, any advice on
this one; it seems I don't know as much about the TIA as I
thought :(
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@657 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
at a time. Of course, it doesn't actually do anything yet.
Logically, the algorithm is very simple (or at least I think it is).
I just have to figure out how to execute the 6502 until a scanline
is done. In the process, the internal buffers (and hence the
external FrameBuffer) will be filled with data, and we just do
a FrameBuffer::refreshTIA() to 'see' the changes. The first part
of this is the problem. Any advice Brian??
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@656 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
However, we do leak memory: yyparse() happily allocates Expressions as
it parses, but when it hits a parse error, it doesn't return a valid
pointer to the top of the Expression tree. From what I can tell, the
so-called Expression* result is the int value of the last lexer token
cast to an Expression* (due to yacc's use of a union).
I know how to avoid the leak: we need to keep a vector of Expression
pointers in YaccParser. If there's a parse error, yyerror() can delete
all the Expressions using the vector. If not, we clear the vector (er,
calling .clear() on a vector doesn't delete all its elements, too,
does it?). Every time yacc says "$$ = new WhateverExpression", it also
should vector.push_back($$).
Will implement this tomorrow; am getting tired & flaky.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@655 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
to include spaces in arguments. "print 80" and "print {80}" are equivalent,
but "print 80 + 1" and "print {80 + 1}" are not (the former counts as 3
arguments, the latter only one).
Actually, I haven't tied the YaccParser to getArgs() yet, so both would
still be errors. I still need to fix the segfaults on parse error.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@654 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Semi-fixed a bug: formatFlags was capitalizing the wrong flags. I'm
pretty sure it's because they were being pushed into the BoolArray in
reverse order. I "fixed" formatFlags by having it ignore the BoolArray,
and call my new CpuDebug methods to get the flag states directly.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@653 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
but decided we'd be better off with just one IntMethodExpression class.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@652 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
it, then try changing the A register, then "expr". It should return the
changed value.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@651 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
a convenience: <foo is equivalent to foo&$ff (or foo%$100), and >foo is
equivalent to foo/$100, assuming foo is a 16-bit quantity.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@650 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Changed the % prefix for binary input to \ (backslash). It simplifies
the lexer/parser syntax *greatly*. Might change back at some point.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@649 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
be expanded to pop up a palette when double-clicking on a color,
to visually choose a new one.
Added ColorWidgets for the 4 TIA color registers to TiaWidget.
Since these are tied to a DataGridWidget, a nice side-effect is
being able to press '+' and have all the colors cycle.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@648 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Some work on TIADebug. Change tracking now works for the color
registers. Getting/setting the color registers works (sort of,
since the change doesn't seem to be registering in TIA).
Some work on TiaWidget. Color registers and scanline count are
shown. VSync and VBlank are shown, but can't be changed.
Made CheckboxWidget only emit a signal when interactively
clicking on the checkbox (changing state programmatically no
longer emits the signal). TODO: maybe two signals should be used??
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@647 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
At this point, you should be able to do this:
> define foo 1
> expr foo+1
result: 2
> define foo 2
> expr
result: 3
> undef foo
> expr
result: 0 <-- because undefined labels are treated as -1. Bug?
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@646 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
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
urchlay