Stella 2.4.2 released

[+stephena]

OK, this is just a quick bug-fix release of version 2.4 wrt OpenGL giving a black/white screen. Apparently some OpenGL drivers (I'm looking at you, ATI) report to support an OpenGL extension, but really don't. So I've made the 'GL_TEXTURE_RECTANGLE_ARB' extension optional, and have it default to off. It can be toggled with the '-gl_texrect' commandline argument, if necessary. This was reported by at least one OSX user, but hopefully it will also fix the ATI issues that Win32 users are having.

 

Note that many of the promised updates for the next release are still being worked on, but this fix was important enough to warrant a separate point release. Big things are coming in 2.5 ...

 

As always, report any bugs here in this thread, or directly to me.

 

Stella Homepage

[Albert]

I've been using Stella a fair bit the last few weeks, and I have a suggestion and a bug.

 

The suggestion is to add some sort of button and/or hot-key that I can use to refresh the ROM listing while Stella is loaded. I know I can go into the menu and the Config Files dialog and then click on "Reload ROM Listing", but that's several extra clicks and I'm often copying new ROMs into my ROMs directory with Stella running.

 

The bug is that if you select a new directory, then go back out to the directory listing (get out of all the dialogs), the new directory you chose is not reloaded. In fact, even if you quit and restart Stella, it still loads the old directory instead of the new one you chose. I believe it should do an automatic refresh as soon as you exit the "Config Files" dialog if you did change the directory.

 

Thanks!

 

..Al

[Albert]

I'm also having an issue where if I choose a new directory and then click "Reload ROM Listing" right away, it reloads the previously selected directory instead of the new one I just picked. I have to exit the dialog and then click on "Config Files" again and then "Reload ROM Listing" in order to get the directory to refresh. Also, it's not refreshing the list when I start up Stella. I have to manually click "Reload ROM Listing" to see any changes to the directory. I am running OS X Leopard, btw.

 

..Al

[+stephena]

I'm also having an issue where if I choose a new directory and then click "Reload ROM Listing" right away, it reloads the previously selected directory instead of the new one I just picked. I have to exit the dialog and then click on "Config Files" again and then "Reload ROM Listing" in order to get the directory to refresh. Also, it's not refreshing the list when I start up Stella. I have to manually click "Reload ROM Listing" to see any changes to the directory. I am running OS X Leopard, btw.

 

..Al

I'll have to look into this. I tried to remove that functionality from version 2.4, but re-added it in 2.4.1 because several people wanted it back. I guess I didn't re-add all of it. I'd like to get rid of it entirely, though, and just have the ROM launcher act as a filesystem browser (show actual filenames and folders, not filenames based on the properties entries).

 

I wonder if you (or anyone else reading this) could answer why this mode is preferable to you? I'm thinking it's simply because of the better looking filenames. If this is the case, I did plan on adding a 'ROM audit' type mode, where all ROMs in the current directory can be renamed according to their properties entry. That way, you still get the nice names, but without this 'reloading/invalid cached' situation. Are there any other reasons why the filesystem/browse mode is not preferable??

[Albert]

I'm also having an issue where if I choose a new directory and then click "Reload ROM Listing" right away, it reloads the previously selected directory instead of the new one I just picked. I have to exit the dialog and then click on "Config Files" again and then "Reload ROM Listing" in order to get the directory to refresh. Also, it's not refreshing the list when I start up Stella. I have to manually click "Reload ROM Listing" to see any changes to the directory. I am running OS X Leopard, btw.

 

..Al

I'll have to look into this. I tried to remove that functionality from version 2.4, but re-added it in 2.4.1 because several people wanted it back. I guess I didn't re-add all of it. I'd like to get rid of it entirely, though, and just have the ROM launcher act as a filesystem browser (show actual filenames and folders, not filenames based on the properties entries).

 

I wonder if you (or anyone else reading this) could answer why this mode is preferable to you? I'm thinking it's simply because of the better looking filenames. If this is the case, I did plan on adding a 'ROM audit' type mode, where all ROMs in the current directory can be renamed according to their properties entry. That way, you still get the nice names, but without this 'reloading/invalid cached' situation. Are there any other reasons why the filesystem/browse mode is not preferable??

Why can't it do both? I'd much prefer a file system browser if a choice had to be made between the two. Most of the files I'm running don't have profiles yet because they are games in development, prototypes, etc. It really should always show the files in the current directory without my ever having to manually refresh it. What would be nice is if the file DOES have a properties entry, it would then show the name from the properties next to it. Right now the window is pretty big (with all those buttons lined up horizontally on the bottom) and the filenames are typically pretty short. Another option would be to show the filenames, and then have another window below the file list that shows some of the more important properties of the file you have selected above. Would be damn cool if a frame of the game could be rendered and displayed as well, but that's just wishful thinking.

 

Thanks,

 

..Al

[+stephena]

Why can't it do both?

Because I want to add some things that make it difficult to have two different modes. Some parts of Stella are becoming too complex, since there are too many options. The browse vs. non-browse mode is a perfect example of where we have two diverging ways of doing things that really should be merged into one. In other words, I'd like to concentrate on making one mode work for everyone, rather than having to compromise something every time I think of a new feature for one mode that doesn't work with the other. The software vs. OpenGL renderer is another area where this is a problem. I'd love to just concentrate on OpenGL only, and add scalers for it, but the dreaded software mode keeps coming back to haunt me

I'd much prefer a file system browser if a choice had to be made between the two. Most of the files I'm running don't have profiles yet because they are games in development, prototypes, etc. It really should always show the files in the current directory without my ever having to manually refresh it. What would be nice is if the file DOES have a properties entry, it would then show the name from the properties next to it. Right now the window is pretty big (with all those buttons lined up horizontally on the bottom) and the filenames are typically pretty short. Another option would be to show the filenames, and then have another window below the file list that shows some of the more important properties of the file you have selected above. Would be damn cool if a frame of the game could be rendered and displayed as well, but that's just wishful thinking.

The current CVS code has a snapshot viewer to the right of the ROM listing (if you enable it), and right below that the relevant properties are shown. Perhaps this is exactly what you're looking for, and if so, the point it moot. And not having to ever refresh the file listing is exactly why I want to get rid of non-browse mode as well.

 

I'm attaching a snapshot of the snapshot viewer. Obviously it isn't finished yet, but you can get the idea. Combined with a 'ROM audit' button which will rename all ROMs to that specified in their properties, I think it completely replaces the non-browse mode.

[Albert]

Why can't it do both?

Because I want to add some things that make it difficult to have two different modes. Some parts of Stella are becoming too complex, since there are too many options. The browse vs. non-browse mode is a perfect example of where we have two diverging ways of doing things that really should be merged into one. In other words, I'd like to concentrate on making one mode work for everyone, rather than having to compromise something every time I think of a new feature for one mode that doesn't work with the other. The software vs. OpenGL renderer is another area where this is a problem. I'd love to just concentrate on OpenGL only, and add scalers for it, but the dreaded software mode keeps coming back to haunt me

Well, I didn't really mean have two different ways of viewing a ROM listing, I meant show the filename and then the "properties" name side by side. But even that I don't care about, I just want the list to always be current without my having to manually force Stella to retrieve an updated file listing. I'm not sure you are addressing this issue with your comments. Right now I think it's confusing if I have files named one thing in a directory and Stella shows them as something else without showing the original filename. No other applications I use do this strange voodoo.

 

The current CVS code has a snapshot viewer to the right of the ROM listing (if you enable it), and right below that the relevant properties are shown. Perhaps this is exactly what you're looking for, and if so, the point it moot. And not having to ever refresh the file listing is exactly why I want to get rid of non-browse mode as well.

 

I'm attaching a snapshot of the snapshot viewer. Obviously it isn't finished yet, but you can get the idea. Combined with a 'ROM audit' button which will rename all ROMs to that specified in their properties, I think it completely replaces the non-browse mode.

That is very cool and is exactly what I was thinking of. Are you dynamically generating the screenshot? What do you mean by "non-browse mode"? I think I am a little confused by your terminology.

 

Thanks,

 

..Al

[+SpiceWare]

I noticed a bug in the debugger - the label doesn't get updated. You can see in the PROMPT area that it knows byte $80 is labeled SPbeat, but when 80 is clicked on in the RAM display the Label: field stays blank.

Edited November 13, 2007 by SpiceWare

[+stephena]

Well, I didn't really mean have two different ways of viewing a ROM listing, I meant show the filename and then the "properties" name side by side. But even that I don't care about, I just want the list to always be current without my having to manually force Stella to retrieve an updated file listing. I'm not sure you are addressing this issue with your comments. Right now I think it's confusing if I have files named one thing in a directory and Stella shows them as something else without showing the original filename. No other applications I use do this strange voodoo.

OK, terminology time

 

1) browse mode: where the listing in the Stella launcher window is exactly what exists on your disk. All filenames and directories are shown exactly has they're present on the hard disk (or whatever media you're accessing). This is the mode I want to keep. Adding new files to the directory while Stella is running (and pointing to that directory) will of course require you to move out of the directory and back into it, but I think all frontends work that way. Basically, every time you enter a directory, the file listing is re-scanned from disk.

 

