Jump to content

Photo

Stella 3.9.1 released

stella debugger new release

34 replies to this topic

#1 stephena OFFLINE  

stephena

    River Patroller

  • 3,360 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Wed Aug 21, 2013 1:10 PM

It's time for another release of Stella. This one, like the last few, concentrates mostly on debugger improvements. However, as always, there are a few extras thrown in from different areas. Changelog is as follows:

* Note: because of TIA/6502 changes, the state file format has changed again, and old state files will not work with this release.

* Several bugfixes and improvements to the debugger:
- Improved display of debugger when using larger video modes. There are now three font sizes, which are automatically selected when the debugger is sized accordingly. When using larger fonts, the extra space is now used more efficiently.

- Fixed bug in disassembly when the mirror used for the current PC didn't match the mirror for the current bank. In this case, the disassembler became confused and didn't properly track the PC address.

- Fixed bug in display of current TIA frame number in the UI; depending on how breakpoints were set, it was sometimes off by one.

- Fixed RAM widget Search/Compare textboxes; entering any data and then pressing 'Enter' / clicking 'OK' locked the UI until exiting and re-entering the debugger.

- Changed display for various TIA position counters to decimal (from hex) in the TIA tab. Related to this, all data input widgets in the UI now have the ability to enter binary, decimal or hex values by using the proper leading character (\, #, $, respectively).

- Added 'INTIM Clks' to the 'I/O' tab. which shows the number of clocks between each 'step' of the INTIM timer.

- Added ability to modify 'tiadriven' commandline argument to the 'TIA' tab, and 'ramrandom' to the 'I/O' tab. These options were available for quite some time, but they weren't exposed in the UI.

- Added 'cpurandom' commandline argument, and associated UI item to the 'I/O' tab. This works similar to 'ramrandom', and randomizes the contents of the CPU registers on ROM startup.

- Added 'uhex' debugger prompt command, which toggles all hexadecimal display between upper/lower case. This setting is also saved in the settings file as argument 'dbg.uhex'.

- Removed 'loadsym' command from the debugger prompt, since the DASM symbol file is always loaded anyway, making the command redundant. Related to this, fixed loading symbols with ###.name convention; the leading number is now stripped.

- Added support for DASM lst files (created with the -l option). For now, the contents are only partially used, to detect constants vs. symbolic addresses in the symbol file. Eventually, further information from the lst file may be used.

- The GRPx and PFx registers in the TIA output now show inactive background pixels as either blanked or with the underlying object colour, instead of always being black. This gives a more accurate representation of how the registers are actually drawn onscreen. Thanks to Tjoppen of AtariAge for this idea and sample code.

- The 'Source Address' locations for the CPU registers now show labels where appropriate.

* Renamed 'Override properties' dialog (accessible from the ROM launcher by a right-mouse-button click) to 'Power-on options', with the following new options:
- Set start-up state for both joysticks as well as console select/reset buttons. Related to this, added 'holdjoy01' and 'holdjoy1' commandline arguments, and removed 'holdbutton0' argument.

- The ability to load the ROM directly from this dialog, after changing any settings, and also to start in the debugger.

- Added more detailed information as to how to use this functionality to the UI.

- Buttons held down are reset approx. 0.5 seconds after starting the ROM, to simulate pressing and releasing the buttons on a real console.

* Fixed bug when using event remapping; changes were being saved only when launching a ROM from the launcher, not in standalone mode.

* Improved bankswitch autodetection for newer EF and EFSC ROMs generated by batari Basic, thanks to RevEng of AtariAge.

* Added properties database info for "Princess Rescue" ROM.

* For the Linux/UNIX port:
- Fixed bug whereby a maximize button was always present in the window title bar. Stella could not be expanded in this way, so the button was removed.

- Added Startup notification protocol patch to the .desktop file from Dan Fandrich.

* Updated included PNG library to latest stable version.


Barring any major issues, the next release will concentrate on controller improvements (particularly mouse/paddle stuff, and a new device like 2600-daptor). Then I'll be concentrated on porting Stella to SDL2, which was just released a few weeks ago.

As usual, you can download Stella here, and please consider a donation if you find the project useful. Bug reports, etc can be reported here or by PM.

#2 israelg OFFLINE  

israelg

    Moonsweeper

  • 401 posts

Posted Wed Aug 21, 2013 1:22 PM

Thanks!

#3 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,972 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Thu Aug 22, 2013 7:35 AM

Added support for DASM lst files (created with the -l option). For now, the contents are only partially used, to detect constants vs. symbolic addresses in the symbol file.

Great feature, but doesn't seem to work for me.

SYM and LST files have been found, but the debugger still displays LDA BLUE (a5 80), where it should display LDA frameCnt instead. BLUE is a color constant.

LST file says:
64 ???? 00 80    BLUE = $80
...
97 U0080    00    frameCnt    .byte.b


#4 stephena OFFLINE  

stephena

    River Patroller

  • Topic Starter
  • 3,360 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Thu Aug 22, 2013 7:53 AM

Please forward sample ROM and both sym and lst files. I didn't have many lst files for comparison, so it's likely that I missed something. More work is probably required here. Eventually, it might be better to just use the lst file if it is provided, and bypass the automatic disassembly completely.

#5 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,972 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Thu Aug 22, 2013 8:17 AM

Here it is.

Disassembly displays $80 (f828) where it should display BLUE and BLUE (f83a) where it should display frameCnt. :)

