Jump to content

Recommended Posts

The only way to know for sure is to somehow create the ROM with a different version of the ARM DPC+ driver and see what happens.  However, I don't know much about how bB actually works, so I can't help with that part.  For now, I know from several reports that it works on real hardware, and that the 'tweak' we use for another version of the ARM driver allows this ROM to work correctly.  So I can easily fix it in Stella.  But I'd really like to see it compiled with the latest driver to make sure that this 'fix' is the correct way to go.

Share this post


Link to post
Share on other sites
3 hours ago, TwentySixHundred said:

if this is a case of a Stella the bug please report what the issue is as this would be very helpful for us programmers

OK, so this is the relevant code from Stella:

// Older DPC+ driver code had different behaviour wrt the mask used
// to retrieve 'DFxFRACLOW' (fractional data pointer low byte)
// ROMs built with an old DPC+ driver and using the newer mask can
// result in 'jittering' in the playfield display
// For current versions, this is 0x0F00FF; older versions need 0x0F0000
uInt32 myFractionalLowMask{0x0F00FF};
...
// Currently only one known DPC+ ARM driver exhibits a problem
// with the default mask to use for DFxFRACLOW
if(MD5::hash(image, 3_KB) == "8dd73b44fd11c488326ce507cbeb19d1")
  myFractionalLowMask = 0x0F0000;

Basically, the behaviour of DFxFRACLOW changed from old versions of the ARM driver to new versions.  Old versions expect a mask of $F0000, while new versions expect the mask to be $F00FF.  I can confirm if I force Stella to use the old mask, then this ROM works fine.  So it's very easy to fix on my end, if it is indeed that problem.

 

I don't know if this is something that bB users will even interact with; it might be happening at a lower level, and not accessible in Basic at all.

Share this post


Link to post
Share on other sites

I can understand that an old game using an old driver is failing and needs special handling in Stella. But there is no reason for a new game which uses a common bB type (DPC+) which is used by many other bB games without problems too. IMO the problem must be on the game's side.

 

But I also wonder why the game is working on a Harmony. Does the Harmony have some kind of autodetection? Or does it work with both addresses? Or...?

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, Thomas Jentzsch said:

But I also wonder why the game is working on a Harmony.

This is the sticking point.  If the code is working correctly on real hardware, I can't see how there is anything wrong with the driver, and hence it must be a Stella issue.  But unless we can test the very latest DPC+ driver code, we can't know for sure.

  • Like 1

Share this post


Link to post
Share on other sites
12 hours ago, stephena said:

OK, so this is the relevant code from Stella:

// Older DPC+ driver code had different behaviour wrt the mask used
// to retrieve 'DFxFRACLOW' (fractional data pointer low byte)
// ROMs built with an old DPC+ driver and using the newer mask can
// result in 'jittering' in the playfield display
// For current versions, this is 0x0F00FF; older versions need 0x0F0000
uInt32 myFractionalLowMask{0x0F00FF};
...
// Currently only one known DPC+ ARM driver exhibits a problem
// with the default mask to use for DFxFRACLOW
if(MD5::hash(image, 3_KB) == "8dd73b44fd11c488326ce507cbeb19d1")
  myFractionalLowMask = 0x0F0000;

Basically, the behaviour of DFxFRACLOW changed from old versions of the ARM driver to new versions.  Old versions expect a mask of $F0000, while new versions expect the mask to be $F00FF.  I can confirm if I force Stella to use the old mask, then this ROM works fine.  So it's very easy to fix on my end, if it is indeed that problem.

 

I don't know if this is something that bB users will even interact with; it might be happening at a lower level, and not accessible in Basic at all.

 

 

Share this post


Link to post
Share on other sites
1 minute ago, TwentySixHundred said:

That is something that worries me about Stella, it's crucial that Stella stays faithful. I want the emulator closer to hardware rather then then an an a patch. It helps us developers ironing out bad techniques and learning of where we go wrong i truly believe this is a coding issue. I could be wrong an would rather a developer prove me wrong, that would be great

 

This is not a 'patch' in the normal sense.  What many people don't realize is that DPC+ actually has several variations, and was in active development over the years during which some games using it were released on cart.  That is, DPC+ actually changed how it did certain things, over time.  So we're not just emulating one bankswitching scheme, but variations of it.

 

Now, I would have preferred to use the very latest DPC+ driver emulation in Stella, and just ignore the WIPs that are out there.  But at least one ROM has been released commercially on AtariAge that used the old way of doing things.  And the tweak in Stella considers that old version of the driver.  No new game should ever be using that version of the driver.  That's why I want to get this ROM compiled with the very latest DPC+ driver, and see if the problem persists.  If it doesn't, then we know for sure that the problem in the current ROM.

 

I fully agree that Stella should be closer to what he hardware really does; that's the whole point of emulation after all.  But in this case, before I commit a change to Stella, I want to be absolutely sure where the bug is coming from.

Share this post


Link to post
Share on other sites
8 minutes ago, TwentySixHundred said:

