Jump to content
IGNORED

DPC+ Playfield bug with Stella 4.x


Sprybug

Recommended Posts

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.

  • Like 1
Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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 by DirtyHairy
  • Like 1
Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by DirtyHairy
Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

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...