original scan of Stella Programmer's Guide?

[+SpiceWare]

@ckrtech is continuing his research into the VSYNC issue with Battlezone and found what appears to be a typo in the MiniDig version of Stella Programmer's Guide:

 

 

we think both should say "3 scanlines". He found an older version via the Internet Archive that has 3 scanlines for both, which would back that up (though it has other typos like writting with 2 Ts)

 

 

So we're curious if anybody's seen an original scan of the guide?

[Omegamatrix]

I believe the original is the same as the one found on the internet archive.

 

The one on the Atari Museum looks the same.

 

http://www.atarimuseum.com/ahs_archives/archives/pdf/videogames/2600/2600_Guide.pdf

 

 

[Thomas Jentzsch]

I am pretty sure this must by a typo when converting which looks like the original.

 

 

[+SpiceWare]

For those interested in the results of @ckrtech's research:

 

 

[+ZeroPage Homebrew]

30 minutes ago, SpiceWare said:

For those interested in the results of @ckrtech's research:

 

Excellent video! It should be recommended viewing for all new developers wanting to program for the 2600 to ensure compatibility with modern equipment. Over the years I've tried to broadcast numerous 2600 homebrew games through my Framemeister and encountered screen blanking due to the things discussed in the video. Luckily I've found that more and more 2600 homebrew programmers are now more careful to avoid these issues. ?

 

- James

[+Andrew Davie]

... and yet a part of me doesn't care about running on modern equipment. If it works on (say) 98% of CRTs, then that's period-correct.

Part of the toolkit for a retro programmer is varying the frame to a "non-standard" (e.g., 276 scanlines has been commonly used) which we know most CRTs are able to handle. Should we be avoiding these modes because/if a "modern" frame grabber/TV signal processor cannot handle them?

I'm in the "no" camp. They are, to me, perfectly valid period-appropriate solutions used by programmers BITD.

Edited June 22, 2021 by Andrew Davie

[Thomas Jentzsch]

52 minutes ago, Andrew Davie said:

I'm in the "no" camp. They are, to me, perfectly valid period-appropriate solutions used by programmers BITD.

From authenticity perspective, I tend to agree here. 

 

But then you have to realize and accept that more and more people do not have or use authentic equipment. So by staying strictly authentic, you limit your target group. And because @ZeroPage Homebrew is streaming homebrews and YouTube videos are at fixed 60Hz (e.g. Star Castle Arcade looks horrible for both), the problem of a game with modern hardware becomes very obvious.

Edited June 22, 2021 by Thomas Jentzsch

[+SvOlli]

To put my two cents into one sentence: it was okay back then, but today one should be ashamed of not using 262 or 312 lines. Especially with Stella to help you accomplish this. There might be reasons like tape loading or sampled music that requires to drop VSYNC completely, but otherwise I consider it a stupid beginner's mistake.

 

In the demoscene there are now some people who are also trying to use the 2600 for a quick product (compofiller) in an emulator or online dev environment. When it looks good there, it will be released. The best example is CoRoBars which looks nice in an emulator and like goat barf on real hardware.

 

@ZeroPage Homebrew : Could you please run a quick test with my 32 bytes demo hard2632? During development, @Thomas Jentzsch and I were discussing if using just VSYNC is enough, of if VBLANK is also required for having a correct display. We settled for "if you do it in 32 bytes, there will be no space left for a demo effect".  But it would be very nice to have a second opinion by the Framemeister.

[Thomas Jentzsch]

17 minutes ago, SvOlli said:

...today one should be ashamed of not using 262 or 312 lines. Especially with Stella to help you accomplish this.

It is more about which scanlines you are aiming for than missing your target. The latter is shameful, agreed.

 

But there are lots of valid reasons to intentionally increase the scanline count, e.g. more displayed lines or more CPU time for complicated calculations. Especially if your game does not use flicker, increased scanlines are almost always an improvement. And if you have to flicker, a decreased number reduces the flicker.

 

The problem is the modern hardware which is much less flexible than good old CRTs the 2600 was made for.

[+SpiceWare]

2 hours ago, Thomas Jentzsch said:

But there are lots of valid reasons to intentionally increase the scanline count, e.g. more displayed lines or more CPU time for complicated calculations.

 

An example would be the holiday cart Stella's Stocking. It uses 264 scanlines due to the divisible by 4 requirement of @supercat's Better-Than-Pitfall-II music routine that's used for the menu music. All the games used 264 scanlines to prevent screen jitter/jump when transitioning between the menu and a game.

 

BTP2 - note: need to turn off Developer mode in Stella

 

 

Stay Frosty:

 

Grandma's Revenge

