Raster Positions in CPCTelera

[Typhon]

Evening Lads and Ladettes, a question:

I'm on a remake of an old Arcade game using CPCTelera, and I want to know if there any easy way, without cycle-counting instructions, to use interrupts to draw rasters at positions on screen that aren't related to divisors of 6 (ie 300/50), I.e 33 pixels high? I currently just use the old "cycle a static variable from 0 to 5 repeatedly, and have a switch statement on each interrupt to change the colours accordingly" method. It's basic, and easy, and does the job, but I wondered if there was anything else that didn't involve jiggery-pokery with the CRTC to get even more fine-tuned contrrol?

(If you look at the titlescreen with rasters, you'll see the issue, with the 5th raster down, it starts about 4 pixels too soon, and the white bleeds into the green:

[Typhon]

Whoops, the image didn't attach.

[andycadley]

Basically, no, unless you use the Plus machines which can generate interrupts on whichever lines you want. 

[Typhon]

Fair enough, then I guess I just need to be creative when it comes on to-screen positioning of colours and assets :-)

[lmimmfn]

Maybe if you went into overscan vertically and adjusting the start screen position you could align it? It's not something I tried but the interrupts are fixed in time so should allow some movement.

[Anthony Flack]

you can make the interrupts take longer than 52 scanlines by resetting the interrupt counter partway through. For eg if you wait for four scanlines after an interrupt, and then hit reset on the interrupt counter, all the interrupts below that point will arrive four scanlines later.

It's too bad you can't actually read and write to the interrupt counter.

You CAN use the method Imimmfn suggests to nudge the entire screen down by a few scanlines.

[SpDizzy]

An easy fix for this concrete case would be to add a little delay at the beggining of the affected interrupt, just before your palette colour change takes place. So 1 NOP will do it.

[Anthony Flack]

I don't think so, unless I'm misunderstanding... it looks like the interrupt is happening three scanlines too late. But you could push the entire display down by three scanlines.

Or use the previous interrupt and delay by 49 scanlines. 49 scanlines is a lot of time to wait, but if you have some code that executes in a fixed amount of time, you can use the interrupt reset trick to delay the interrupt without wasting all that processor time (or just stick your fixed-length code directly into that wait time).

If it's just on the title screen, you might not need to use an interrupt at all, just a HALT inline with your main loop.

[Anthony Flack]

Nudging the entire display down by a few scanlines is very easy to do and may be all that's required.

If you put this somewhere at the start of your program...

; set register 5 of CRTC to 3 (3 scanlines of vertical offset)
ld bc, &bc05
ld a,3
out (c),c
out (c),a

The entire screen will be drawn three scanlines lower, but the interrupts will still be in the same place as they were.

[SpDizzy]

Oh sorry. Because of info about green colour starting too soon I understood the 3 scanlines of white where desired as a aesthetic 'reborder effect'. If that's not the cause obviously waiting 1 NOP will not solve the problem, and pushing display down with R5 as @Anthony Flack said is the way to go.

[Longshot]

You must increment B before OUT(C),A if you actually want to modify R5. 
But this method is not recommended because the screen will no longer be exactly at 50 Hz (312 lines), given that a frame will last 315 lines with these 3 extra lines.

[andycadley]

Given it's a title screen, I'd just burn through a bunch of NOPs personally. How much CPU time do you really need on it?

Of course if the problem also manifests in-game then yes you may have to think about repositioning the screen of getting clever with inserting some constant time code that you have to run anyway.

[angry]

The practical solution is to move the Nibbler DX bit up a few lines and leave the "remake by" bit where it is - you could move the "presenting" up 1 line if you wanted. Then judging where the splits are from the green bit you end up with - black white yellow orange, black white orange red, black blue red green. And it barely looks any different!

Even in theory whenever you start thinking about burning through 49 scanlines surely the correct answer is really to rethink things.

[andycadley]

Even in theory whenever you start thinking about burning through 49 scanlines surely the correct answer is really to rethink things.

The reality is likely you'll burn through far more than that by just doing a HALT after the final palette change anyway.

Sometimes the simple solution is the best.

[Anthony Flack]

You must increment B before OUT(C),A if you actually want to modify R5. 
But this method is not recommended because the screen will no longer be exactly at 50 Hz (312 lines), given that a frame will last 315 lines with these 3 extra lines.

Oh yeah, whoops. INC B

Are there displays that don't like this? 

[Longshot]

Oh yeah, whoops. INC B

Are there displays that don't like this?

With 315 lines this gives 49.60 Hz.
On a CTM display the image may shift depending on the setting of the vertical adjustment screw located at the rear.
However, if this screw is positioned between the 2 limits, this type of frequency is accepted by the CTM.

[Typhon]

A fascinating thread, thank you. In the end, I managed to solve it by rejigging my colours around, and delaying one particular raster.

I had a similar situation in my main game screen where my HUD along the top was only 32 pixels high, and thus the HUD colours were briefly bleeding into the main area.

I solved that by swapping the HUD to the bottom of the screen, and delaying the appropriate raster
.