2) non-browse mode: where the listing does not include directories, and the ROM files are shown as their names in the properties file. This is the mode I want to get rid of, since it requires accessing a cache file and keeping that up to date (ie, you can get a stale cachefile where the listing doesn't reflect the current directory contents).

 

#1 is what I want to continue improving, and discard #2. I suspect #2 is preferred by some people for several reasons:

 

a) It shows 'pretty' names for ROM files. However, I will fix that issue by having a 'ROM audit' mode, where the ROMs can actually be renamed to their properties entry. That way, the names will be changed on disk, and by using #1, it will look exactly the same.

 

b) Somewhat related to (a), it shows 'Note' information. However, this will be fixed by the snapshot viewer, where all relevant properties info is shown to the right of the ROM listing, and below the snapshot view.

That is very cool and is exactly what I was thinking of. Are you dynamically generating the screenshot? What do you mean by "non-browse mode"? I think I am a little confused by your terminology.

Snapshots are not generated automatically, but must be pre-generated (I already have a script to do this). Basically, you set your snapshot directory to point to the snapshots, and the viewer automatically finds and displays them.

[+stephena]

I noticed a bug in the debugger - the label doesn't get updated. You can see in the PROMPT area that it knows byte $80 is labeled SPbeat, but when 80 is clicked on in the RAM display the Label: field stays blank.

