Optimal values of CRTC reg 3 for half-character horizontal scrolling

[Rhino]

Hi!

I have recently received a report that the Mario demo ( https://www.cpcwiki.eu/forum/games/astonishing-and-enigmatic-pics-from-batmangroup!!/ ) produces a darkened image on a non-Amstrad CRT Monitor/TV and I think it must be due to the values of CRTC register 3 (#85/#86) that it uses for the half-character horizontal scroll. Does anyone know if there are more optimal/compatible values than #85/#86?

I also wonder if maybe there are no a value pair 100% compatible with all CRTs and maybe the best solution is to provide several possible combinations so that the user can choose the one that best suits his monitor (as I think Super Cauldron did), in that case it would be good to know which would be the combinations of values that can provide that 100% compatibility.

Anyone experimented with this in depth?

Thanks!

[krusty_benediction]

According to some failed experiments (this month) on exotic screens when displaying a static screen that do no scroll with r3 trick : it seems it is better to not be under 8c to be safe when R2=50

[Rhino]

According to some failed experiments (this month) on exotic screens when displaying a static screen that do no scroll with r3 trick : it seems it is better to not be under 8c to be safe when R2=50

Those exotic screens were modern LCD/LED screens? I rule out the possibility that the reg 3 trick works on those screens. Instead, it would be nice to reach 100% compatibility on CRT screens since a % of users have their CPC connected on some kind of CRT TV or non Amstrad CRT monitor.

[roudoudou]

According to some failed experiments (this month) on exotic screens when displaying a static screen that do no scroll with r3 trick : it seems it is better to not be under 8c to be safe when R2=50

Those exotic screens were modern LCD/LED screens? I rule out the possibility that the reg 3 trick works on those screens. Instead, it would be nice to reach 100% compatibility on CRT screens since a % of users have their CPC connected on some kind of CRT TV or non Amstrad CRT monitor.

Almost all CRT-TV i have are doing a kind of automatic stabilisation, so R3 trick does not work with them. No problem for me if you are only compatible with true CTM

[krusty_benediction]

According to some failed experiments (this month) on exotic screens when displaying a static screen that do no scroll with r3 trick : it seems it is better to not be under 8c to be safe when R2=50

Those exotic screens were modern LCD/LED screens? I rule out the possibility that the reg 3 trick works on those screens. Instead, it would be nice to reach 100% compatibility on CRT screens since a % of users have their CPC connected on some kind of CRT TV or non Amstrad CRT monitor.

I was not the tester guy ;  I have no more information than "a commodore monitor". So I guess it is an old CRT monitor.

[Devlin]

I didn't make the report, but I wanted to see for myself - so here we are!

I've tried on my 464(crtc0)+512k and schneider tv through SCART and provided a photo for reference
You cannot view this attachment.

[Rhino]

I didn't make the report, but I wanted to see for myself - so here we are!
I've tried on my 464(crtc0)+512k and schneider tv through SCART and provided a photo for reference
You cannot view this attachment.

Thanks! that's exactly the issue I'm referring to, the image is darkened, have you checked if any game using reg 3 hardware scrolling looks fine on your monitor?

Here is a list of some of them (those marked as "yes" in R3 column):

https://www.cpcwiki.eu/index.php/Programming_methods_used_in_games

[Longshot]

Hi!

I have recently received a report that the Mario demo ( https://www.cpcwiki.eu/forum/games/astonishing-and-enigmatic-pics-from-batmangroup!!/ ) produces a darkened image on a non-Amstrad CRT Monitor/TV and I think it must be due to the values of CRTC register 3 (#85/#86) that it uses for the half-character horizontal scroll. Does anyone know if there are more optimal/compatible values than #85/#86?

I also wonder if maybe there are no a value pair 100% compatible with all CRTs and maybe the best solution is to provide several possible combinations so that the user can choose the one that best suits his monitor (as I think Super Cauldron did), in that case it would be good to know which would be the combinations of values that can provide that 100% compatibility.

Anyone experimented with this in depth?

Thanks!

Hi Rhino

Regarding R3 on a CTM.

VSYNC is sent for 4 HSYNC by the GATE ARRAY, whatever the value of R3.
The value of the 4 more significants bits of R3 only affects the "duration" of the VSYNC signal by the CRTC.

For the 4 less significants bits of R3, it is better to use values 4 and 5 instead of 5 and 6.
Especially to avoid problems related to different types of CRTC.

See Compendium, chapter 16 (VSYNC) and 14 (HSYNC)
https://shaker.logonsystem.eu/ACCC1.7-EN.pdf

I have no experience with CPCs connected to LCDs, but it's a bit of a lottery.

[Longshot]

Changes in brightness may be seen on some CRT monitors.

Compendium (chapter 14.4) relates this in a note:

A short C-HSYNC may also have a discolouration effect on some non-CTM displays.  This is for example the case if the CPC is connected to an ATARI SC1425 monitor (which was available with the ATARI 520STE).

If the HSYNC is cut to 6 µsec (R3=6), the GATE ARRAY sends black for approximately 2 µsec followed by the HSYNC signal of 4 µsec. If the colour of the BORDER has been defined with something other than black (which a HSYNC longer than 6 would generate) this has a discolouration impact on the line because each colour component is calibrated according to the colour present over the following 3 µsec (position 7, 8 and 9).

If the BORDER is not black and R3<9, the colour will be affected on the line. On this type of monitor, it is therefore possible to obtain more colours.

[Devlin]

I didn't make the report, but I wanted to see for myself - so here we are!
I've tried on my 464(crtc0)+512k and schneider tv through SCART and provided a photo for reference
You cannot view this attachment.

Thanks! that's exactly the issue I'm referring to, the image is darkened, have you checked if any game using reg 3 hardware scrolling looks fine on your monitor?

Here is a list of some of them (those marked as "yes" in R3 column):

https://www.cpcwiki.eu/index.php/Programming_methods_used_in_games

Tried Ghosts'N'Goblins and Legend of Kage - both in the list as "Yes" for R3, and neither had any darkening or other issues when scrolling. Tried Prehistorik 2 and Super Cauldron as well I couldn't get them to even load.

[Rhino]

Hi!
I have recently received a report that the Mario demo ( https://www.cpcwiki.eu/forum/games/astonishing-and-enigmatic-pics-from-batmangroup!!/ ) produces a darkened image on a non-Amstrad CRT Monitor/TV and I think it must be due to the values of CRTC register 3 (#85/#86) that it uses for the half-character horizontal scroll. Does anyone know if there are more optimal/compatible values than #85/#86?
I also wonder if maybe there are no a value pair 100% compatible with all CRTs and maybe the best solution is to provide several possible combinations so that the user can choose the one that best suits his monitor (as I think Super Cauldron did), in that case it would be good to know which would be the combinations of values that can provide that 100% compatibility.
Anyone experimented with this in depth?
Thanks!

Hi Rhino
Regarding R3 on a CTM.
VSYNC is sent for 4 HSYNC by the GATE ARRAY, whatever the value of R3.
The value of the 4 more significants bits of R3 only affects the "duration" of the VSYNC signal by the CRTC.
For the 4 less significants bits of R3, it is better to use values 4 and 5 instead of 5 and 6.
Especially to avoid problems related to different types of CRTC.
See Compendium, chapter 16 (VSYNC) and 14 (HSYNC)
https://shaker.logonsystem.eu/ACCC1.7-EN.pdf
I have no experience with CPCs connected to LCDs, but it's a bit of a lottery.

Thanks for the info and congratulations for your great work with your CPC CRTC Compendium!
So, if I understood correctly, would it be enough to put a black border to fix the issue?

Regarding the 4/5 vs 5/6 values, do you mean that the half character scroll is more accurate with those values? I noticed that in CRTC 1, 5/6 values did not produce an accurate half character scroll, but wouldn't it be less stable at sync level with 4/5? "A CTM monitor must be adjusted if it loses sync with R3l=4."

[Rhino]

I didn't make the report, but I wanted to see for myself - so here we are!
I've tried on my 464(crtc0)+512k and schneider tv through SCART and provided a photo for reference
You cannot view this attachment.

Thanks! that's exactly the issue I'm referring to, the image is darkened, have you checked if any game using reg 3 hardware scrolling looks fine on your monitor?
Here is a list of some of them (those marked as "yes" in R3 column):
https://www.cpcwiki.eu/index.php/Programming_methods_used_in_games

Tried Ghosts'N'Goblins and Legend of Kage - both in the list as "Yes" for R3, and neither had any darkening or other issues when scrolling. Tried Prehistorik 2 and Super Cauldron as well I couldn't get them to even load.

Thanks, that would fit with the black border solution, since those games have a black border.

[Longshot]

Regarding the 4/5 vs 5/6 values, do you mean that the half character scroll is more accurate with those values? I noticed that in CRTC 1, 5/6 values did not produce an accurate half character scroll, but wouldn't it be less stable at sync level with 4/5? "A CTM monitor must be adjusted if it loses sync with R3l=4."

Absolutly!

"When R3l drops, excluding R3.JIT, the image is shifted to the right of half a unit (0.5 μsec if
R3l drops by 1) whatever the value of R2. However, values 5 and 6 should be avoided to
obtain an exact and independent phase shift from the CRTC.

On CRTC 1, for example, if R3l=5, then the duration of C-HSYNC is approximately 3,1250 μsec,
while with R3l=6, the duration of C-HSYNC is exactly 4 μsec. 4-3.1250 = 0.875/2 = 0.4375 or 7
Pixels (graphic mode 2) instead of the expected 8 pixels. If R3L=4, then C-HSYNC lasts 2,1250
μsec approximately. The difference between 3,1250 and 2,1250 is exactly 1 μsec and the screen
is in principle well offbeat of 8 pixels.

It is therefore preferable to use the 4/5 values because these two values allows to generate CHSYNC
signals, the difference of which is very exactly 1 μsec, whatever the type and tolerance of
the CRTC. A CTM monitor must be adjusted if it loses sync with R3l=4."

I tried on several CTM monitors and did not encounter any particular problems.

If the horizontal adjustment potentiometer on the back of the monitor is incorrectly adjusted, this can still be managed quite simply.

An example:

https://www.youtube.com/watch?v=1q7RQykZoKY

[martin464]

this seems like the place to sneak in a quick question...

on the standard settings the horizontal fly back is 16 nops to give our 64 nops per scanline
is there an equivalent delay on vertical fly back?

it would make sense that there isn't as the math works out as if there isn't one as 64 * 312 is 19968
unless my 312 total lines is wrong....
i always thought 'vysnc' was some kind of magic delay but maybe not!

[McArti0]

312 lines includes Vsync.
64 nops includes Hsync.

[martin464]

312 lines includes Vsync.
64 nops includes Hsync.

the 64 nops is 8 for both borders + 40 for the visible screen + 16 for Hsync
if there's 312 lines the Vsync has no delay like the 16 Hsync has, it's instant

i noticed the CPC Wiki says there's 38 vertical characters total if you X 8 scanlines per char that is 304 lines. i assumed this is unclear in the wiki and it's 0 based and should be 39 for 312 lines
so this means after the hsync on the final line has finished it immediately starts back at the top

[McArti0]

R3 =VVVVHHHH " VSync width in scan-lines. (0 means 16 on some CRTC. Not present on all CRTCs, fixed to 16 lines on these)"

[martin464]

R3 =VVVVHHHH " VSync width in scan-lines. (0 means 16 on some CRTC. Not present on all CRTCs, fixed to 16 lines on these)"

ok i'm not disagreeing with you, but how does the maths work, where's the 
we know a full frame is 19968 nops which is 64 * 312. so as you said the 312 includes the vsync wait

look at it this way
64us * 312 = 19968. Any further waits must occur within the 19968 or it won't be 19968 any more!

a vsync width of 16 scanlines implies something else to me, that the vsync isn't a delay but a state that lasts 16 scanlines
this would seem to net out to hsync being a real delay but vsync is not... or am i setting myself up to stand corrected!

[McArti0]

312-16 ok?

[martin464]

yep that'll do

[Longshot]

yep that'll do

Reading chapter 7 of the Compendium may help you.

https://shaker.logonsystem.eu/

[martin464]

thanks Longshot I'll take a gander but i think i have it all figured out! (which is a dangerous assumption)

the key point for me is on standard settings it takes 12800us to display the 200 line 16k screen
what i learned recently was the raster rips along at 2 bytes per microsecond which would be 8192us but the border and horizontal flyback increase that to 12800

that means 7168us free time to do stuff between frames, and there's also 20us free time per scanline
it was knowing exactly how long it takes to draw the screen and how much free time there was i wanted to understand

the only thing i'm not sure of is what exactly happens on the blanking, flyback, border periods
this is just a curiosity, because in theory the wait/ready induced states that stretch out the instructions to 4 cycles could have been suspended when not needing to actually read vram but we know those wait states are constant
i just wonder what's going on during those periods, does the GA still read vram off the edge and the CRTC ignore it, or does the GA know and cease trying to send data.

[McArti0]

https://bread80.com/2021/06/03/understanding-the-amstrad-cpc-video-ram-and-gate-array-subsystem/   Chapter "Timing Diagrams"

https://www.cpcwiki.eu/imgs/4/4a/CPC6128_Schematic.png

[martin464]

yes, bread's analysis is awesome, however he doesn't go into that part you'll see he treats it like the same thing always happens
the answer is in the schematic yes but that's why i asked, i cannot read these!

[McArti0]

the same thing always happens

Yes.