+stephena Posted August 21, 2013 Share Posted August 21, 2013 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. 5 Quote Link to comment Share on other sites More sharing options...
israelg Posted August 21, 2013 Share Posted August 21, 2013 Thanks! Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 22, 2013 Share Posted August 22, 2013 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 Quote Link to comment Share on other sites More sharing options...
+stephena Posted August 22, 2013 Author Share Posted August 22, 2013 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 22, 2013 Share Posted August 22, 2013 Here it is. Disassembly displays $80 (f828) where it should display BLUE and BLUE (f83a) where it should display frameCnt. test.zip Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 22, 2013 Share Posted August 22, 2013 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/forums/topic/213888-stella-39-released/#entry2783024 Here's an example from today after selecting large text and restarting Stella: Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 22, 2013 Share Posted August 22, 2013 Looks good too me. Are you sure your eyes are OK? Quote Link to comment Share on other sites More sharing options...
+stephena Posted August 22, 2013 Author Share Posted August 22, 2013 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: 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 22, 2013 Share Posted August 22, 2013 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. Quote Link to comment Share on other sites More sharing options...
+stephena Posted August 22, 2013 Author Share Posted August 22, 2013 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. 1 Quote Link to comment Share on other sites More sharing options...
+stephena Posted August 22, 2013 Author Share Posted August 22, 2013 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 ... Quote Link to comment Share on other sites More sharing options...
+stephena Posted August 23, 2013 Author Share Posted August 23, 2013 OK, this is the small console font (1080x720) bolded instead of normal. 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. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 23, 2013 Share Posted August 23, 2013 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 23, 2013 Share Posted August 23, 2013 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 23, 2013 Share Posted August 23, 2013 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. Quote Link to comment Share on other sites More sharing options...
+stephena Posted August 23, 2013 Author Share Posted August 23, 2013 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 Quote Link to comment Share on other sites More sharing options...
+stephena Posted August 23, 2013 Author Share Posted August 23, 2013 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 23, 2013 Share Posted August 23, 2013 I suppose I better help getting the emulation right first. Quote Link to comment Share on other sites More sharing options...
LS_Dracon Posted August 23, 2013 Share Posted August 23, 2013 (edited) 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 August 23, 2013 by LS_Dracon Quote Link to comment Share on other sites More sharing options...
+stephena Posted August 23, 2013 Author Share Posted August 23, 2013 Stephen, I found a bug. Please respond by PM with the source, ROM, and any extra info you think is appropriate. Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted August 23, 2013 Share Posted August 23, 2013 (edited) 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 August 23, 2013 by Joe Musashi Quote Link to comment Share on other sites More sharing options...
+stephena Posted August 23, 2013 Author Share Posted August 23, 2013 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. Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted August 23, 2013 Share Posted August 23, 2013 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. Quote Link to comment Share on other sites More sharing options...
+stephena Posted August 23, 2013 Author Share Posted August 23, 2013 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? Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted August 25, 2013 Share Posted August 25, 2013 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.