forum> Code
Rupture: border between 2 screens?
France eliot - 02 May 2012 - 17:53:36 251 posts
Hi,

still investigating in CRTC... My question is about the possibility to produce border in a split-screen.

screen 1 (for ex: logo as in 99,9% of the classical demos... :)
border (variable height)
screen 2

My first idea was to have a variable R4 for screen1 (and compensate in screen2!) to have the wanted variable height for border. It requires several synchronized codes, depending of the height, while I'm looking for a solution with the minimal time wasted for synchronizing split-screen.

Have the CRTC-masters a better idea?
France PulkoMandy - 02 May 2012 - 18:30:24 633 posts
Mh, I don't see the problem ? It's the same as a classical split screen, but with R6 < R4, so you see some border.

To do screen splitting without wasting CPU time, you need to code on the Amstrad PCW :)

Another solution is :
screen 1
border-screen
screen 2

In the border screen set R6 = 0 so there is only border.
Set R4 = 0 so your screen is only 1 line high
(set R9 = 0 so the line is only 1 pixel high, if you need pixel precision)

Then wait for some lines.

When you need to start screen 2, just set your CRTC regs as needed.
You still have to compensate for the border-screen length at the end of screen 2, of course.
France eliot - 02 May 2012 - 18:59:36 251 posts
What I must precise is that the aim is to make "screen2" moving UP and DOWN... :)

Of course screen1's R6 has no impact on screen2 position...
France Hicks - 03 May 2012 - 11:24:46 459 posts
@pulkomandy: to put some border on a whole line, prefer R1=0 to R6=0, since the first is compatible on CRTC0&1 and not the second. And don't forget that if you put R6=0 when VCC=0 on CRTC 1, there will be border until the next counter loop.

But I suppose that using R1 is not a good solution since if require synchronized code. But I'm not sure to understand what you plan to do. 2 screens moving up and down independantly? Or just the screen 2? Which precision for your border (line, 2 lines, more)?
France eliot - 03 May 2012 - 13:04:06 251 posts
Screen1 is stable. The wanted precision to move Screen2 is 1 line.

Of course, I thought too about R1 as we studied Zap't'ball's dynamic screen-display at Revision Party. But it requires line synchro...
France krusty - 03 May 2012 - 16:55:19 327 posts
@eliot: could you write a post, or an article, explaining zap't'balls screen ?
France Hicks - 03 May 2012 - 18:01:12 459 posts
@eliot: it seems that the easier way to do it is your first solution: R4/R5 of the first screen variable, compensation with R4/R5 of the second screen. I just feel one problem: if R4 of the first screen is < to R4 of the second screen. But it can be resolved with some code under interruptions (to put R4 of the second screen before R4_screen1 and avoid overflow).
France PulkoMandy - 03 May 2012 - 22:24:18 633 posts
Hicks: with R4=0, the next counter loop shouldn't be too far anyway ?
Since each line would be a new screen, all the registers are refreshed so I don't see why it wouldn't work.
But, ok R1=0 works fine as well, so if you think it's better... :)
France Hicks - 04 May 2012 - 10:30:56 459 posts
@Pulko: R6=0 & R4=0 is a problem if R9<>0 because you can't have a line precision (on CRTC 1), just a R9 precision (you can correct that by setting R9=0 too, but it turn a little bit complex)...
France PulkoMandy - 04 May 2012 - 17:41:14 633 posts
Complex ? Well, if you're afraid of changing just 3 registers... :)
You need to do this ONCE at the beginning of the border-area, then you can stop it any time by putting other values in these 3 regs and start another screen. I don't see what's complex with it.
Online: Toms
Kill All Humans!