Jump to content
IGNORED

Stella 3.7.3 released


stephena

Recommended Posts

Speaking of new features, there are a couple of things that I'd like to see in future releases:

 

1 - Save screenshots in a different directory than the one used to show them in the UI. At the moment it could be a bit annoying finding a screenshot you just take to post it in a forum if you already have hundreds of them in the same dir. If you use different paths you can manually move the images you want to see in the UI if needed, or you can set the same directory in both paths if you want to keep the current behaviour.

 

2 - Ability to change the controllers in the "Game Properties" tab without having to reload the rom. This could help development if using a routine to autodetect the controller plugged in the console, or if using the AtariVox/SaveKey in a 2 player game: in this case the game could require to swap one of the controllers with the Savekey at the end of a round to store/load data.

 

You're right that these are fairly minor and will have to wait until after the bigger issues. That being said, they're both options I'd considered myself at some point, so there's a good chance I'll get them added eventually. #1 in particular is annoying when I'm testing ROMs and don't want to mess up my main snapshot collection.

 

I think for #1, we could have a 'load' and a 'save' folder. By default, 'save' would be the same as 'load', but there could be a checkbox or something that allows you to use separate locations. Quite easy to do, actually.

Link to comment
Share on other sites

  • 1 month later...

Speaking of new features, there are a couple of things that I'd like to see in future releases:

 

1 - Save screenshots in a different directory than the one used to show them in the UI. At the moment it could be a bit annoying finding a screenshot you just take to post it in a forum if you already have hundreds of them in the same dir. If you use different paths you can manually move the images you want to see in the UI if needed, or you can set the same directory in both paths if you want to keep the current behaviour.

 

2 - Ability to change the controllers in the "Game Properties" tab without having to reload the rom. This could help development if using a routine to autodetect the controller plugged in the console, or if using the AtariVox/SaveKey in a 2 player game: in this case the game could require to swap one of the controllers with the Savekey at the end of a round to store/load data.

 

Number one is done, and will be in the next release. There's now separate 'save' and 'load' directories, which can be set differently (the default is the same one, so it works like old releases).

 

Number 2 is more invasive, and will have to wait for a future release. There's several separate places in the code that assume the same controllers per ROM load, so that logic/assumption will have to be reworked.

Link to comment
Share on other sites

During debugging I noticed yesterday, that e.g. the frame count seems not correct when using break points. Before executing the kernel it is displayed as X and afterwards as X+1. But it should switch at VSYNC.

 

I suppose the displayed X is wrong and should be X+1 instead. That's because there seems to be other incorrect data after hitting a break point the first time during a frame. E.g. often the preview picture is displayed at a vertically wrong position and the current scanline value is wrong too. This goes away after after you step forward one frame.

Link to comment
Share on other sites

During debugging I noticed yesterday, that e.g. the frame count seems not correct when using break points. Before executing the kernel it is displayed as X and afterwards as X+1. But it should switch at VSYNC.

 

I suppose the displayed X is wrong and should be X+1 instead. That's because there seems to be other incorrect data after hitting a break point the first time during a frame. E.g. often the preview picture is displayed at a vertically wrong position and the current scanline value is wrong too. This goes away after after you step forward one frame.

 

A test ROM and exact description is always helpful in this case. But I suspect this is 3.9 stuff, as I'm in the middle of preparing for the 3.8 release now. BTW, I did fix a debugger issue with INTIM/TIMINT reads that were being displayed incorrectly, so it could be that this is related.

 

I hope to get to these in the 3.9 release, which will be mostly debugger-based. We've already discussed one of the major debugger things that will be in 3.9 :)

Link to comment
Share on other sites

:)

 

Another, minor thing: We have hotkeys for Step, Trace, Scan+1, Frame+1 and Rewind, but not for Exit. Since only a Exit reacts to breakpoints and traps (BTW: why is that? Especially for Frame+1 this is a bit annoying), I would like a hotkey here too.

 

I will provide a test ROM and description with my next post.

Link to comment
Share on other sites

The attached ROM is the latest build of Star Castle. Add two breakpoints at _CHECK0 and _CHECK1. The first is at the beginning of the display kernel, the 2nd one at the end. Both are executed each frame.

 

So the expected frame numbers at the breakpoints would be n, n, n+1, n+1, n+2, n+2,... But instead we get n, n+1, n+3, n+4, n+6, n+7, ...

 

When you step forward after _CHECK0 or _CHECK1, you will notice that the frame increases by one immediately. Which perfectly explains the odd numbers listed above. It seems that a hit breakpoint increases the frame number.

framebug.zip

Link to comment
Share on other sites

Quick question Re: Star Castle

Do we need 2 builds, one for Stella and one for Harmony because Stella reports FA2* and is that a new bank switch type?

The 29K build runs in Stella and reports FA2* .

FA2 (padded to 1024) at the beginning appended to a padded .bin to 32,768 that runs on Harmony will not run in Stella.

Link to comment
Share on other sites

Quick question Re: Star Castle

Do we need 2 builds, one for Stella and one for Harmony because Stella reports FA2* and is that a new bank switch type?

The 29K build runs in Stella and reports FA2* .

FA2 (padded to 1024) at the beginning appended to a padded .bin to 32,768 that runs on Harmony will not run in Stella.

 

FA2 is indeed a new bankswitching scheme created by cd-w for Star Castle (the * in this case simply means it was autodetected as such). This ROM won't run directly on Harmony since it needs some extra ARM code appended. I'm not opposed to adding support for the 32KB version to Stella, as long as it can be reliably autodetected (perhaps by recognizing a string in the ARM code, etc?).

 

EDIT: The Stella version is actually 28K, not 29. And it was originally 24K, essentially doubling the capacity from the FA (12K) scheme (hence the name FA2). So if we add support the 32K, there will be three versions (24/28/32K). Again, this is fine, so long as it can be reliably autodetected.

Link to comment
Share on other sites

If we're sure that the 32K version of FA2 will always have valid ROM data @ 1K - 29K with all zeroes above this, then Stella can be easily modified to autodetect this. In fact I've already done it, but await a response before committing the change :)

Link to comment
Share on other sites

Couldn't you just check for FA2 and then accept both file sizes (28 and 32k)?

 

Not sure what you mean by 'check for FA2'. It's actually the other way around; the file sizes (in part) determine that the ROM is FA2. So we don't know until after looking at the sizes whether it is FA2. Remember, at this level, it's a static analysis; just looking at ROM sizes and inspecting certain byte patterns. There's no disassembly going on or anything like that.

 

My question should have been worded differently. I should have asked: are we sure that given a 29/32KB file with all zeros above 29K, that the first 1K should be skipped and the next 28K is valid FA2 data? IOW, is the scheme subject to change??

 

Remember, I'm asking this question in the context of autodetection for all ROM types. I have to be careful that one heuristic isn't too aggressive and cause mis-detections. This is particularly hard at 32K, since there are so many different schemes possible.

Link to comment
Share on other sites

Not sure. At least for Star Castle it shouldn't change.

 

Maybe you could check for the ARM loader code pattern instead? Here are two patterns: A0 C1 1F E0 and 00 80 02 E0 which should appear within the first 1k.

Edited by Thomas Jentzsch
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...