Yes, it seems to not be working. Can you forward the ROM and sym file so I can duplicate (and fix) the problem?

[Buzbard]

After reading your explanation of the "browser/non-browser" modes and the "Rom Audit" feature, I think that your new "Browser" mode would be best and I vote to get rid of the old "Non-Browser" mode.

 

I was one of people that asked you to bring it back, just because I have multiple ROMs that have similar names in the same directory, and it's hard to tell which is which.

[+SpiceWare]

Yes, it seems to not be working. Can you forward the ROM and sym file so I can duplicate (and fix) the problem?

Will do so after work.

[Tickled_Pink]

Maybe it's just me, but I've just been trying to set up Stella to my liking but can't quite set up the directories in the stella configuration file. If it's not possible at the moment, then it would a nice (if minor) addition. If it is possible, then can someone tell me how to do it.

 

All I'm trying to do is set up the romdir property so that it points to a subdirectory within the directory that stella's residing, without having to put in the full path to it. That way, if space on one drive is short, I can just transfer the files to another - or even to a CD/DVD and still have immediate access to the ROM listing in the file browser when I launch Stella.

 

So, for example, if I have the following structure:

 

H:\Stella

|

|- Docs

|

|- ROMS

 

I should just have to type in either:

 

romdir = ROMS\

 

or

 

romdir = .\ROMS\

 

At the moment it seems that I have to type in:

 

romdir = H:\Stella\ROMS\

 

Which is no good if I want to move the files to another drive later.

Edited November 17, 2007 by Tickled_Pink

[+batari]

I have a request about the handling of JAM opcodes. If one is encountered, it would be nice if there was a setting to automatically enter the debugger. That, and the setting would also allow the processor to be unJAMmed without having to restart (currently a JAM stops the debugger from continuing execution as well.)

 

The idea is that a JAM is always a bug, this the debugger.

 

The side effect is that a JAM could also be a "breakpoint instruction" that could be compiled into code during development instead of having to manually set them. Modern CPUs and debuggers have intentional breakpoint instructions for exactly this purpose.

[NinjaWarrior]

How about for games that requiers the Paddle, driving & keyboad controllers

[+SpiceWare]

How about for games that requiers the Paddle, driving & keyboad controllers

Stella supports all of those controllers, and more.

[+stephena]

I should just have to type in either:

 

romdir = ROMS\

 

or

 

romdir = .\ROMS\

 

At the moment it seems that I have to type in:

 

romdir = H:\Stella\ROMS\

 

Which is no good if I want to move the files to another drive later.

What you're talking about is called 'relative pathnames'. Stella doesn't support that right now, but I will consider it for a future release.

[+stephena]

I have a request about the handling of JAM opcodes. If one is encountered, it would be nice if there was a setting to automatically enter the debugger. That, and the setting would also allow the processor to be unJAMmed without having to restart (currently a JAM stops the debugger from continuing execution as well.)

 