Attached Files

  • Attached File  test.zip   8.85KB   124 downloads


#6 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,952 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Thu Aug 22, 2013 10:32 AM

I might be doing something wrong. The text in the debugger seems to be just as hard to read as it was when I mentioned it here:

http://atariage.com/...d/#entry2783024

Here's an example from today after selecting large text and restarting Stella:

stella_text.png

#7 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,972 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Thu Aug 22, 2013 10:56 AM

Looks good too me. Are you sure your eyes are OK?

#8 stephena OFFLINE  

stephena

    River Patroller

  • Topic Starter
  • 3,360 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Thu Aug 22, 2013 11:16 AM

Here's an example from today after selecting large text and restarting Stella:


Go to Options -> UI Settings -> Debugger. Click 'Window size for large font'. It will set the debugger window size to 1300x940. Start a ROM, and enter the debugger. For me, this generates the following:

rr.png

Of course, you actually need to have a monitor capable of displaying 1300x940 resolution. If you don't it falls back to (successively smaller) fonts until it can fit. Larger fonts mean more space needed for the debugger. There's no way around that one.

#9 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,952 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Thu Aug 22, 2013 3:39 PM

Of course, you actually need to have a monitor capable of displaying 1300x940 resolution. If you don't it falls back to (successively smaller) fonts until it can fit. Larger fonts mean more space needed for the debugger. There's no way around that one.


Mine is 1360 x 768. I don't think I ever had trouble with the size of the text, I just wanted it to be thicker (bolder), like in the screenshot you posted. Don't know why the text on mine is as thin as a baby flea turd and yours is thick enough to read without eyestrain.

#10 stephena OFFLINE  

stephena

    River Patroller

  • Topic Starter
  • 3,360 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Thu Aug 22, 2013 3:44 PM

The resolutions for small/medium/large fonts is 1080x720, 1280x860 and 1300x940, respectively. So based on your monitor size, it will only ever show the small font, since the screen isn't large enough to show otherwise.

I'll look into making the smaller font bold in certain areas, since 1360 x 768 is a common enough resolution, and other people may have similar issues with it.

#11 stephena OFFLINE  

stephena

    River Patroller

  • Topic Starter
  • 3,360 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Thu Aug 22, 2013 5:38 PM

Disassembly displays $80 (f828) where it should display BLUE and BLUE (f83a) where it should display frameCnt. :)


The latter was easy enough to fix; in fact, it's already fixed in SVN. The former is intentional, in that I don't use symbolic constants at all yet. They're stored in an array ready to be used, but the problem is I would need to replace all $80 by BLUE (for immediate mode). This isn't a problem for disassembly or this ROM, but consider the case where sometimes a $80 is meant to be just $80, and other times to use a constant name.

I'm not sure what makes more sense: replacing all $80 with BLUE, and having confusion when the label is used where it wasn't meant, or never using the label at all. I chose the latter for now, but it's not a final decision ...

#12 stephena OFFLINE  

stephena

    River Patroller

  • Topic Starter
  • 3,360 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Fri Aug 23, 2013 6:54 AM

OK, this is the small console font (1080x720) bolded instead of normal.

rr_small-bold.png

To me, it seems a little too 'busy'. I guess I could make only the labels be bold, and anything with lines of text (ie, with a light background) be normal. But that will take a little extra work, since the debugger is set up to use only one font ATM.

#13 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,952 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Aug 23, 2013 7:03 AM

To me, it seems a little too 'busy'. I guess I could make only the labels be bold, and anything with lines of text (ie, with a light background) be normal. But that will take a little extra work, since the debugger is set up to use only one font ATM.


At least at first glance, it looks fine to me. Thanks.

#14 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,972 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Aug 23, 2013 7:11 AM

To me, it seems a little too 'busy'.

100% agreed. The current font is much better.

I guess I could make only the labels be bold, and anything with lines of text (ie, with a light background) be normal.

No, please don't do that. While debugging, I care for the content, not the labels. So if you really have to make anything bold, then the text.

Vice versa would be like:

Today's Lottery Numbers: 6 12 13 22 24 37 :)

#15 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,972 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Aug 23, 2013 7:25 AM

I'm not sure what makes more sense: replacing all $80 with BLUE, and having confusion when the label is used where it wasn't meant, or never using the label at all.

