Re: [stella] Stella 2.0 Alpha 3 available

Subject: Re: [stella] Stella 2.0 Alpha 3 available
From: "atari2600" <atari2600@xxxxxxxxxxxxx>
Date: Sun, 3 Jul 2005 16:03:18 -0400
I would like to check this out on Boulder Dash (R) -- but I'm wondering...
does Stella handle 3E bankswitching?

-------Original Message-------
> From: "B. Watson" <atari@xxxxxxxxxxxxxx>
> Subject: [stella] Stella 2.0 Alpha 3 available
> Sent: 03 Jul 2005 17:50:06
>  Download from
>  Notes from Stephen:
>  1)  Fullscreen OpenGL in Windows is still not working correctly, better
>  to avoid it altogether for now.
>  2)  Tracking changes is only working in RAM, not the CpuWidget.  I'll
>  get to that later.
>  Notes from me:
>  There are a lot of changes since the last alpha. I'm sure there are bugs,
>  and I'm sure I forgot to mention some stuff in this message.  If something
>  seems wrong or nonsensical, please let me know so we can fix it.
>  This alpha contains Fred Quimby's frying code. I tried changing it
>  around, but nothing I came up with worked as well as the original,
>  so that's what we used. Press Backspace during emulation to fry.
>  The debugger RAM tab and prompt "ram" command now track changes to
>  RAM. For now, we don't detect when the same value gets written to
>  an address as was already there: this will need changes to the core,
>  and we'll proceed carefully there.. Meanwhile, you can step, trace,
>  frame advance, or run, and see the RAM locations turn red when they
>  change value.
>  The prompt also tracks CPU registers that have changed since the last
>  prompt was printed (they show up in inverse video). The CPU tab in the
>  GUI doesn't do this yet, but it will soon.
>  About the tracking: we save the RAM state before each step, trace, frame
>  advance, or run/exit. At each prompt (or in the RAM tab) we show the
>  changes since the last save-point. We *don't* save the old-RAM contents
>  in the state file, so you can save state, run the emulator for a while,
>  then load state and see what's different between the last emulated state
>  and the statefile.
>  Prompt error messages are now red (actually reddish, TIA color $34 or so).
>  Generally speaking, the prompt now supports color, so I'm asking for
>  suggestions about ways to use color to make information stand out. Nothing
>  should *require* color to be functional though: Some people might be using
>  B&W monitors, and some people are color-blind. I'm open to suggestions:
>  visual design is not my strong suit :)
>  The "tia" prompt command now gives you a lot more information, including
>  the values of write-only registers and internal TIA state (such as the
>  actual color-clock position of each player/missile/ball). Color registers
>  are displayed numerically along with a swatch of the actual color from the
>  current TIA palette. Things like NUSIZx are decoded somewhat into English
>  (e.g. "size=8 copy=3 spacing=8" for NUSIZ0 value 3). Audio frequencies
>  are displayed as AUDFx values plus freqency in Hz. This command still
>  isn't finished (for one thing, it doesn't display strobes. Ideally I'd
>  like RESP0, WSYNC, etc. to show how many clocks it's been since they
>  were last strobed).
>  Added "riot" command. Shows raw and decoded I/O and timer state, including
>  English joystick directions (for now it always says "(no direction)"
>  because entering the debugger resets all the inputs. This will change).
>  Even though the joystick buttons are wired to the TIA, I went ahead and
>  included them here.
>  There's a "colortest" command that lets you see any TIA palette
>  color. This will eventually (after 2.0 release) evolve into a screen
>  layout tool of some kind (which may end up a separate program if it
>  gets complex).
>  I can't remember whether this was in Alpha 2 or not: prompt has
>  "savestate", "loadstate" commands. These work exactly like the F9 and F11
>  keys do during emulation, except you specify the save-slot in the command:
>  "savestate 0" through "savestate 9". This provides simple "waypoint"
>  support for the debugger.
>  Added "rom" command for patching ROM. I made it a separate command
>  from "ram" because you don't want to accidentally change ROM due to
>  a typo. There are one or two cartridge types that don't support ROM
>  patching because I couldn't figure out the addressing scheme (these will
>  be fixed in the future).
>  Added "bank" command. With no parameters, it tells you the current
>  cartridge type and number of banks. With a bank number, it switches
>  to that bank. If you want to patch ROM, you need to switch to the bank
>  you want to patch before using "rom". There are a couple of cart types
>  where I couldn't easily tell what to do, so they don't (yet) support
>  bankswitching from the debugger.
>  This isn't a new feature, but it isn't immediately obvious from the
>  help output: The "ram" command can change any non-ROM address, not
>  just the RIOT RAM. So you can say "ram CXCLR 0" to clear collisions,
>  or "ram TIM64T 30" to set the TIM64 timer. You can even switch banks
>  in a bankswitched cart with the "ram" command. I will probably split
>  this off from "ram" and make it a separate command (which is better,
>  "poke" or "write"? Or I could make them both work...)
>  Enjoy,
>  --
>  B.
>  Archives (includes files) at
>  Unsub & more at
-------Original Message-------
Archives (includes files) at
Unsub & more at

Current Thread