[+ZeroPage Homebrew]

7 hours ago, SvOlli said:

To put my two cents into one sentence: it was okay back then, but today one should be ashamed of not using 262 or 312 lines. Especially with Stella to help you accomplish this. There might be reasons like tape loading or sampled music that requires to drop VSYNC completely, but otherwise I consider it a stupid beginner's mistake.

 

In the demoscene there are now some people who are also trying to use the 2600 for a quick product (compofiller) in an emulator or online dev environment. When it looks good there, it will be released. The best example is CoRoBars which looks nice in an emulator and like goat barf on real hardware.

 

@ZeroPage Homebrew : Could you please run a quick test with my 32 bytes demo hard2632? During development, @Thomas Jentzsch and I were discussing if using just VSYNC is enough, of if VBLANK is also required for having a correct display. We settled for "if you do it in 32 bytes, there will be no space left for a demo effect".  But it would be very nice to have a second opinion by the Framemeister.

 

I recorded both CoRoBars and hard2632 through my setup and they both look pretty good to me! I can't really find an appreciable difference between the look through Stella and running on real hardware.

 

- James

 

[NOTE: SET TO 1080P60 FOR FULL QUALITY!]

 

Edited June 22, 2021 by ZeroPage Homebrew

[orange808]

There are two high end video game scalers in the pipeline (the PixelFX Morph and marq's OSSC Pro).  We should be able to lobby better support for the VCS from one or both of those machines after they hit the market--at the expense of a small amount of latency.  I haven't gotten a Retrotink5x yet, but it's possible that Mike Chi may be willing to help out as well.  I partially agree with Andrew.  Good video scalers should be bridging the gap. Valid CRT signals should work on digital displays, versus coming up with hacks of existing software or putting strict requirements on development.  That can be done and it doesn't require nearly as the amount of latency (usually a full frame of more) that most "seamless" switching video scalers use, because the VCS signal remains within a small range.

[Thomas Jentzsch]

Cool, though better scalers would help for your home equipment only, but not solve the streaming and YouTube issues. 

Edited June 22, 2021 by Thomas Jentzsch

[orange808]

34 minutes ago, Thomas Jentzsch said:

Cool, though better scalers would help for your home equipment only, but not solve the streaming and YouTube issues. 

Why?  I don't follow.  Streaming is already a pretty easy fix, because the latency on the streaming feed doesn't matter much.  Feed the local CRT directly from the matrix switch and knock the stream feed through a seamless scaler before the capture card.

[Thomas Jentzsch]

The problem is, that the frequency is fixed to 60Hz (or for YouTube sometimes 30Hz). So if your game runs at e.g. 59Hz, every 60 frames a frame has to be duplicated. If the game uses flicker or fast movements, this is very noticeable.

[orange808]

11 hours ago, Thomas Jentzsch said:

The problem is, that the frequency is fixed to 60Hz (or for YouTube sometimes 30Hz). So if your game runs at e.g. 59Hz, every 60 frames a frame has to be duplicated. If the game uses flicker or fast movements, this is very noticeable.

First option would be to adjust your output rate to be as close to the dominant input frame rate. The tearing or studdering will be minimized.  Plenty of options to do this, but it will require a little setup.  Probably best to cook up a rom that sweeps a "192 line" tall, eight color clock wide white missile from side to side--and uses the joystick to toggle the amount of scanlines.  Should be able to dial in the best settings (for different situations) doing that.  Might also add an interlaced option.  Maybe I'll make one of those.

 

Could also try running the video processor output at 120Hz and letting capture card software interpolate frames down to 60.

 

Ultimately, though, a few hiccups don't matter much on a stream.  It's really only a big deal on the "gaming" screen.

 

Better scalers solve the problem entirely, because less than a frame of latency doesn't really matter much--and that's probably enough to maintain sync and frame lock with such a small window of variance.  Right now, we can't get a decent frame lock and small buffer together, but I think it can be done--and the artifacts won't be very noticeable.

 

Edited June 23, 2021 by orange808

[+SvOlli]

On 6/22/2021 at 8:11 PM, ZeroPage Homebrew said:

I recorded both CoRoBars and hard2632 through my setup and they both look pretty good to me! I can't really find an appreciable difference between the look through Stella and running on real hardware.

Thanks.

 

The video helped me to get a quite some understanding. My problems with CoRoBars were experienced on a PAL machine, so that "bad linecount" by not being constant in the up vs down movement does not make the video "trip" on NTSC as it does on PAL. And it's also good to know that the hard2632 technique does also work. That's knowledge will be handy when hacking up a 32 byte demo or even on a 256 bytes demo.