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? Thanks A -------Original Message------- > From: "B. Watson" <atari@xxxxxxxxxxxxxx> > Subject: [stella] Stella 2.0 Alpha 3 available > Sent: 03 Jul 2005 17:50:06 > > Download from http://www.hardcoders.org/stella-20050703.zip > > 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 http://www.biglist.com/lists/stella/archives/ > Unsub & more at http://stella.biglist.com -------Original Message------- Archives (includes files) at http://www.biglist.com/lists/stella/archives/ Unsub & more at http://stella.biglist.com
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[stella] Stella 2.0 Alpha 3 availab, B. Watson | Thread | Re: [stella] Stella 2.0 Alpha 3 ava, B. Watson |
[stella] Stella 2.0 Alpha 3 availab, B. Watson | Date | Re: [stella] Stella 2.0 Alpha 3 ava, B. Watson |
Month |