JetSetIlly

Try upgrading the Go compiler to at least 1.16 (1.16.3 is the latest). The embed package is a recent addition.

I've updated Gopher2600 to use the new kernel if anyone wants to try it. https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.10.2

We can say that a ball reset is only ever *triggered* at a granularity of three TIA cycles. However, there is a delay *after the trigger* before the ball reset actually takes place. This is caused by the TIA itself and has nothing to do with the CPU. The length of this further delay varies but in most instances it is 5 TIA cycles. In practical terms, with careful programming, the effects of RESBL (ie. where the ball is drawn) can be seen at any color-clock (pixel) on the screen. I hope this helps.

They're still being made. Erica for the PS4 is a notable example.

Very good question. I don't know. I'm only surmising that it is set based on the bug that I fixed. My bug might have been more subtle, but I don't think so. Either way, it would be interesting to dig into the ROM.

The ball can be a different color to the players even in score mode. In scoremode the color of the ball is not changed - the playfield color changes to match the player of course, but not the ball. You can see this in the score mode/priority test ROM (using Stella in this instance). Debug colors: Real colors:

The candidate pixels at that point on the screen are from the background, player 1 or the ball.

Phew ?

New version with scoremode/priority fix: https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.10.1 @ZeroPage Homebrew Please can you test with Circus Convoy. Thanks.

Thanks for that. I've not seen the test ROM in the first post before. Interestingly, the ROM gives exactly the same output with the old code as it does with the fixed code. I think this is because the priority of the ball in score-mode is not being explicitly tested for. The second link I have seen. It was my misinterpretation of what was being said that caused the error. To summarise, I was changing the priority of the ball in scoremode if the priority bit was set. I'm fairly certain I have it solved now. Once it's confirmed that Circus Convoy outputs correctly, I'll create a specific test ROM to make sure I don't regress in future. Thanks for your help!

So, the ball had lowest priority on the right hand side of the screen but high priority on the left hand side of the screen. This is wrong and would account for what we see in the screen shot. I've changed it and it passes all regression checks. I'll wait for James to confirm that Score mode is enabled and post a new binary.

That's interesting. The ball has the lowest priority in score mode according to Stella. How on Earth did I miss that fact?! Haha @ZeroPage Homebrew Can you confirm that 'Score' mode is on at the point the Giraffe is being drawn?

Okay. Where in the source will it be do you think? on edit: TIA.cxx

Looking at my implementation. The ball will have priority over the player sprites when (a) the priority bit is set or (b) when scoremode is on and we're in the left hand side of the playfield. So either the priority bit is set or the scoremode is on for the bug to be visible. So either my priority assumption is wrong or the emulator thinks priority or scoremode is set when it isn't. I can't believe the latter, but I can believe the former. This is the code that decides pixel priority. As you can see, the TODO suggests I wasn't 100% happy but couldn't find any test cases that contradicted it. This is an "optimised" version (branches culled). The unoptimised version will be in the Github repository. I'll dig it out. Maybe I made a subtle mistake.

I agree. It does.

It does. The problem with Gopher2600 at the moment is that you can't flip to the debugger mode from the play mode. So you have to play the game in "debug mode" which is inherently slower because of the longer loop. But yes, it would be a help if @ZeroPage Homebrew could post a Stella screen shot with debug colors.

Yes. I was thinking that. The test binary attached to this Stella issue is the best test case I know of for priority issues and Gopher2600 passes that. https://github.com/stella-emu/stella/issues/58 I would guess the problem pixels are from the ball so I'm guessing it's something to do with that, possibly vertical delay as you say.

Thanks. It was a long shot but worth trying.

Interesting. I doubt it's anything to do with Superbank but you never know. One thing you could do is press F9. That will bring up the TIA revisions window. See if any of the options are selected. If there are you should unselect them. If they're already unselected, try toggling them in sequence to see if it has any effect. It's a long shot but it might give me a clue if it changes anything. But thanks for showing me that it works! That pleases me enormously ?

With the support of @rbairos I've added Movie Cart support to Gopher2600. Source and binaries can be found on my Github page https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.10 I've put a video of the Walter Cronkite demo movie on my YouTube channel. This should be watched in HD in order to get the full 60FPS. Watching in SD will cause the movie to play at 30FPS meaning you won't get the full effect. In addition to Movie Cart, I've fixed the Superbank bank-switching method. I don't have a copy of Circus Convoy to test that but hopefully someone can try it to see if it works. I've also tweaked how game pads works. Left thumb-stick now controls the joystick and not the paddle. This feels more natural to me and besides, I'm not convinced the narrow range of the stick is good for paddle control. The analogue triggers will still control the paddle but will no longer auto-center. Auto-centering made games like Night Driver too easy. Other control methods (ie. DPad, cursor keys for joystick and mouse for paddle) still work as before. There is also a nice icon set of icons that will be displayed briefly in the corner of the screen to indicate the control method has changed. The screenshot below shows the moment when the paddle has just been activated. Thanks again to @Al_Nafuur for help with the Windows binary. Much appreciated.

I was thinking that earlier but one of the general rules is that a demo can't have been released before. The showing on ZPH earlier this week might have disqualified it. But it would have been a strong contender for the win IMO. It might be worth @rbairos asking for a pass. Even if it's not eligible for a competition, that audience would love to see it.

That would be Jim Bagley who converted Dragon's Lair for the ZX81.

Fantastic. I wanted to have a crack at doing it myself so these are brilliant resources. Thanks.

I've had a quick look and I'm reasonably confident that it's something I can do but it'll take me some time. From what I can tell, it'll require me to write a full ARM and Thumb-2 decoder. Much of the logic in my Thumb implementation could be reused but even so, it's quite a bit of work to go through the Cortex-M4 documents. I've downloaded them and they're sat on my desktop to remind me ? I'll put it on the todo list but I don't know when I'll be able to get to it. I've got a lot of stuff that needs doing to get me to a version 1.0 release. I can start to think about it properly after that.

It works here on Gopher2600 with the keypad. I'm not familiar with the game but on game reset (F2) I can move the spaceship with left-player keypad. Q moves left and E moves right. 2 is "fire" and S is "drop". These correspond to keypad keys 4, 6, 2, and 8. Is this correct? If you try the latest version of Gopher2600 from the Github I've added some icons to the display that indicate when the controller input has changed, which might be useful in these types of instances. It should also work with the binaries tagged at v0.9. Nothing has changed recently.