What i am saying is please prove me wrong as this helps with development of my latest game

I personally can't prove you wrong, since I don't have much experience with bB.  But I outlined how someone would do it.  Get the very latest DPC+ driver for bB, compile the code, and see if it still happens.  If it does, then we can definitely say that the ROM code is buggy.

 

EDIT:  There are too many unknowns right now.  Is it an old vs. new version of the driver, is the ROM buggy, is Stella buggy, does the Harmony do something different here, etc?  We need to narrow it down (ie, find the actual source of the bug).

Share this post


Link to post
Share on other sites
45 minutes ago, stephena said:

I don't know if this is something that bB users will even interact with; it might be happening at a lower level, and not accessible in Basic at all.

That is indeed the case - the bB programmer doesn't set or see the driver at all; it is "under the hood". The OP is using the latest version of bB, and the DPC+ code hasn't changed in quite some time. Several DPC+ bB games have been produced with the same DPC+ code with no reports of any issues with Stella, so the problem being due to the older driver feels like a red herring to me.

 

That being said, @RevEng has asked to be pointed to the latest DPC+ driver so that he can incorporate it in bB. If that happens, then the OP can try recompiling with the new version of bB and see if that makes any difference.

 

  • Like 1

Share this post


Link to post
Share on other sites
8 minutes ago, Karl G said:

Several DPC+ bB games have been produced with the same DPC+ code with no reports of any issues with Stella, so the problem being due to the older driver feels like a red herring to me.

That's entirely possible.  It could just be a coincidence that the code works with the old driver.  My point is that there are too many unknowns at this point.  It may not be Stella at all, and it just as easily could be.

8 minutes ago, Karl G said:

That being said, @RevEng has asked to be pointed to the latest DPC+ driver so that he can incorporate it in bB. If that happens, then the OP can try recompiling with the new version of bB and see if that makes any difference.

I have no idea where to get it.  I guess that would come from @batari?  I don't believe it's open source, so I don't think we can even look at the driver code to see how it works?  Someone else that did active development on DPC+ would have to speak up.  Perhaps @SpiceWare or @cd-w??

  • Like 2

Share this post


Link to post
Share on other sites
23 hours ago, stephena said:

That's entirely possible.  It could just be a coincidence that the code works with the old driver.  My point is that there are too many unknowns at this point.  It may not be Stella at all, and it just as easily could be.

I have no idea where to get it.  I guess that would come from @batari?  I don't believe it's open source, so I don't think we can even look at the driver code to see how it works?  Someone else that did active development on DPC+ would have to speak up.  Perhaps @SpiceWare or @cd-w??

 

I think only Fred (batari) has the DPC+ source code - I reverse-engineered parts of it for CDFJ, but don't know the differences between the minor DPC+ revisions.

 

Chris

  • Like 1

Share this post


Link to post
Share on other sites

Was playing this a bit on harmony cart . 

Couple of times I was able to move through walls , or was stuck in a wall , or would “teleport “ to different parts of walls . I will try to give a more specific example when I have more time to play

Share this post


Link to post
Share on other sites
On 3/6/2020 at 12:27 PM, stephena said:

That's entirely possible.  It could just be a coincidence that the code works with the old driver.  My point is that there are too many unknowns at this point.  It may not be Stella at all, and it just as easily could be.

I have no idea where to get it.  I guess that would come from @batari?  I don't believe it's open source, so I don't think we can even look at the driver code to see how it works?  Someone else that did active development on DPC+ would have to speak up.  Perhaps @SpiceWare or @cd-w??

 

No source here either, so don't know what changed.  

 

I do know the DPC+ jitter was added almost 5 years ago after I helped somebody with a specific bB game. It was a known issue for bB programmers, with a known workaround of setting DFxFRACINC registers before each drawscreen.

 

I tried the ROM in the initial post on my 2600, there was no jitter. Considering how long its been, seems likely the DPC+ driver version used in bB has changed.

 

I'll see if I can track down which game that was so we can compare the MD5 of that DPC+ driver with the one used for this game, though it'll be a few hours before I can look into it.

Share this post


Link to post
Share on other sites
55 minutes ago, SpiceWare said:

I do know the DPC+ jitter was added almost 5 years ago after I helped somebody with a specific bB game. It was a known issue for bB programmers, with a known workaround of setting DFxFRACINC registers before each drawscreen.

The changes you made in that link to CartDPCPlus.cxx are exactly what I was referring to above.  There is an older mask ($F0000) and a newer mask ($F00FF).  If I manually set the code to use the old mask, it works fine.  The default is to use the new mask, of course.

 

@SpiceWare, where did the idea come from to change this mask?  I always assumed it was because of a change in the DPC+ driver behaviour, but now I'm not sure what the actual logic was???

Share this post


Link to post
Share on other sites
5 hours ago, stephena said:

The changes you made in that link to CartDPCPlus.cxx are exactly what I was referring to above.  There is an older mask ($F0000) and a newer mask ($F00FF).  If I manually set the code to use the old mask, it works fine.  The default is to use the new mask, of course.

 

@SpiceWare, where did the idea come from to change this mask?  I always assumed it was because of a change in the DPC+ driver behaviour, but now I'm not sure what the actual logic was???

 

Don't recall where the idea came from, it was almost 5 years ago.  Change was done to match what was seen on real hardware when the DFxFRACINC registers were not updated in Doom Patrol.  I just finished doing some research that suggests Stella's DPC+ driver could be changed to this as there's actually 2 versions of Epic Adventure, one that runs on the Harmony Encore:

CartDPCPlus.cxx

string md5 = MD5::hash(image, 3_KB);
if(md5 == "8dd73b44fd11c488326ce507cbeb19d1" || md5 == "5f80b5a5adbe483addc3f6e6f1b472f8")
  myFractionalLowMask = 0x0F0000;

 

 

 

The Encore version uses the same driver that Space Rocks and Stay Frosty 2 use, so maybe it would make better sense to swap the mask values in the header and C files, then check for the DPC+ driver used in Doom Patrol.

CartDPCPlus.hxx

    uInt32 myFractionalLowMask{0x0F0000};


CartDPCPlus.cxx

  // DPC+ driver used in Doom Patrol 0.5 exhibits jitter on real hardware if the DFxFRACINC registers are not updated
  if(MD5::hash(image, 3_KB) == "17884ec14f9b1d06fe8d617a1fbdcf47")
    myFractionalLowMask = 0x0F00FF;


The research is in this blog post:

 

Share this post


Link to post
Share on other sites

well, another update....now the final maze, instead of becoming entirely visible when you have the Seer, i did a halo of light like in the original Adventure. I finally figured out how to do it. theres still one bug that I can't figure out...the Harp keeps going back to its original room when you drop it. Grr.

text_adventure.bas.bin

  • Like 1

Share this post


Link to post
Share on other sites

To optimize your source code, use one line when values are the same. 

 

Example: 

DF0FRACINC = 0: DF1FRACINC = 0: DF2FRACINC = 0: DF3FRACINC = 0

 

Not:

DF0FRACINC = 0 

DF1FRACINC = 0

DF2FRACINC = 0

DF3FRACINC = 0

 

It can save hundreds of bytes of ROM per bank. But this can make the source code harder to read when one line gets very long. 

 

This is something I wish the compiler would optimize.

The first way compiles to “load 0, store 0 in these registers”. 

The second way - the way everyone codes - compiles to “load 0, store 0, load 0, store 0, load 0, store 0, load 0, store 0”.

Share this post


Link to post
Share on other sites
3 hours ago, iesposta said:

To optimize your source code, use one line when values are the same. 

 

Example: 

DF0FRACINC = 0: DF1FRACINC = 0: DF2FRACINC = 0: DF3FRACINC = 0

 

Not:

DF0FRACINC = 0 

DF1FRACINC = 0

DF2FRACINC = 0

DF3FRACINC = 0

 

It can save hundreds of bytes of ROM per bank. But this can make the source code harder to read when one line gets very long. 

 

This is something I wish the compiler would optimize.

The first way compiles to “load 0, store 0 in these registers”. 

The second way - the way everyone codes - compiles to “load 0, store 0, load 0, store 0, load 0, store 0, load 0, store 0”.

Thanks!

Share this post


Link to post
Share on other sites
Found dasm version: DASM 2.20.12
Starting build of text_adventure2.bas
batari Basic v1.4 (c)2020
2600 Basic compilation complete.
--- Unresolved Symbol List
 
free ram: 0
DPC free RAM= 603
8 bytes of ROM space left in bank 1
3624 bytes of ROM space left in bank 2
522 bytes of ROM space left in bank 3
897 bytes of ROM space left in bank 4
3626 bytes of ROM space left in bank 5
3919 bytes of ROM space left in bank 6
885 bytes of ROM space left in graphics bank
 
text_adventure2.bas.asm (3876): error: Illegal Addressing mode 'bit '.
text_adventure2.bas.asm (3970): error: Illegal Addressing mode 'bit '.
text_adventure2.bas.asm (4064): error: Illegal Addressing mode 'bit '.
text_adventure2.bas.asm (4296): error: Illegal Addressing mode 'bit '.
 
Fatal assembly error: Source is not resolvable.
Build complete.
Cleaning up files generated during compilation...
 

Can someone tell me what this means and how to fix it?

Share this post


Link to post
Share on other sites

If you provide the source, either publicly or in the private message, I can take a look and see what I can figure out.

Share this post


Link to post
Share on other sites

Players 2 and up are virtual sprites, so they can't be used in collision statements.  You have a number of lines like this:

 

 if !collision(player2,ball) then goto skip_key2

 if !collision(player3,ball) then goto skip_gem2

 if !collision(player4,ball) then goto skip_lyre2

 if !collision(ball,player7) then goto no_hero

Changing these to player1 allows the code to compile.

Share this post


Link to post
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.

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