NTSC raster problem

[TBCVIC]

I'm doing some raster tricks, like raster bars, for my new game.
I want my game to work equally well on PAL as on NTSC machines, but
for some reason, I'm having some trouble getting it to work on NTSC,
at least in VICE.
Check out this little code snippet:

Code: Select all

	lda #30
wait:
	cmp $9004
	bne wait

It waits for the raster register to become 30.
In PAL, if I for example change the background color right after,
it will change far left on that line as expected.
In NTSC though, it doesn't change the background color until in the
middle of the screen.
I'm not sure if this is a VICE problem or something else, because I
have no real NTSC machine to test on.

Anyone got an idea?

Here's a complete program to test with:

Code: Select all

	sei
	lda #0
	sta $9002
loop:
	ldx #9
	lda #30
wait:
	cmp $9004
	bne wait
	stx $900f
	lda #0
wait2:
	cmp $9004
	bne wait2
	lda #8
	sta $900f
	jmp loop

Binary for unexpanded Vic-20: TEST.P00

[TBCVIC]

If anyone could test this program on a NTSC Vic-20 I would be very happy.
RASTER.P00
This is how it looks in VICE:
PAL

NTSC

[Mike]

Even though I don't own an NTSC VIC, I dug into the VICE sources. Apparently the VIC-6560 indeed changes the raster counter mid-line.

There are some definitions in '/src/vic20/vic20.h' which shed light on this:

Code: Select all

#define VIC20_PAL_CYCLES_PER_SEC        1108405
#define VIC20_PAL_CYCLES_PER_LINE       71
#define VIC20_PAL_SCREEN_LINES          312
#define VIC20_PAL_FIRST_DISPLAYED_LINE  28
#define VIC20_PAL_LAST_DISPLAYED_LINE   311
#define VIC20_PAL_CYCLE_OFFSET          0

and

#define VIC20_NTSC_CYCLES_PER_SEC       1022727
#define VIC20_NTSC_CYCLES_PER_LINE      65
#define VIC20_NTSC_SCREEN_LINES         261
#define VIC20_NTSC_FIRST_DISPLAYED_LINE 8
#define VIC20_NTSC_LAST_DISPLAYED_LINE  260
#define VIC20_NTSC_CYCLE_OFFSET         37

... and me thinks the VICE guys didn't include the different values for the VIC20_%_CYCLE_OFFSET for no good reason.

In 'vic-mem.c' the raster register is read thus:

Code: Select all

BYTE REGPARM1 vic_read(WORD addr)
{
    addr &= 0xf;

    switch (addr) {
      case 3:
        return ((VIC_RASTER_Y(maincpu_clk + vic.cycle_offset) & 1) << 7)
               | (vic.regs[3] & ~0x80);
      case 4:
        return VIC_RASTER_Y(maincpu_clk + vic.cycle_offset) >> 1;
      case 6:
        return vic.light_pen.x;
      case 7:
        return vic.light_pen.y;
      default:
        return vic.regs[addr];
    }
}

... where vic.cycle_offset has been initialised from either of those defines given before, within 'vic.c', in the function 'void vic_change_timing(void)'.

Greetings,

Michael

[Unseen]

I think you're trusting that code more than the people who wrote it...

[Mike]

I think you're trusting that code more than the people who wrote it...

Could you post a more constructive comment, maybe even a screenshot of TBCVIC's program running, in case you own an NTSC VIC?

[matsondawson]

Yep, I have big problems with NTSC raster changing in the middle of the screen on Atalantis in my emulator, and havn't been able to work out what I'm doing wrong.
It'd be great if someone could figure out exactly when the raster changes on NTSC. I have worked it out that for PAL it changes at the end of the previous line, before the horizontal blank.

[Wilson]

It's not a problem with VICE. I just tested it on my NTSC vic and it looked just like the screenshot you posted.

[Jeff-20]

Do you think raster tricks could be pulled off in basic?

[Mike]

You could always try something like this:

Code: Select all

1 A=36879:B=36868:C=64
2 WAITB,C,C:POKEA,8:WAITB,C,.:POKEA,25:GOTO2

But that has little more than a curiosity value.

[carlsson]

Another idea is to make a hybrid program, i.e. an IRQ extention in machine code which handles the raster trick(s) while your Basic program keeps running.

Anyway, I have invited TBC to my home tomorrow. We will see if he can make it. At least I am one of the few people in this world to own a NTSC VIC-20 so we can do some testing.

[Mike]

Then TBCVIC should expand the test program in the way, that the letters of the ABC are displayed above or below the raster bar:

Code: Select all

                  -------------
ABCDEFGHIJKLMNOPQRSTUV

... so that the cycle exact position can be judged not from eye alone.

[TBCVIC]

Thx, guys. I'll trust the VICE for now then and see if I can make further tests on carlsson's Vic-20.

[TBCVIC]

I took you excellent suggestion Mike, and did a new version of my test program. Here it is:
RASTER2.P00

It looks like this in VICE and NTSC:



The nice thing is we can check if VICE is really correct this way. Hopefully the developers of VICE has already done it this way or something similar.

[Unseen]

Could you post a more constructive comment, maybe even a screenshot of TBCVIC's program running, in case you own an NTSC VIC?

I don't own an NTSC VIC, but maybe you consider it constructive that there are a few test programs in the VICE SVN. Unfortunately they are only for PAL and nobody has stepped forward to test/port/adapt/rewrite them for NTSC, including tests on a real machine so the VICE devs know what they should look like.

[a1bert]

In NTSC though, it doesn't change the background color until in the middle of the screen.

For some reason NTSC really changes the raster counter in the middle on the line. You just have to time it. This affects some other things as well.

Also, the horizontal scroll gives trouble. In PAL the first visible offset is 5 (if I remember correctly), so you can scroll the screen a few characters off-screen, which makes easy to make scroll routines. In NTSC you only have half a character or so off-screen.

These both together cause problems when you change the horizontal scroll register to a lower value: VIC-I draws an extra scanline in some cases, or the first scanline is distorted at the point when you change the horizontal position and/or number of columns.