CPCWiki forum

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!

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

Quote from: krusty_benediction on 21:17, 29 January 24According 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.

Quote from: Rhino on 10:03, 30 January 24

Quote from: krusty_benediction on 21:17, 29 January 24According 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

Quote from: Rhino on 10:03, 30 January 24

Quote from: krusty_benediction on 21:17, 29 January 24According 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.

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 :)
PXL_20240130_114113937.jpg

Quote from: Devlin on 12:45, 30 January 24I 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 :)
PXL_20240130_114113937.jpg

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

Quote from: Rhino on 20:00, 29 January 24Hi!

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. ???

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.

Quote from: Rhino on 13:16, 30 January 24

Quote from: Devlin on 12:45, 30 January 24I 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 :)
PXL_20240130_114113937.jpg

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.

Quote from: Longshot on 13:38, 30 January 24

Quote from: Rhino on 20:00, 29 January 24Hi!
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."

Quote from: Devlin on 14:18, 30 January 24

Quote from: Rhino on 13:16, 30 January 24

Quote from: Devlin on 12:45, 30 January 24I 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 :)
PXL_20240130_114113937.jpg

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.

Quote from: Rhino on 14:24, 30 January 24Regarding 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

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!

312 lines includes Vsync.
64 nops includes Hsync.

Quote from: McArti0 on 12:40, 07 March 24312 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

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

Quote from: McArti0 on 15:44, 07 March 24R3 =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  :picard:
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!

312-16 ok?

yep that'll do

Quote from: martin464 on 19:02, 07 March 24yep that'll do

Reading chapter 7 of the Compendium may help you. ;)

https://shaker.logonsystem.eu/

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.

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

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!

Quote from: martin464 on 11:44, 11 March 24the same thing always happens

Yes.

I suspect the answer is "it was just easier to build the hardware to assert WAIT regardless." 

It could have been designed more like the Speccy, where the Z80 is only slowed when accessing memory visible to the GA and only during the actual screen area, but it'd have been a more complicated design and the savings probably not considered worth it at the time.

gotcha thanks Andy, looks like there's a sequencer in the gate array that follows a preset pattern, so the multiplexers always connect ram to either the CPU or CRTC following this 16 step sequence. 

Seems likely. I guess the design makes sense when you think about the 464 since all of the RAM is potentially video memory and the display can technically cover any part of the border area.

It's a lot more annoying on 128K and above because there is a lot of RAM that could have been used to run code faster, but adding all the bus arbitration logic would probably have been expensive.

yes, there'd probably be no overscan otherwise maybe just as well!
I was thinking about this, its quite hard to work out how much it actually slows CPU execution down

most of the instructions seem to do memory access on the same phase of the cycle there's only a few where it's stretching them i suppose it's been worked out... but my guess was maybe a 15% hit to optimised code, maybe it's less than that
i've read some statements on the slowdown that surely must be wrong about it being a major hit, possibly from those Speccy owners you mentioned...

Too many 'maybe' and 'suppose'...
Tell me how much slower stack-based instructions are? CALL, RET, RET z, PUSH HL, POP HL.

sure but how to measure this. good to mention the worst case ones
it can be slower but the % slower has to be an average

Looking at these stack based ones are about 20% slower with PUSH coming off worst. JP nnnn is 20% slower.

 

POP RR	10	12	20%
PUSH RR	11	16	45%
RET	10	12	20%
CALL	17	20	18%

All the 1 nop instructions will not be effected nor are a few others, like JP (IX) is the same. JR is the same and only 1 cycle slower on cc 7 vs 8.

it depends on what your code is doing
If it's using PUSH to copy data the hit is significant and OUT suffers is 33% slower
If your code is using other instructions it depends what they are and every unaffected instruction reduces the total slowdown as a % of the total

So it's impossible to do anything but make an approximate estimate as it's code specific and how many times a piece loops through and what instructions you're using

Ok how about this, about 10-20% normally but double that for routines hitting the stack or IO

Not that any of this is really the biggest problem
Most chunks of code have plenty of scope for optimisation, like remember routines you did in 200nops then figured out a way to do it in 100 and swear to yourself that's now the dogs nuts ultimate, and next day you get it to 88. so until anyone gone all the way optimising can't be blaming the gate array!