Atari 2600

[NML32]

I will make new release - may be it will fix some found issues.

[slingshot]

Hi, Slingshot!

I have noticed the tittle screen in Juno First is totally wrong. Is that fixable somehow? Thanks!

Ahh, the game does a cycle-perfect write to the HMOVE register just when the TIA wants to reset it. This commit fixes the title:
https://github.com/gyurco/TCA2601/commi ... cb99476e48

[NML32]

Hi, Slingshot!

I have noticed the title screen in Juno First is totally wrong. Is that fixable somehow? Thanks!

Ahh, the game does a cycle-perfect write to the HMOVE register just when the TIA wants to reset it. This commit fixes the title:
https://github.com/gyurco/TCA2601/commi ... cb99476e48

It's great seeing the Atari 2600 getting updated.

[PhantombrainM]

Picture on Atari 2600 screen is generated by CPU. So this core is very depend on cpu cycle accuracy. That's why such thing as sound generation may affect the video. So, it's because current CPU model in this core is not perfect.

...or it just wasn't that obvious on the now 40 years old TVs. HSync is actually generated by TIA automatically, VSync is what's software triggered.
Btw, I don't see any problems with Winter Games. PAL/NTSC switch only changes the colors, the TIA doesn't have line counter.

Sorry for writing back lately.
I was busy the last days but I can check Atari 2600 on CRT too if needed in about 10 hours. (Sony PVM)
If MIST is "rock stable" on VGA at the mentioned games it might be a MISTer port problem or HDMI only problem.
I had it run on VGA last year but can't remember if the up down flickering was also there.
But since the OSD GUI shows that the resolution changes one up and down I think it's also present on VGA and not a HDMI problem.

[slingshot]

Sorry for writing back lately.
I was busy the last days but I can check Atari 2600 on CRT too if needed in about 10 hours. (Sony PVM)
If MIST is "rock stable" on VGA at the mentioned games it might be a MISTer port problem or HDMI only problem.
I had it run on VGA last year but can't remember if the up down flickering was also there.
But since the OSD GUI shows that the resolution changes one up and down I think it's also present on VGA and not a HDMI problem.

No problem. I only said Winter Games has no problem. There are a couple of games which don't produce a stable sync, but I don't know how they behave on a CRT.

[NML32]

Hi, Slingshot!

I have noticed the tittle screen in Juno First is totally wrong. Is that fixable somehow? Thanks!

Ahh, the game does a cycle-perfect write to the HMOVE register just when the TIA wants to reset it. This commit fixes the title:
https://github.com/gyurco/TCA2601/commi ... cb99476e48

Your suggested change also fixes graphics issues with Aardvark demo (Superchip).
http://atariage.com/forums/topic/259694 ... try4158730

[slingshot]

Unfortunately this breaks Pole Position's speedometer.
There are better fixes already, just want to test it more thoughtfully before I release.

[PhantombrainM]

No problem. I only said Winter Games has no problem. There are a couple of games which don't produce a stable sync, but I don't know how they behave on a CRT.

Okay, that's interesting. You were right. Winter Games is stable on analog TV. But the onscreen gui with display information is not!
On HDMI TV the screen is moving up and down to the sound of the title music. On analog CRT the picture is stable but the OSD is moving up and down.

So there's something going on on the digital picture side. Also some games are not in centre but okay on HDMI.

I made a video: https://www.youtube.com/watch?v=_3eNSF8xrkw

[slingshot]

Okay, that's interesting. You were right. Winter Games is stable on analog TV. But the onscreen gui with display information is not!
On HDMI TV the screen is moving up and down to the sound of the title music. On analog CRT the picture is stable but the OSD is moving up and down.

So there's something going on on the digital picture side. Also some games are not in centre but okay on HDMI.

I made a video: https://www.youtube.com/watch?v=_3eNSF8xrkw

I think the game creators didn't really think about an OSD or HDMI back in 1982
They just seen the game on a TV, and if it worked, then the quality check passed. Centering is also a speciality of A2600, if HMOVE is used, the left HBLANK automatically extended by 8 pixels (those are the spikes which you can see in many games).

[Sorgelig]

I think the game creators didn't really think about an OSD or HDMI back in 1982
They just seen the game on a TV, and if it worked, then the quality check passed. Centering is also a speciality of A2600, if HMOVE is used, the left HBLANK automatically extended by 8 pixels (those are the spikes which you can see in many games).

Why left side has black spikes only on some line? Can we improve the TIA to completely remove them?

[slingshot]

I think the game creators didn't really think about an OSD or HDMI back in 1982
They just seen the game on a TV, and if it worked, then the quality check passed. Centering is also a speciality of A2600, if HMOVE is used, the left HBLANK automatically extended by 8 pixels (those are the spikes which you can see in many games).

Why left side has black spikes only on some line? Can we improve the TIA to completely remove them?

That doesn't have to be improved It's the feature of the original hardware. When using HMOVE, HBLANK is shifted by 8 pixels, since with the original position, there's no time to make the full move (this is abused by some games, which sets up HMOVE at the point when it's resetted by the TIA, then there will be movement, but no spike. Of course it cannot use the full movement range then).
If it happens on some line only, then the game uses HMOVE only in those lines.
Look the Stella FAQ:
https://stella-emu.github.io/faq.html

