Sprybug Posted May 25, 2017 Share Posted May 25, 2017 Hey guys, got another laptop that I planned on using for projects, like programming Atari games for example. So I transfer all my stuff from my old laptop to this one and install the latest Batari BASIC, VbB, and Stella. They all ran fine and then I ran my latest BIN from Robot Zed in Stella to check it out. The playfield jitters like a mofo. Now, I thought it might have to do with something I did in the code and tried an older BIN that I know worked on my old laptop. It still jittered. I saw what version of Stella I was using on my old laptop and it was 3.8.1. So I scoured the Internet and found that same version on some website. I downloaded and installed it, and it ran just fine. I tried the latest Stella and the earlier one I could get on the Stella site (4.1) and they all did the jitters. So, there's got to be something going wrong in the emulation when it comes to displaying a DPC+ playfield. Is there any way we can get to the authors of Stella about this issue? They can use Robot Zed's current source for testing material, if they need to. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 25, 2017 Share Posted May 25, 2017 Spice made stella more accurate WRT DPC+ jitter. I think it's likely that your code will jitter on real hardware too. Make sure you've set the DFxFRACINC registers before each drawscreen command. Quote Link to comment Share on other sites More sharing options...
Sprybug Posted May 25, 2017 Author Share Posted May 25, 2017 Thanks Rev. I included the values of the DeFRANC variables/registers to my renderscreen routine, which gets called for every drawscreen, and it fixed the issue. What was implemented in the later Stellas that accounted for this? 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 25, 2017 Share Posted May 25, 2017 NP. On real hardware the DFxFRACINC variables get cleared/changed by the time the frame is drawn. Stella was changed to match. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted May 25, 2017 Share Posted May 25, 2017 (edited) Thanks Rev. I included the values of the DeFRANC variables/registers to my renderscreen routine, which gets called for every drawscreen, and it fixed the issue. What was implemented in the later Stellas that accounted for this? Before Darell's change, the fractional part (the lowest 8 bit) of a fractional counter were cleared both by changing the fractional increment or by writing the low byte of the corresponding pointer (bits 7- 15 of the fetcher). The change was to clear the fractional part only on writes to the fractional increment. That's whe you get jitter on the playfield: the fractional part is not reset between frames, causing an offset that varies between frames. NP. On real hardware the DFxFRACINC variables get cleared/changed by the time the frame is drawn. Stella was changed to match. I wonder whether this is true for all versions of the DPC+ driver that have been out in the wild. I just confirmed that this is the same issue that plagues epic adventure when running on modern versions of Stella (see the last few posts here: http://atariage.com/forums/topic/184924-epic-adventure/page-8). The binaries fail to run on my harmony (guess I'd have to flash an old version of the firmware), but as this was published and sold on AA, I assume that there was an old version of the driver that actually behaved the same way as old Stella versions (or the code was fixed before flashing the boards, but the change did not make it into the last binary published on the forum). If this is true, then I think we might want to offer an option in Stella (and 6502.ts) to emulate the old behavior and support those old ROMs that relied on it. Edited May 25, 2017 by DirtyHairy 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 25, 2017 Share Posted May 25, 2017 The binaries fail to run on my harmony (guess I'd have to flash an old version of the firmware), but as this was published and sold on AA, I assume that there was an old version of the driver that actually behaved the same way as old Stella versions (or the code was fixed before flashing the boards, but the change did not make it into the last binary published on the forum). I think you're right that the older DPC+ driver didn't behave this way. I helped Byte Knight fix a cycle-overage issue in EA just prior to the cart release (later than what's in that thread) and in the source I have I only see DFxFRACINC being set when each playfield is defined. (not every frame) Quote Link to comment Share on other sites More sharing options...
+stephena Posted May 25, 2017 Share Posted May 25, 2017 I think doing this could lead us down the rabbit hole. For 'newer' bankswitch schemes (DPC+, CDF, BUS, etc), I look at them as being WIP. In fact, I think Spiceware (the person who either developed or provided significant input) looks at them the same way. So when a new version of DPC+ comes out, there is new ARM code for the Harmony, and updated code for Stella. Going back and supporting old versions is problematic, since in some cases they fix valid bugs. In any event, this would lead to having to track the different versions, and have different versions of classes in Stella, etc. The better approach would be to update older ROMs to the newer version of the bankswitch scheme, which, again, often offers bugfixes. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted May 25, 2017 Share Posted May 25, 2017 (edited) I agree with you for CDF and BUS, those are under active development and all games developed on this basis are in active development and evolving with those drivers. However, I don't fully agree about DPC+. If it indeed turns out that there are versions with different semantics that have been used as the basis for AA store releases, then I think it would be worthwhile to investigate whether we can support those --- if my assertion is correct, then there is currently no way to run the released version of Epic Adventure on a current emulator. I agree that having different classes for those would be far too much pain, as would be following each bugfix revision. What I'd like to suggest is to investigate those versions that have been ciculated and used for BBasic and AA store releases and support any *widespread* differences that can be adressed conditionally (which might well boil down to just this fetcher issue) by either Adding a non-persistent option, via command line and cartridge DB, to specify the DPC+ revision Checksumming the DPC+ driver A combination of both For example, the fractional fetcher can easily be fixed by adding a conditional to the code. Edited May 25, 2017 by DirtyHairy Quote Link to comment Share on other sites More sharing options...
+stephena Posted May 25, 2017 Share Posted May 25, 2017 I agree with you for CDF and BUS, those are under active development and all games developed on this basis are in active development and evolving with those drivers. However, I don't fully agree about DPC+. If it indeed turns out that there are versions with different semantics that have been used as the basis for AA store releases, then I think it would be worthwhile to investigate whether we can support those --- if my assertion is correct, then there is currently no way to run the released version of Epic Adventure on a current emulator. This was once true for DPC+ as well; it was under active development, and the ROMs were developed along with the drivers. That's why we're in this position now; at one point, a ROM was finalized based on a non-finalized version of the scheme, and no longer works with the newer version of the scheme. I do think that old ROMs should work, but what it means is introducing revisions, and tracking what exactly is a new ROM and what is an old one. I'm not against the idea necessarily, just the amount of work it may create. I agree that having different classes for those would be far too much pain, as would be following each bugfix revision. What I'd like to suggest is to investigate those versions that have been ciculated and used for BBasic and AA store releases and support any *widespread* differences that can be adressed conditionally (which might well boil down to just this fetcher issue) by either Adding a non-persistent option, via command line and cartridge DB, to specify the DPC+ revision Checksumming the DPC+ driver A combination of both For example, the fractional fetcher can easily be fixed by adding a conditional to the code. If that is all that it is, and if we can auto-detect the ARM code by checksum or something similar, then I'm not opposed to it. But if we are serious about doing this, I think we need to open an issue for it. I have some other DPC+ ROMs here that also don't work in the newest scheme, but I think are not related to the "fractional fetcher" stuff. So that is another revision; now we have 3 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted May 25, 2017 Share Posted May 25, 2017 If that is all that it is, and if we can auto-detect the ARM code by checksum or something similar, then I'm not opposed to it. But if we are serious about doing this, I think we need to open an issue for it. I have some other DPC+ ROMs here that also don't work in the newest scheme, but I think are not related to the "fractional fetcher" stuff. So that is another revision; now we have 3 Done https://github.com/stella-emu/stella/issues/139 I also have at least one example of an old DPC+ ROM that fails on current Stella with an ARM trap. I'll start out by raising this question over at the Harmony channel, I guess Spiceware or Batari might know more about which revisions were circulated and what changes (if any) might be worth emulating Quote Link to comment Share on other sites More sharing options...
+stephena Posted May 25, 2017 Share Posted May 25, 2017 I also have at least one example of an old DPC+ ROM that fails on current Stella with an ARM trap. I'll start out by raising this question over at the Harmony channel, I guess Spiceware or Batari might know more about which revisions were circulated and what changes (if any) might be worth emulating Yes, that's what I have too; probably the same ROM. Anyway, I will move further discussion to the github page. 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.