I thought you would use the list file for that. If that's not possible, then displaying $80 is better, especially since there could be multiple constants with the same value.

#16 stephena OFFLINE  

stephena

    River Patroller

  • Topic Starter
  • 3,360 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Fri Aug 23, 2013 7:33 AM

I suspect the only way to accommodate everyone is to make it configurable. But only to an extent, as I could easily spend the next 6 months making every little thing in the UI configurable, and not get anything else done.

Maybe allow one to select normal and/or bold for labels/contents. That way you have 4 possible configurations: normal label and text (the current approach), bold label and normal text (and vice-versa) and everything bolded (like the previous image).

To be honest, adding two extra fonts to Stella isn't that hard. It's just that every time an option is added, the UI and documentation must be expanded to explain it. And the documentation itself is well over 100KB at this point :)

#17 stephena OFFLINE  

stephena

    River Patroller

  • Topic Starter
  • 3,360 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Fri Aug 23, 2013 7:35 AM

I thought you would use the list file for that. If that's not possible, then displaying $80 is better, especially since there could be multiple constants with the same value.


The list file is only used right now to read constant names and their values and differentiate the names from address names. It does not scan the entire list file and see where every constant is used. Eventually, this may be the best thing to do, but I will have to put it off for now.

#18 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,972 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Aug 23, 2013 7:45 AM

I suppose I better help getting the emulation right first. :D

#19 LS_Dracon OFFLINE  

LS_Dracon

    Dragonstomper

  • 778 posts

Posted Fri Aug 23, 2013 8:01 AM

Stephen, I found a bug.
In my last game, SuperPong, when you load the game the screen is garbled, mostly colors and the ball, I think is related what Thomas Jentzsch found in page 3 and I didn't understand that time.
The bug is fixed just going on controller config, I don't even need to change nothing, just returns to the game and everthing is fine.
The rom works fine in real hardware, I don't mind to send you the game source if you need.
Once the bug is fixed, it never happens again until you change the controller for joystick, so you can replicate it switching between paddle/joystick on game config.

Edit : The bug happens every time you go to controller config, if the game is fine, press ok and the game become garbled, then you return to controller config, press ok and the game is fine again.

Edited by LS_Dracon, Fri Aug 23, 2013 8:07 AM.


#20 stephena OFFLINE  

stephena

    River Patroller

  • Topic Starter
  • 3,360 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Fri Aug 23, 2013 8:56 AM

Stephen, I found a bug.


Please respond by PM with the source, ROM, and any extra info you think is appropriate.

#21 Joe Musashi OFFLINE  

Joe Musashi

    Moonsweeper

  • 311 posts

Posted Fri Aug 23, 2013 9:23 AM

I'm not sure if this is a bug, but when I go to the debugger screen and open then context menu for the display in the upper left (right mouse button) and then select 'Toggle fixed debug colors' nothing happens. This is regardless whether debug colors were on in the main screen or not.

This is on Mac OSX 10.7.5.

Edited by Joe Musashi, Fri Aug 23, 2013 9:24 AM.


#22 stephena OFFLINE  

stephena

    River Patroller

  • Topic Starter
  • 3,360 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Fri Aug 23, 2013 3:21 PM

Because of the way the current TIA image is drawn, toggling debug colours only takes effect on a subsequent draw. Normally this doesn't matter in emulation mode, since it's drawing 60fps and you see it essentially immediately. But in the debugger, the frame is frozen, and no further drawing occurs. If you toggle it and then do a step/trace/scanline/frame advance, it will draw in debug colours from that point on. This is all documented in the manual, BTW.

#23 Joe Musashi OFFLINE  

Joe Musashi

    Moonsweeper

  • 311 posts

Posted Fri Aug 23, 2013 4:02 PM

Yes, you are right, that works. Sorry, I should have checked that manual.

I see that this behavior allows to switch mid-screen. It still feels a bit unintuitive, though.

#24 stephena OFFLINE  

stephena

    River Patroller

  • Topic Starter
  • 3,360 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Fri Aug 23, 2013 4:12 PM

I agree that it's a bit unintuitive, but I'm not sure how to improve it. Perhaps the message could be clearer?? Toggle debug colours essentially means "from this point on". I suppose I could go back to the current framebuffer and redraw it with the new colours (without having to run the emulation to generate it), but then we wouldn't get the ability to change it mid-screen.

So which one is more important: have it redraw with new colours instantly upon toggling the option, or allowing mid-screen changes the way it is now?

#25 Joe Musashi OFFLINE  

Joe Musashi

    Moonsweeper

  • 311 posts

Posted Sun Aug 25, 2013 11:33 AM

My vote would be for redrawing the screen upon toggling. Mostly, because then one could switch back and forth without having to advance/alter the emulation state.

 







Also tagged with one or more of these keywords: stella, debugger, new release

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users