[Sorgelig]

Well, i've implemented 64 sprites per line in TGfx16. It was impossible in original chip. Similar improvements may be possible for TIA. I mean, some original HW flaws possible to fix in modern HW.

[PhantombrainM]

Thank you for the updates. By the way, now Winter Games (HES, PAL) doesn't load anymore. (black screen).
Previous version was okay.

[slingshot]

Well, i've implemented 64 sprites per line in TGfx16. It was impossible in original chip. Similar improvements may be possible for TIA. I mean, some original HW flaws possible to fix in modern HW.

But nothing is supposed to be displayed in that first 8 pixels. If you replace the HMOVE blank with playfield, ball, or missile graphics, it may work in some games, but will look bad in others. And the other thing is authenticity, my thinking if some wants an improved A2600, then get an A5200.

[Sorgelig]

my thinking if some wants an improved A2600, then get an A5200.

yeah, or Genesis, or SNES..

[slingshot]

my thinking if some wants an improved A2600, then get an A5200.

yeah, or Genesis, or SNES..

Of course

But HMOVE blanks are part of the Atari 2600. Like the attribute clash on the Speccy.

[remowilliams]

Excellent, love to see this core getting improved

One thing I noticed - the difficulty switches seem to be backwards, A should be more difficult and B less difficult. Looking at Kaboom! for instance you should have large buckets on the B setting (not on the A setting as it is now)

Additionally I cannot seem to map the fire buttons on my Atari paddles. They are connected using a 2600daptor D9 (http://www.2600-daptor.com/2600-daptor%20D9.htm) which reports the paddles as X1/Y1 axes, and button1/button2 respectively.

The paddle movement is fine in the core, but I am forced to assign the actual paddle fire buttons to another device as the paddle fire buttons themselves are not picked up during remapping for some reason.

[Sorgelig]

Thank you for the updates. By the way, now Winter Games (HES, PAL) doesn't load anymore. (black screen).
Previous version was okay.

i will fix it

[Sorgelig]

Additionally I cannot seem to map the fire buttons on my Atari paddles. They are connected using a 2600daptor D9 (http://www.2600-daptor.com/2600-daptor%20D9.htm) which reports the paddles as X1/Y1 axes, and button1/button2 respectively.

The paddle movement is fine in the core, but I am forced to assign the actual paddle fire buttons to another device as the paddle fire buttons themselves are not picked up during remapping for some reason.

connect USB console and in Menu core you can see the log in console about pressed buttons. So check if buttons are producing press/depress events and button codes are different.
Also when you define the buttons for the core, they cannot be shared. So make sure you don;t define paddle buttons for other functions.

[Sorgelig]

One thing I noticed - the difficulty switches seem to be backwards, A should be more difficult and B less difficult. Looking at Kaboom! for instance you should have large buckets on the B setting (not on the A setting as it is now)

so you have large buckets in A which means more simple. B has smaller buckets which is harder. Shouldn't be B harder than A?

[PhantombrainM]

One thing I noticed - the difficulty switches seem to be backwards, A should be more difficult and B less difficult. Looking at Kaboom! for instance you should have large buckets on the B setting (not on the A setting as it is now)

so you have large buckets in A which means more simple. B has smaller buckets which is harder. Shouldn't be B harder than A?

According to Kaboom! User Manual no:

"6. Set difficulty switches at b(down) to begin.
.
.

9. Difficulty switches. With the difficulty switches in the b(down)
position, buckets are full size. With switches in the a(top)
position, buckets are half size(only advanced players should attempt
this setting). The left difficulty switch is used by the first
player, the right switch by the second player(Game 2 only)."

https://atariage.com/manual_html_page.p ... abelID=257


So Remowilliams seems right as long as the manual is correct

[Sorgelig]

no problem, I'll invert it.

[remowilliams]

connect USB console and in Menu core you can see the log in console about pressed buttons. So check if buttons are producing press/depress events and button codes are different.
Also when you define the buttons for the core, they cannot be shared. So make sure you don;t define paddle buttons for other functions.

Thanks, I've figured out how to get them properly mapped. The remaining issue now is that the paddles cannot reach the far right hand side of the screen at full right rotation.

These paddles are in good shape and work properly on a real 2600. They register (using the https://html5gamepad.com/ tester) from -0.994135 (full left) to 0.962854 (full right) along their rotation. Could there be a way to adjust for this?

[Sorgelig]

The remaining issue now is that the paddles cannot reach the far right hand side of the screen at full right rotation.

These paddles are in good shape and work properly on a real 2600. They register (using the https://html5gamepad.com/ tester) from -0.994135 (full left) to 0.962854 (full right) along their rotation. Could there be a way to adjust for this?

I need some test ROM for Atari 2600 to calibrate analog input properly.
Currently i calibrate on Breakout game which is probably not so good for this purpose.

[remowilliams]

I need some test ROM for Atari 2600 to calibrate analog input properly.
Currently i calibrate on Breakout game which is probably not so good for this purpose.

Correct, Breakout actually will reach the far right side currently. Try using Demons to Diamonds, Kaboom!, and Atari Circus to start, none of those will reach the right extent.