The idea is that a JAM is always a bug, this the debugger.

 

The side effect is that a JAM could also be a "breakpoint instruction" that could be compiled into code during development instead of having to manually set them. Modern CPUs and debuggers have intentional breakpoint instructions for exactly this purpose.

I'll put this on the TODO list, and I may have questions about it in the future. For now, I'm otherwise occupied with other parts of the codebase

[Thomas Jentzsch]

I'll put this on the TODO list, and I may have questions about it in the future. For now, I'm otherwise occupied with other parts of the codebase

Another TODO from my wishlist: Support 4a50 bankswitching.

[SeaGtGruff]

Another TODO from my wishlist: Support 4a50 bankswitching.

I second that! And since John/supercat has already added 4A50 bankswitching support to z26 (see his AtariAge blog for the updated z26 program), studying those changes should hopefully make it easier/quicker to make similar changes to Stella.

 

Michael

[+Andrew Davie]

Another TODO from my wishlist: Support 4a50 bankswitching.

I second that! And since John/supercat has already added 4A50 bankswitching support to z26 (see his AtariAge blog for the updated z26 program), studying those changes should hopefully make it easier/quicker to make similar changes to Stella.

 

Michael

 

I third that, with icing on top. 4a50 support in Stella would tend to push me towards porting Boulder Dash® to that bankswitch scheme, as it offers many advantages over 3E which I am currently using. I would expect significant speedups in some sections of the code, and as I use Stella as my development environment (z26 does NOT run BD successfully), it's only when one of these two emulators supports 4a50 AND 3E correctly that I can proceed.

 

Cheers

A

[+stephena]

Another TODO from my wishlist: Support 4a50 bankswitching.

I second that! And since John/supercat has already added 4A50 bankswitching support to z26 (see his AtariAge blog for the updated z26 program), studying those changes should hopefully make it easier/quicker to make similar changes to Stella.

 

Michael

 

I third that, with icing on top. 4a50 support in Stella would tend to push me towards porting Boulder Dash® to that bankswitch scheme, as it offers many advantages over 3E which I am currently using. I would expect significant speedups in some sections of the code, and as I use Stella as my development environment (z26 does NOT run BD successfully), it's only when one of these two emulators supports 4a50 AND 3E correctly that I can proceed.

 

Cheers

A

I just replied on the Stella mailing list about this. Basically, I don't have a lot of time, and my initial experiments with 4A50 support were less than encouraging. Due to other issues, I haven't really been motivated to work on Stella in the past few months. Maybe if some others could help a little, it would renew my energy (hint, hint). I have all kinds of ideas of new features and fixes to add, but when you're a lone programmer not hearing from anyone for months, it tends to turn you off a little.

 

I did look at the z26 4A50 code, but it isn't terribly helpful since I don't really know x86 assembler. If someone could go through that one module and convert it to an algorithm (in pseudocode, it doesn't even have to be in C or C++), it would help me add support 1000x faster.

[Thomas Jentzsch]

I did look at the z26 4A50 code, but it isn't terribly helpful since I don't really know x86 assembler. If someone could go through that one module and convert it to an algorithm (in pseudocode, it doesn't even have to be in C or C++), it would help me add support 1000x faster.

I just checked John's blog, but I could find any source code for z26 there.

[+stephena]

I did look at the z26 4A50 code, but it isn't terribly helpful since I don't really know x86 assembler. If someone could go through that one module and convert it to an algorithm (in pseudocode, it doesn't even have to be in C or C++), it would help me add support 1000x faster.

I just checked John's blog, but I could find any source code for z26 there.

I went through Google and found it right away Anyway, attached is the main file that would need to be converted. There were a few other files in the archive, but they're basically just hooks into the new code; the attached one is where all the work is done (renamed to .txt so it would upload).

 

JBANK.ASM.txt

[SeaGtGruff]

I just checked John's blog, but I could find any source code for z26 there.

As near as I can figure, it's in the .zip file here:

 

http://www.atariage.com/forums/index.php?a...;showentry=1400

 

Only the new or modified files are included, so you still need the source for z26 if you want to compile it yourself, but the modified file is BANKS.ASM, and the new file is JBANK.ASM. BANKS was modified to auto-detect a 4A50 ROM image based on a ROM size of 64K or 128K (look for "JBP" to see the lines where John modified the code), and JBANK is the new code for actually doing the bankswitching... I think. It's all pretty much over my head for the most part, but that's what I figure from looking at it!

 

Michael