It now compiles and runs against the latest controller changes.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1451 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Fixed long-standing bug where debugger mode didn't work for E0 carts.
It seems at some point I refactored a section of code, and the debugger
wasn't being locked before entering it. Hence, bankswitching was
occuring when the debugger attempted to read the emulation state.
Fixed a similar debugger issue for 4A50 support. This might necessitate
a 2.5.1 release ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1450 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Updated docs for impending 2.5 release. I still have to add documentation
for Rom Info and Rom Audit functionality. That's the worst thing with
adding new features; I have to document them :)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1446 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
marked as being incompatible. With each future release, if the format
changes again, we simply update the header. Also, the header encodes the
last version that worked with that format, with 2 bytes per number (ie,
version 2.5, or 2.5.0.0, is encoded as 02050000).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1445 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
that looks roughly the same as the current default but was bigger. Then
it occurred to me to simply modify that font to be twice as large :)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1441 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
was still being used for the next ROM. It makes me wonder how many
people use this feature, since this problem was never reported before.
Some general cleanup of the Debugger API. I generally don't like
pointers, and use (const) references whenever possible.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1440 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
this is a simple mono-spaced font. For a future release, I'd like to get
a nicer proportional font something like the current smaller one.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1439 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
just too cool a feature not to include in the next release ;)
Checked in some updated UI font-aware code. All of the UI's are not
converted yet, but for the next release the only one that really matters
is LauncherDialog.
Added '-launcherfont' commandline argument and associated UI config
to set the size of the font used in the ROM launcher (for now, small
or large). This is useful if you activate the ROM Info and can't
zoom the entire UI by 2x. Previously, this meant the ROM listing font
was very small, but now you can have the launcher in 1x mode with a
larger font *and* the ROM info stuff also visible. More changes are
coming in a future release, so this will have to do for now.
Reworked UIDialog to contain tabs, since the options were starting to
become unwieldy.
This pretty much ties up the last remaining items for this release,
so after a little testing and updating the manual, it's time for 2.5.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1438 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
useful until I get the UI fixed wrt font sizing, and fix the issue where
you need to save snapshots in 1x mode. All that leads to extra work that
can't be released in pieces, and I want to get this release out *now*.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1436 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
into the Paddles class.
Removed '-paddles' commandline argument. You can still change the paddle
that the mouse is emulating from the UI or with Ctrl 0..3, but its no
longer a setting that can be saved.
Added message to LauncherDialog when a ROM is invalid and can't be loaded.
Reworked the GameInfoDialog a little wrt swapping console ports. Behind
the scenes, the Console.SwapPorts property is still being used, but the
UI is now more consistent (you no longer select the left and right
controller, but the controllers for players 0 and 1, and which port
they'll be plugged into).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1435 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
will be able to select a ROM directory to scan, and have all files
identified as a ROM (by extension) renamed according to their properties
name. This will create ROMs with 'pretty names', and takes the place
of the previously removed 'non-browse' mode.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1429 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
enable/disable it. Currently, you have to exit and restart the program
for this to take effect.
Fixed issues with resizing and toggling video renderers and the
image not being updated correctly. Also, saving a snapshot within
emulation mode and exiting to launcher mode now shows the new
snapshot.
Currently, the rom info viewer only works with PNG images 320x250 or
less (ie, 1x zoom mode in Stella). If the image is bigger, a message
is displayed stating that fact. At some point I have to add another
snapshot mode where it always saves in 1x mode (or maybe not; it
depends on how many people will want to save snapshots for viewing in
the rom info viewer).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1428 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
ROM has been selected in the ROM launcher (or if we're in emulation mode).
BTW, I forgot to mention in the previous commit that Stella now only
recognizes ROMs if they're named with the following extensions: .bin,
.a26, .rom, .zip, .gz (not case sensitive). Right now, attempting to
select something else prints an error message. Eventually, a MessageBox
will be shown indicating that the filename isn't valid.
For now, this restriction is only for files started from the built-in
launcher. I haven't decided if it should apply to the commandline as well.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1427 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
actually removed it from 2.4.1, and re-added it in 2.4.2. But I think
I've figured out a way to get the best of both worlds, and only have
one browsing mode. This will become clearer once I finish the ROM
auditing feature.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1426 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
config folder to "My Documents\Stella". Note that 'My Documents' will
mean different locations in different versions of Windows. But the
user shouldn't have to worry about that, since the 'Stella' folder will
be in whatever 'My Documents' is on your system :)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1425 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
config files and the state folder. This is more in line with the Linux and
OSX ports, which have a pre-defined basedir folder ($HOME/.stella). This
also makes Stella behave better with limited accounts in Windows, since
writes are no longer done to the app folder.
Since the Win32 port didn't work this way before, many people may
require the old behaviour. In this case, one may create a file named
'disable_profiles.txt' in the app folder to restore the old behaviour.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1424 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
things a little (I hope I didn't break the recent GP2X changes).
Removed more PSP stuff, since that port is no longer maintained in this
codebase, but by someone else externally.
Building the 'win32dist' target is now tailored to a Linux environment,
and now properly converts text files and zips up the result
automatically. So automated building just became that much closer ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1422 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
accessed using a new 'host' type in configure (mingw32-cross). For
my system, the command would be as follows:
configure --host=mingw32-cross
--with-sdl-prefix=/home/stephena/.mingw/usr/i386-mingw32msvc
This allows you to compile the Windows version in Linux, which is my
main development platform. It will also allow me to get the automated
build page working again :)
Removed all NASM checking from the config scripts, since we're never
going to use it (it goes against the philosophy of Stella compiling
everywhere).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1421 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
This ties into the TIA floating pin on read logic that Eckhard recently added.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1418 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
To test this feature set 'myFloatTIAOutputPins' to 'false' in TIA::reset() and play the old version of Reindeer Rescue where you can see how Santa gets stuck in the background.
TODO: add a command line switch to control this feature. Steve can you help?
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1417 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
plugged in. It seems SDL sends button events for buttons 2, 3, 4, 5
in this case, which really doesn't make sense; a Stelladaptor can only
have two buttons.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1415 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
(sets the bankswitch type). I'm leaving the '-type' there as well,
just in case there are people (or frontends) that depend on it.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1414 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
movement, named 'pspeed'. This replaces the 4 'pXspeed' commandline
arguments. Also removed 'pthresh', since it no longer serves any purpose.
Updated UI to change this setting dynamically from within Stella.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1413 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Moved a lot of the code into the respective Controller classes, in the
process cleaning up the EventHandler (which was starting to get a little
unwieldy).
I've borrowed some code and ideas from z26, but also improved on it as
well:
1) Stelladaptor devices now send their events directly to a
controller class, allowing for any Stelladaptor device to emulate
a controller (to the limits of the input device, of course).
2) Hopefully fixed Stelladaptor driving controller support. Eckhard,
could you test this, since I don't have any of those myself?
3) Improved interaction with different input devices. For example,
a Stelladaptor, mouse, joystick (digital and/or analog axis), and
the keyboard can now simulate paddle events at the same time. So it
shouldn't matter what input devices you have plugged in; things should
'just work'. In the case of Stelladaptor paddles, you may have to
'zero' them by turning completely left, however.
4) Related to (3), changed mouse events to use relative motion. This
should fix the issues with paddle emulation/movement behaving
differently based on the window size.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1412 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
is add autodetection for this type.
Changed number of carts defined in GameInfoDialog to a constant, so we
only have to update it in one place.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1411 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
fixed a bug in the startup bank. According to the documentation, it
should always start in the last bank.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1410 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
displayed in the debugger GUI. I say 'partially', since it's not really
distinguishing between different types of labels with the same address, so
in some cases what you see in the debugger GUI won't be correct (but at
least you'll see *something*). I need to determine how the DASM sym file
is generated to fix this final issue.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1405 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
The 4A50 scheme now works on all test ROMs I have, whether or not display
autodetection is activated.
I noticed there's some graphical glitches in the various 'Ruby Runner'
demos below the lowest wall of the maze. I'm not sure if this is a
bankswitching issue or TIA emulation problem, but I'm leaning towards the
latter. More testing is required ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1402 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
ROM that follows the specs. Also, it seems the final ROM that wasn't
working with this scheme actually *does* work; it just doesn't work
when display format autodetection is turned on. So that's what I'll
work on next.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@1401 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba