Line interrupts again...

Prophet (2619)

27-07-2009, 19:26

To make the story short:

Is it possible to set a line interrupt on lines above 255?.

I mean, let's say you've a virtual screen made of 2x192 piled screens, this makes the playfield 384 pixels high; so if you scroll over it using R#23 and you want to keep an steady interrupt in line 192 (related to the display) you'll need to add the register content to the desired line; but you'll overflow the line register very soon...

As the line interrupt is mapped onto the VRAM and not over the display in itself, I'm truly starting to believe that there's no way to do what I'm trying.

Aangemeld of registreer om reacties te plaatsen

Van Edwin

Paragon (1182)

27-07-2009, 20:38

No. And you don't need to. Just adding the R#23 value to your line is enough to keep it where it should be.

Van flyguille

Prophet (3031)

27-07-2009, 21:19

More viewable scanlines? ... IIRC that produces overheat... and start to do glitches .... reduce the sparetime for CO-VDP... etc

Van jltursan

Prophet (2619)

27-07-2009, 21:53

@flyguille: No, simply a virtual screen. I'm displaying a bare 192 lines.

@Edwin: I'll try to explain myself with an example:

There're 384 lines available from $00000 to $18000, thus the Y coordinates range from 0 to 383.
If I want to rotate R#23 between 191 and 0 (decrementing) and want to keep an interrupt in (displayed) line 192 I'll need to set R#23 from 384 to 192 (if I've understood right the logic). So as Edwin suggests I'm doomed going that way, if it's not possible to set values above 255 I must change the routine.

Van Edwin

Paragon (1182)

28-07-2009, 01:17

I don't really get where you get the 384 number from. But R#19 is based on the visible lines. And since the maximum number of lines on that a v99x8 can put into view is 256, there's just 0-255 to work with.

Van jltursan

Prophet (2619)

28-07-2009, 18:49

Anyway, here's a quote from MAP that fools me:

If you have a split and are changing the vertical scrollregister (r#23) on it, then you should always re-set the splitline (r#19). This because the splitline is calculated from line 0 in the VRAM, and not from line 0 of the screen. In order to set the splitline to the ‘screenline’ it’s easiest to simply add the value of r#23 to it.

And it's true 'cause if I set a screensplit on line 192 and after that I change the scrollregister, the line interrupt changes its position; so from my point of view R#19 isn't display related. Maybe we're talking about the same...

there's just 0-255 to work with

That's all, if there's no trick to overcome this, it means that you can't get to work the following extreme example (in SC8):

- R#23=255 (page 1 is mostly displayed, first displayed line is still in page 0)
- I want to set a split on line 96 (display related, right in the middle of the screen/TV)
- So...R#19=255+96...oops, we can't!

As a rule of thumb, if you want to keep a steady screensplit on line Y, you'll never be able to change R#23 out of the range [ 0 - (255-Y) ] because you'll overflow the byte-sized register. Am I right?

Van NYYRIKKI

Enlighted (6038)

29-07-2009, 08:51

IIRC Line interrupt can be set to lines 0-234 (in 192 line mode) or 0-244 (in 212 line mode). This is relative to R#23 offset.

- R#23=255 (page 1 is mostly displayed, first displayed line is still in page 0)

If you have display page 1 selected first line is actually line 255 in page 1. You can not scroll from display page to another, it will just wrap.
- So...R#19=255+96...oops, we can't!
Yes, you can... R#19=95

You really don't need to think about overflow problem... It will take care of it self automatically.

To get better idea, try for example in basic:
SCREEN 1
for i=0 to 512:vdp(24)=iand255:for w=0 to 10:next w,i

Van Edwin

Paragon (1182)

29-07-2009, 18:50

- R#23=255 (page 1 is mostly displayed, first displayed line is still in page 0)

Ah! Now I understand the confusion. Your problem is not R#19, it's that R#23 doesn't work like you say it does here. No matter what value R#23 has, you only see the lines from one page, not a combination of two following pages.

However, you can achieve the same effect with some trickery. When line 255 enters the screen, you can add a screensplit there to change the page to the next one. And change it back to P0 at vblank. This still won't be perfect since R#23 changes are reflected immediately and there will be flicker. You can avoid this by copying the last couple of lines of P0 to P1 as well and doing you split a line early. This way P0 and P1 will contain the same data and the split will be invisible.

Van monant

Resident (48)

29-07-2009, 23:51

hallo,

on my nms8245 I made this test time ago:

50 hz. Interrupt mode 1. switch ROM in page 0 to RAM.
at 0038h I placed a fast interrupt service routine (without saving any register)

0038h : change border color at a given line (100 for example) and restore old border color
at another given line (150 for example)

the int is set by the vdp at the end of the scanline in reg19 before drawing the right border
so if reg19=99 then you'll be on scanline 100 during interrupt routine ,

Repeat this with different values of reg 23 and reg19 to check the effect.

the strange behavior was when I set interrupt at line 255.
as far as I can remeber it seems that line 0 cannot be matched?
or am I confusing with reg 18 (adjust register)?

Van Edwin

Paragon (1182)

30-07-2009, 00:53

You're right, it cannot. As NYYRIKKI said, there is a maximum value you can use for R#19. The last line you can select is somewhere halfway vblank. Of course, this issue is more of a problem with registers that are only processed at the start of a line.

Van jltursan

Prophet (2619)

30-07-2009, 19:31

So the screen wraps, indeed that's what fooled me at first. Now it sound the most logic approach...

IMHO the limit of 0-234 of R#19 register seems to be pretty harmless. I can't remember any use for such high values. IIRC the overscan trick uses values less than 234 and only overscan raster color bars could be affected by this.