DirtyHairy Posted May 13, 2017 Share Posted May 13, 2017 (edited) 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 May 13, 2017 by DirtyHairy Quote Link to comment Share on other sites More sharing options...
Trebor Posted May 13, 2017 Share Posted May 13, 2017 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. Quote Link to comment Share on other sites More sharing options...
Trebor Posted May 13, 2017 Share Posted May 13, 2017 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. 2 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted May 13, 2017 Share Posted May 13, 2017 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. Out of curiosity: what glitch are you referring to? Is it already fixed? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 13, 2017 Share Posted May 13, 2017 Argh I updated BUS this morning as it had the same FastJump issue CDF did. My github status is this: 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: 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: 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. Quote Link to comment Share on other sites More sharing options...
Trebor Posted May 13, 2017 Share Posted May 13, 2017 Out of curiosity: what glitch are you referring to? Is it already fixed? Still present in Beta 7: *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. Quote Link to comment Share on other sites More sharing options...
Trebor Posted May 13, 2017 Share Posted May 13, 2017 Posting a couple of captures from the right-side under the Woody: 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: 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: 1 Quote Link to comment Share on other sites More sharing options...
Keatah Posted May 13, 2017 Share Posted May 13, 2017 I've only noticed 2 right-side glitches. They're present in old and new Stella. Can't speak for real hardware though. 1 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted May 13, 2017 Share Posted May 13, 2017 (edited) 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 Edited May 13, 2017 by DirtyHairy 1 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted May 13, 2017 Share Posted May 13, 2017 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 13, 2017 Share Posted May 13, 2017 (edited) I am not sure if it s true for all Pole Position glitches, but at least most of them can be reproduced on real hardware. Edited May 13, 2017 by Thomas Jentzsch 2 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 13, 2017 Share Posted May 13, 2017 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. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted May 13, 2017 Share Posted May 13, 2017 (edited) 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. 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 May 13, 2017 by DirtyHairy Quote Link to comment Share on other sites More sharing options...
Trebor Posted May 13, 2017 Share Posted May 13, 2017 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 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. 1 Quote Link to comment Share on other sites More sharing options...
+stephena Posted May 13, 2017 Author Share Posted May 13, 2017 Spice, I just went ahead and committed this. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 14, 2017 Share Posted May 14, 2017 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). Quote Link to comment Share on other sites More sharing options...
+stephena Posted May 14, 2017 Author Share Posted May 14, 2017 Sorry, you sounded stressed out and running out of time, so I went ahead and did the commit. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted May 14, 2017 Share Posted May 14, 2017 (edited) 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 . Edited May 14, 2017 by DirtyHairy Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 14, 2017 Share Posted May 14, 2017 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). Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 14, 2017 Share Posted May 14, 2017 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 .Here's one of the kernels, the TIA writes are in gold though one of them is hidden in the DIGITAL_AUDIO macro: 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. 1 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted May 14, 2017 Share Posted May 14, 2017 (edited) 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 May 14, 2017 by DirtyHairy Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 14, 2017 Share Posted May 14, 2017 Pretty much. This kernel's used the most, it's for the scanlines that nothing needs to be repositioned on: The very last scanline of the gameplay area jumps to this, which draws the condition/score/radar/lives/formation: 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... Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted May 16, 2017 Share Posted May 16, 2017 It's rather similar in concept to what's going on in Galaxian: Interesting stuff. I'm looking forward to playing around with this at some point. As for the Galaxian trick: for which part of the display are you using this one? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 16, 2017 Share Posted May 16, 2017 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: score horizontal line at top attack area between formation and player player area horizontal line at bottom lives/level Quote Link to comment Share on other sites More sharing options...
+stephena Posted May 24, 2017 Author Share Posted May 24, 2017 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. 3 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.