What's _scanLineCounterDelay ?

[nippur72]

I was trying to make the one single function cycle() for 6560 and 6561 and found that the only difference is this _scanLineCounterDelay found in 6560.

If I've understood well it's used to update the scanline counter with delay, but I wonder why it's not the same for 6561. I imagine they are the same chips differing only in register values, is that so?

    if (_scanLineCounterDelay-- == 0) {
      if (_scanLine==260) {
        registers[4] = 0;
        registers[3] &= 0x7F;
      } else {      
        registers[4] = (_scanLine + 1) >> 1;
        registers[3] = (registers[3] & 0x7F) | (((_scanLine + 1) & 1) << 7);
      }
    }

[matsondawson]

PAL and NTSC update thier scan line counter at different times. PAL is at
end of line, and NTSC is 32 cycles after end of line.
I think the two files are separated for performance, and because PAL and
NTSC were sufficiently different, e.g. scan line counter update time, ntsc
has linear mode, sound is also subtly different (PAL has an internal linear
feedback shift register on the channels, NTSC does not).
When I implement simulated PAL Television output, the code will differ as
well.

On 13 September 2014 21:29, nino-porcino notifications@github.com wrote:

I was trying to make the one single function cycle() for 6560 and 6561
and found that the only difference is this _scanLineCounterDelay found in
6560.

If I've understood well it's used to update the scanline counter with
delay, but I wonder why it's not the same for 6561. I imagine they are the
same chips differing only in register values, is that so?

if (_scanLineCounterDelay-- == 0) {
  if (_scanLine==260) {
    registers[4] = 0;
    registers[3] &= 0x7F;
  } else {
    registers[4] = (_scanLine + 1) >> 1;
    registers[3] = (registers[3] & 0x7F) | (((_scanLine + 1) & 1) << 7);
  }
}

—
Reply to this email directly or view it on GitHub
#6.

[nippur72]

didn't knew of the differences, unfortunately the documentation about the chips are scarce, what are your sources? I would like to learn more. I tried to look at VICE emulator, but didn't understand much.

And as for PAL mode, I have a suggestion. Make the vic-pixel render as 2x2 pixel in the canvas buffer when in fullscreen mode. This helps reduce the smoothness of the text. A 2x2 pixel could be also used to simulate scanlines (e.g. making odd rows 50% darker).

Are you going to emulate pixel tearing?

[matsondawson]

I have picked up stuff by testing the chip directly, reading the denial forums and guessing.
You can change the smoothness of the scaling using css.
If I went to 2x2 there'd be a big drop in performance as I have to write 4 x as many pixels in javascript.
I wonder if the scanline simulation could be done with an image overlay?

[nippur72]

not directly related but cool to see: cool-retro-term

BTW, one question: vic 20 has 184 (max 256) lines, but the PAL resolution is 512 lines, do you know how the VIC chip actually produces such resolution? Are scanlines doubled? Are they interlanced? it's not clear to me.

[matsondawson]

PAL has 625 lines split across 2 interlaced frames, (312.5 x 2)
Effectively the interlace doubles the scan lines.
Some of the lines are hidden offscreen hence the max resolution being less than 312.5
In my implementation I only draw one of the interlaced frames to save time.

[nippur72]

Ok, so the 6561 draws always the same image regardless of interlace resulting in "doubled" rows image. The only thing that I don't get is why I don't see any "ghost" image in a real VIC20. For example if you continuously flip background from black to white in theory you should be able to catch by eye "odd" and "even" lines (in a PAL machine). But I never noticed that. What I am missing?

[matsondawson]

I'm not sure, you should see the interlace. There's a demo around somewhere (I can't find it) that has double vertical resolution characters by using interlace. If you really wanted to test, a little machine code routine that waits for start of frame and toggles background color would be easiest.