Jump to content
IGNORED

Testing the new Stella TIA core


stephena

Recommended Posts

Certainly, I am no expert in all the above games by any stretch of the imagination, but still give each title a good play through for a least a few minutes to see if anything is wrong. Looking most excellent, gents...Fantastic work!

Wow, thanks alot for all the work that's hidden in this massive list of testcases!

Edited by DirtyHairy
Link to comment
Share on other sites

Wow, that's a huge list and a pretty massive test effort.

 

On Github, we have labeled quite some issues as "Regression". Mostly games plus a few test ROMs are defined for those regression tests. Maybe you want to have a look at this list first?

 

I have seen the "issues" list and check it before about to report something.

It's the reason I did not make mention of the PP graphic glitch on the lower left side that I noticed while testing.

Link to comment
Share on other sites

Wow, thanks alot for all the work that's hidden in this massive list of testcases!

 

You're welcome. It would be nothing, if not for what you, Thomas, Stephen, Darrell, and company have done and continue to do.

 

I know I'm not going to catch everything that may appear, and again, no expert in most (all?) of those games; however, the more eyes looking at stuff, the better. :)

  • Like 2
Link to comment
Share on other sites

Argh

 

I updated BUS this morning as it had the same FastJump issue CDF did. My github status is this:

post-3056-0-80019900-1494692671_thumb.png

 

I quit Xcode, did the 3 commands in Terminal like before:

git stash
git pull --rebase stella-emu master
git stash pop

Then launched Xcode and did the Source Control->Commit to find that Xcode is not happy:

post-3056-0-68024000-1494692814.png

 

Now Xcode acts like I've committed my changes (if I try to commit again the BUS files don't show up). I checked the last few commits to stella-emu, like this one, and confirmed I have them locally:

post-3056-0-77798900-1494693220_thumb.png

 

So I believe everything's set up correctly in my local git repository, but that I'm going to need additional Terminal commands to send everything up to my github repository. Ah well, need to head out for lunch and run some errands.

Link to comment
Share on other sites

Out of curiosity: what glitch are you referring to? Is it already fixed?

 

Still present in Beta 7:

 

post-18-0-29689300-1494696695.pngpost-18-0-60395900-1494696695.pngpost-18-0-88057100-1494696695.png

post-18-0-25914800-1494696696.pngpost-18-0-88100800-1494696696.pngpost-18-0-38415200-1494696697.png

 

*EDIT: And the above actually mimics real hardware behavior. Don't know how I missed it on the real deal previously, but just gave it another whirl on my Woody system and sure enough it occurs there too. Interestingly, I had it happen on the right side on a few occasions as well, but don't recall seeing that happening with Stella.

 

It may just be cropping difference, but now I want to try and see if I can reproduce similar on the right side under Stella.

 

Back-tracing to where I thought a mention of it occurs with the issues list, I came from this posting; specifically the chunk of dialogue quoted below:

 

"I didn't fix it at all In 6502.ts, CPU emulation is currently not sophisticated enough to do anything like this. In particular, all reads required for decoding the instruction happen in the first cycle, and all reads and writes required by the instruction itself happen in the last cycle (this is the reason while Pole Position is glitched in 6502.ts). As the CPU in 6502.ts is dispatched cycle by cycle, properly emulating memory access patterns would require turning every instruction into a state machine. Doing this would make the implementation of this particular edge case trivial, but the required changes are pretty invasive."

 

My brain must have honed-in on the portion I placed in bold...lol.

Link to comment
Share on other sites

Posting a couple of captures from the right-side under the Woody:

 

post-18-0-35349500-1494700090.pngpost-18-0-04295500-1494699728.png

post-18-0-12668200-1494699733.pngpost-18-0-79913200-1494699735.png

 

The above, especially just below the mountains, is where the line glitch is often evident. But it occurs further down too, as seen in the third capture above.

 

Additionally, below (Although perhaps not as easy to notice), I took a couple of captures where it is clear the red and white track outline extends beyond the overall gray road endpoint. Under Stella, the track outline always appears flush with the road. Under the Woody, it appears the road outline extends one-two vertical scanlines beyond the surface. This does not appear to be color bleed:

 

post-18-0-45710700-1494699729.pngpost-18-0-59894600-1494699730.png

 

The road outline issue is perhaps just cropping differences, but that right side glitching never seems to occur under Stella.

 

Here's the video I took and the source of the above captures; viewing full screen is likely best to notice the items, but turning down the audio is advisable, my wife is watching Krampus while I am recording the footage from my phone:

 

https://www.youtube.com/watch?v=esWoW0PPnD8

 

Note the "blackout" at the edge of track outline. It may appear while racing or after a reset, but at the start of the first game before the race begins, that also is absent from Stella:

 

post-18-0-95760900-1494701248.png

  • Like 1
Link to comment
Share on other sites

 

Back-tracing to where I thought a mention of it occurs with the issues list, I came from this posting; specifically the chunk of dialogue quoted below:

I suspected as much :) The issue is soleley with 6502.ts: if you check out PP there, you'll find that the track is shifted hoizontally relative to the car --- that's the consequence of timing inaccuracies in the CPU emulation.

 

Regarding your finding with the two-pixel gitching on the right side: I am not sure. I can reproduce this in Stella reliably (happens around 50 into the game or so), but I _think_ it looks slightly different from your recording. However, this is hard to tell as this also depends on your driving style, so who knows. I checked the PAL version on my Jr. vs. Stella, and there the glitching happens slightly earlier AND seems to be identical between hardware and emulation. However, as I said, that's very hard to tell; there might as well be a real difference there.

 

If there is a difference, then this is likely related to positioning and size changes during draw / decode of missiles and ball. While I am not aware of any other real-world issues relating to this, there is still potential for improvement there.

 

The other glitches Keatah sees (black lines on the right track boundary and the wrapping of the left boundary to the right side) are present on my Jr., too.

 

All in all, from comparing my own Jr. to Stella I wouldn't suspect any difference, but there is so much glitching going on (depending on your driving) that I find it impossible to be sure :P

Edited by DirtyHairy
  • Like 1
Link to comment
Share on other sites

So I believe everything's set up correctly in my local git repository, but that I'm going to need additional Terminal commands to send everything up to my github repository. Ah well, need to head out for lunch and run some errands.

I can only guess what XCode is complaining about, but you can push your changes to your github repo by doing

git push

As there is no concept of a sever in git, your local copy is a full-fledged git repo, and any commits that you make are local to this repository (including those that you pulled in during rebase). That's why pushing those changes to the remote repository is required as an additional step --- it is also the only step that treats your github repository as the remote server.

 

If you still run into issues with XCode after pushing, you can do

git status

to see whether there are any uncommited local changes. You can also use

git log

to see your local commit history.

Link to comment
Share on other sites

git push

To https://github.com/SpiceWare/stella.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/SpiceWare/stella.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

 

git status

git status
On branch master
Your branch and 'origin/master' have diverged,
and have 5 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
Untracked files:
  (use "git add <file>..." to include in what will be committed)
 
.DS_Store
src/.DS_Store
src/debugger/.DS_Store
src/emucore/.DS_Store
src/macosx/.DS_Store
src/macosx/M6502.ins
src/macosx/stella.xcodeproj/project.xcworkspace/
src/macosx/stella.xcodeproj/xcuserdata/
 
nothing added to commit but untracked files present (use "git add" to track)

git log

commit b604755ef030d015669ba5d07e56fdff073b998a
Author: Darrell Spice, Jr <darrell.spice.jr@spiceware.org>
Date:   Sat May 13 11:14:29 2017 -0500

    Update to BUS FastJump
    Revised BUS so "false" reads after NOPs, taken branch instructions, etc. no longer crash JMP FASTJMP

commit 78cb21d7983e6406c3ad266540ac4ffb6dc5e196
Author: Stephen Anthony <sa666666@gmail.com>
Date:   Fri May 12 18:12:32 2017 -0230

    Fixed PAL color-loss effect bug when the ROM always has an odd # of lines.

commit 73fe5f3b404a214f1e1844b9b226584efa0124b2
...

At this point I'm sick of fighting with this. Here's the 2 files for the BUS FastJump fix, it's basically the same as yesterday's CDF fix

CartBUS.zip

 

I'm going back to work on Draconian, I'm now way behind where I expected to be and am concerned I won't be able to finish it in time for PRGE.

Link to comment
Share on other sites

At this point I'm sick of fighting with this. Here's the 2 files for the BUS FastJump fix, it's basically the same as yesterday's CDF fix

attachicon.gifCartBUS.zip

 

I'm going back to work on Draconian, I'm now way behind where I expected to be and am concerned I won't be able to finish it in time for PRGE.

I guess what has happened is that the rebase has replayed commits that you had already pushed to your own fork on github. Rebasing basically discards the old commits and recreates them, but there is no way for git to identify them with their old versions, so it claims that there are "new" commits in your github repo.

 

As you're the only person committing there, you can just do a forced update

git push --force

This will forcefully update the remote repository to match your local version. You can avoid this this kind of issue by always rebasing on stella-emu/stella before pushing to your github fork.

 

After the force push, you should be able to open the pull request just fine. However, I know from personal suffering that this kind of issue can be pretty nauseating when starting out with git; if you like, I can just merge in those changes from the zip above :)

Edited by DirtyHairy
Link to comment
Share on other sites

All in all, from comparing my own Jr. to Stella I wouldn't suspect any difference, but there is so much glitching going on (depending on your driving) that I find it impossible to be sure :P

 

Among the above with aforementioned screen (and perhaps even slight console (variation) video output/timing) differences, coupled coming across the earlier comments, is why I didn't bother reporting it from the get-go; nonetheless, further confirmation is reassuring and brings peace of mind, thank you.

 

Great job and keep up the awesome work, everyone. :)

  • Like 1
Link to comment
Share on other sites

Thanks! I tried the git push --force yesterday and it appears to have worked correctly, however I didn't notice that stephena had already committed the update so now I have a conflict.

 

I'm going to leave it be for now as I'm in the middle of the kernel rewrites for Draconian - there's 58 kernels for the game screen: 55 reposition kernels, a normal kernel (scanlines where nothing's being repositioned), an exit kernel, and finally the score/radar/etc kernel. With the new FastJump feature I'm now making up to 15 TIA writes per scanline in the gameplay area. 13 for normal kernel (includes a WSYNC), and 15 for reposition kernels(do not have a WSYNC).

Link to comment
Share on other sites

Thanks! I tried the git push --force yesterday and it appears to have worked correctly, however I didn't notice that stephena had already committed the update so now I have a conflict.

:) That's unavoidable I guess. You can recover when you get back to Stella development by hard resetting your repository to the upstream master:

git fetch stella-emu
git reset --hard remotes/stella-emu/master
git push --force

The "git fetch" will pull in all commits from upstream without touching your local branch head (that's the pointer that tracks the most recent commit in a branch). "git reset --hard" then resets the branch head to the latest commit in the upstream master (discarding any commits that are not part of upstream). At this point, your local master branch is identical to the upstream master, and the force push propagates this to your upstream repo. This gives you a clean start.

 

I'm going to leave it be for now as I'm in the middle of the kernel rewrites for Draconian - there's 58 kernels for the game screen: 55 reposition kernels, a normal kernel (scanlines where nothing's being repositioned), an exit kernel, and finally the score/radar/etc kernel. With the new FastJump feature I'm now making up to 15 TIA writes per scanline in the gameplay area. 13 for normal kernel (includes a WSYNC), and 15 for reposition kernels(do not have a WSYNC).project

Have fun! 15 TIA writes is pretty impressive, I guess that's the absolute limit for what you can realistically do without bus stuffing. I'd like to try my hands on an ARM based project myself when I find time. In case this ever happens I'll give CDF a spin :P.

Edited by DirtyHairy
Link to comment
Share on other sites

No worries, I was.

 

I think everything's where they need to be for now for BUS and CDF, so I'm taking a break from Stella until I finish Draconian. Then I'll be able to figure out git without being pressed for time. If something comes up before then that I need to fix I'll just send you the updated file(s).

Link to comment
Share on other sites

:) That's unavoidable I guess. You can recover when you get back to Stella development by hard resetting your repository to the upstream master:

Thanks! I'll be sure to do that before I next work on Stella :)

 

Have fun! 15 TIA writes is pretty impressive, I guess that's the absolute limit for what you can realistically do without bus stuffing. I'd like to try my hands on an ARM based project myself when I find time. In case this ever happens I'll give CDF a spin :P.

Here's one of the kernels, the TIA writes are in gold though one of them is hidden in the DIGITAL_AUDIO macro:

post-3056-0-57467600-1494796223_thumb.png

 

DS_BALL, DS_MISSILE0, and DS_MISSILE1 use the upper nybble for the HMxx register, lower nybble for the ENAxx register. That lets me save RAM by using 10 datastreams instead of 13. At first glance it looks like I'm only using 9 streams (as there's 9 LDA #), the 10th stream is used by JMP FASTJMP.

  • Like 1
Link to comment
Share on other sites

Here's one of the kernels, the TIA writes are in gold though one of them is hidden in the DIGITAL_AUDIO macro:

 

Interesting. Does this mean that you are potentially using a separate kernel for every line and use the jump stream to chain them in the desired order?

Edited by DirtyHairy
Link to comment
Share on other sites

Pretty much. This kernel's used the most, it's for the scanlines that nothing needs to be repositioned on:

post-3056-0-34239300-1494802170_thumb.png

 

The very last scanline of the gameplay area jumps to this, which draws the condition/score/radar/lives/formation:

post-3056-0-76140100-1494802294_thumb.png

 

It's rather similar in concept to what's going on in Galaxian:

Subject: [stella] The Multi-Sprite Trick

From: Christopher Tumber <christophertumber@xxxxxxxxxx>

Date: Fri, 12 Sep 2003 18:33:46 -0400

...

This trick is quite easy to use to generate static displays. However, if you want a fully dynamic display things get considerably more complicated.

 

Since there is no time available while drawing the sprites to do any calculations, if you want a variable number of sprites on and off you must predetermine which sprites to display. A simple way to do this is to create a subroutine for every possible combination of on/off sprites. Then your program just needs to call the appropriate subroutine (this is what Galaxian does). The problem with this approach is that if you have a lot of sprites, the number of subroutines becomes very large.

...

Hmm - see an issue in ExitKernel. When the CPU gets there TIA's holding the info to draw the last scanline of gameplay area. As such RESP0 and RESP1 could be in use, so the RESP0 and RESP1 would probably mess up an object on the bottom right of the screen...

Link to comment
Share on other sites

As for the Galaxian trick: for which part of the display are you using this one?

 

not the multiple copy trick, the calculated chaining together of a large number of kernels.

 

I've never looked into it, but based on what Christopher Tumbler wrote there'd be 2^7 = 128 kernels just for the formation area as there's 7 players that are on/off in each row of the formation. There's probably 6 additional kernels for the game screen:

  1. score
  2. horizontal line at top
  3. attack area between formation and player
  4. player area
  5. horizontal line at bottom
  6. lives/level
Link to comment
Share on other sites

I'm getting ready to do the final 5.0 release in a few weeks (perhaps by mid June, but preferably no later). To any testers reading this, now is the time to report any remaining regressions from 4.7.3. To developers, now is the time to finish up anything you're working on, and it it can't be finished, push it to post-5.0.

 

There are still about 25 open issues on the Stella git page (and over 100 closed), but most of them are nice-to-have's and not holding up a new release. I hope to eliminate one or two of them before the final release, but as it stands, what was in pre7 is basically going to be the 5.0 release.

  • Like 3
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...