I got a scart cable to connect my cpc to a sony trinitron 4:3 crt television.
I played with some settings (these are the response from the television not the cable or the cpc):
- if I set hsync to less than 8 in basic then pen 0 and the border went black. Not sure if Blue disapears or if the brightness is reduced. I will find out. This means anything using R3 to improve smooth scrolling is not going to work (because it sets it to 5/6)
- if I set hsync to less than 6, the tv can't handle it. I have a picture, but there is a sine wave through the image (like it's distoring using r2 demo effect). So r3 smooth scrolling is not going to work properly.
I will try the flatscreen and I'll see if I can work out any more issues like this.
I didn't see the picture go black and white, it was always in colour but it wasn't happy with the sync.
(Interestingly on the sony CRT television, it allowed R0 to go all the way up to 66 without issue. )
On an old purely analogue CRT TV, the TV should act exactly like any Amstrad monitor. The more pre-processing being done by the TV (as the Trinitron is most likely doing), the more likely it is to have problems when messing with the hsync. LCD/Plasma TVs will always have issues with these tricks because the are using sampling to read the analogue signals, so varying the signals after the TV has "locked" on them will cause problems.
There's a Codemasters game from Ian Richards called Transmuter, which I use to grade how good a TV reacts to these effects. I'm not sure what method Ian used to do the scrolling, but it's relatively smooth on an Amstrad monitor, but barely watchable on a flatscreen TV.
Bryce.
Some Regza (Toshiba) LCD TV display fine the R3 smooth scrolling during around 30s to 1mn and next display a blue screen.
Switching the AV a return work again... More electronics and more (false) problems!
Quote from: Bryce on 15:15, 07 December 16
On an old purely analogue CRT TV, the TV should act exactly like any Amstrad monitor.
Not quite.
What happens when you shorten the HSync is that the CPC starts generating border in the "blanking" area. On Amstrad monitors, this has no effects, but TVs will use the blanking area to perform calibration of the black level. This is why the border color disappears if there is border in that zone, and it is also why plugging some devices to the CTM display result in unexpectedly light picture (for example, you get that problem with an SNES using an RGB cable).
This happens on purely analogue CRT TVs, as well as video projectors and modern LCDs.
By changing the border color (rasters) or having your HSync happen during the active display area, you can use this to generate gradients (because the black calibration is averaged over several lines). This was experimented by Longshot back in the 90s as he was using an Atari monitor, and rediscovered more recently by some spanish guys trying to shift the screen using R3 adjustment for Plus compatibility, a trick originally suggested on Grimware.
We have then confirmed this on CRT TV (owned by Eliot), video projectors (the one used at the ReSeT party, if you want to come there and repeat the experiment) as well as at least two more recent LCD TVs, including mine.
The other problem with the HSync is how well the TV or monitor deals with unexpected changes and out of range values. The CTM has some kind of PLL to synchronize itself, with the result that it will slowly catch up when the HSync suddenly changes in the middle of a frame. Some other (even CRT) displays will immediately switch to the new sync, without the slow and gradual move. This prevents the "hexagonal pixels" trick to work (ask Supersly about it, it is about changing the sync position every other line to shift the display by about half a pixel). Some other displays (usually modern LCD or projectors) will stop displaying anything for a few seconds, until they can resynchronize.
I can't recall exactly which games they were but some of the cassette games I had wouldn't load properly when I used the TV modulator in RF port on either CRT or a HDTV and yet worked fine when using the CPC monitor.
Quote from: PulkoMandy on 16:24, 07 December 16
but TVs will use the blanking area to perform calibration of the black level.
As soon as you start talking about black level calibration it's no longer a "purely analogue" TV that you're talking about. The original analogue TVs didn't calibrate the black level, only later more modern TVs did this. The PLL circuitry was also a lot simpler back then (it wasn't even a true PLL), usually an internal oscillator would be synced to the sync signal, but it was done with a stepless, analogue method. Modern TVs do the same thing, but completely in the digital domain, by digitizing and sampling the incoming signal. The old TVs would allow you to vary the sync frequency on the fly, the digital systems will not accept any variance once the sync frequency has been locked.
The CTM is an old analogue TV with the receiver missing, nothing else.
Bryce.
I take it this is why I cannot play Ghosts and Goblins without my display freaking out when the screen scrolls!
I am using a RGB->VGA box, and a TFT TV - sadly I dont have a CRT of any kind anymore :-(
Quote from: keith56 on 04:04, 08 December 16
I take it this is why I cannot play Ghosts and Goblins without my display freaking out when the screen scrolls!
Yes, it is, and the same for anything else listed here (http://cpcwiki.eu/index.php/Programming_methods_used_in_games#Hardware_Scrolling)with a 'Yes' in the R3 column.
Quote from: Bryce on 15:15, 07 December 16
There's a Codemasters game from Ian Richards called Transmuter, which I use to grade how good a TV reacts to these effects. I'm not sure what method Ian used to do the scrolling, but it's relatively smooth on an Amstrad monitor, but barely watchable on a flatscreen TV.
A bit off topic, but I checked out Transmuter to see if I'd missed something interesting, but it doesnt seem to be altering CRTC registers at all. The scrolling is pure software, it's just using LDIR in a loop directly on the visible screen, which is why the player sprite rocks back and forth as it keeps needing to be corrected after being moved by the scroll.
Quote from: Axelay on 04:57, 08 December 16
Yes, it is, and the same for anything else listed here (http://cpcwiki.eu/index.php/Programming_methods_used_in_games#Hardware_Scrolling)with a 'Yes' in the R3 column.
A bit off topic, but I checked out Transmuter to see if I'd missed something interesting, but it doesnt seem to be altering CRTC registers at all. The scrolling is pure software, it's just using LDIR in a loop directly on the visible screen, which is why the player sprite rocks back and forth as it keeps needing to be corrected after being moved by the scroll.
So Transmuter just generally has crap scrolling? :D
Bryce.
Quote from: Bryce on 21:07, 07 December 16
As soon as you start talking about black level calibration it's no longer a "purely analogue" TV that you're talking about.
How do you explain the RGB output of the SNES being light grey when plugged on the CTM, and black everywhere else? Yes, really everywhere else. Old TVs, Amiga 1084s, etc.
The black calibration can be done in a pure analogue way, and must be done for some machines to work properly.
How old does the TV need to be for you to consider it "pure analogue"? 1990? 1980? 1920?
Quote from: PulkoMandy on 09:11, 08 December 16
How do you explain the RGB output of the SNES being light grey when plugged on the CTM, and black everywhere else? Yes, really everywhere else. Old TVs, Amiga 1084s, etc.
The black calibration can be done in a pure analogue way, and must be done for some machines to work properly.
How old does the TV need to be for you to consider it "pure analogue"? 1990? 1980? 1920?
1920? :D Colour TV's only came 30 years later.
I don't know the exact details of the SNES RGB output, but I think I know what you mean by "calibrating" now. You're just referring to the black reference voltage? This isn't really "calibrated" it's a instant voltage comparison and yes, you're correct, the CTM doesn't properly do this because it assumes that it will only ever be connected to a CPC with known signal levels, so anything else you connect might be displayed slightly dark/lighter than it should be.
Bryce.
Quote from: keith56 on 04:04, 08 December 16
I take it this is why I cannot play Ghosts and Goblins without my display freaking out when the screen scrolls!
I will be doing more testing and I'll have a go at fixing it. :)
All this just tells me that i have to stablish a service to repair and service original screens. The service will run until I eventually die electrocuted in the most horrible way or with a tumour :picard2:
That's one option. Another might be some sort of hardware device that "knows" about these kinds of things and fakes the "correct" output. No idea how feasible that is though....
Quote from: Bryce on 08:42, 08 December 16
So Transmuter just generally has crap scrolling? :D
Transmuter just generally is crap. Full stop. :laugh:
On the other hand, I don't think I've ever played it on a real CPC, only on an emulator, so I wasn't aware until now that there were any differences in the scrolling.
Quote from: Nich on 21:19, 08 December 16
Transmuter just generally is crap. Full stop. :laugh:
On the other hand, I don't think I've ever played it on a real CPC, only on an emulator, so I wasn't aware until now that there were any differences in the scrolling.
I have played it on a real CPC, it was one of the first games I bought....
....and it is crap! :laugh:
Quote from: CanonMan on 22:47, 08 December 16
I have played it on a real CPC, it was one of the first games I bought....
....and it is crap! :laugh:
Transmuter doesn't use double buffer, so it's drawing directly to the visible screen.
It's probably racing the beam too.
To see it smooth you probably need to have exactly a 50hz display and with the amstrad monitor's persistence.
The player sprite moves backwards and forwards - i'm guessing it's not intentional - it's a bug and it's a frame behind (OR, when it's re-drawn taking the racing the beam into account, it's actually correct!)
Quote from: arnoldemu on 15:02, 09 December 16
Transmuter doesn't use double buffer, so it's drawing directly to the visible screen.
It's probably racing the beam too.
To see it smooth you probably need to have exactly a 50hz display and with the amstrad monitor's persistence.
The player sprite moves backwards and forwards - i'm guessing it's not intentional - it's a bug and it's a frame behind (OR, when it's re-drawn taking the racing the beam into account, it's actually correct!)
I'm not convinced that it was trying to chase the beam. See the scroll code from the game below - it's far too slow to chase the beam, it's 'lapped' by it several times!
call #bd19
ld hl,#c001
ld de,#c000
ld a,#10
.l1680
push af
ld a,#08
.l1683
push af
xor a
ld bc,#004f
ldir
ld (de),a
ld hl,#07b1
add hl,de
push hl
pop de
inc hl
pop af
dec a
jp nz,l1683
ld hl,#3fb0
ex de,hl
or a
sbc hl,de
push hl
pop de
inc hl
pop af
dec a
jp nz,l1680
@Axelay (http://www.cpcwiki.eu/forum/index.php?action=profile;u=84) maybe I thought it was winning the race, but I can see now it's far behind.
LOL.
Testing on my CPC6128 type 1 sony trinitron tv and scart cable:
similar response for r3 except 5 is not stable so 6/5 scroll not smooth enough.
R2=49 (left side has ~ half char border)
R1=47 (right side has ~ half char border)
R7=34
R6=32
EDIT: The scrolling is actually ok on relentless. I'm going to guess because the r3 value during vsync is ok, and during scroll area it's changing.
on the flatscreen:
flatscreen TV: type 1
ff reduced border left side
fd larger border left, and shift screen down a little
f9 display goes a bit dull (maybe half brightness?) if colour - set border to black
f8 duller
f6/f5 works - r3 scrolling is good.
visible area:
R2=50 (left side has ~ half char border
R1=47 (right side has ~ half char border
R7=34 (top border half char)
R6=33 (bottom border half char)
NOTE: R4 can go as high as you want and it will not roll the screen.
NOTE: R0 can go to about 69 before it can't sync.
@keith56 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1886): Is the screen static if you start the game and do nothing? Does it show colour?
Ghosts n goblins starts with R3=5, so if the picture is stable and has colour, then clearly the television you have supports that.
Maybe the solution is a custom CPC->HDMI convertor using an FPGA that actually understands the tricks that the CPC pulls on the signals for scrolling, etc. Obviously this wouldn't be as cheap a solution as a CPC->SCART cable ...
Quote from: arnoldemu on 22:18, 10 December 16
@keith56 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1886): Is the screen static if you start the game and do nothing? Does it show colour?
Ghosts n goblins starts with R3=5, so if the picture is stable and has colour, then clearly the television you have supports that.
The game is all looks normal and good until the screen scrolls, at which point it kind of rolls and blacks out, then after a moment it comes back and the game is playable normally again - as you say it sounds like R3=5 is ok.
Unfortunately, being unable to see the screen for so long means I'm probably dead by then!
This is what I connect my CPC with
http://www.octoate.de/wp/articles/connect-cpc-to-vga-display/
I don't know enough about the box to know if it is converting to a digital image, or if the weird syncing is "passed up" through the VGA port to the flatscreen TV
Quote from: keith56 on 00:29, 11 December 16
The game is all looks normal and good until the screen scrolls, at which point it kind of rolls and blacks out, then after a moment it comes back and the game is playable normally again - as you say it sounds like R3=5 is ok.
Unfortunately, being unable to see the screen for so long means I'm probably dead by then!
I will make some test programs that use r3 for scrolling but do different things to compensate for the problem you see. Would you mind testing them?
If I can find a method that works on your television I can patch the game. The ultimate is a patch that completely removes the r3 scrolling which I know will work for all but I want to see if I can find a way to make r3 scrolling work in more situations :)
Quote from: arnoldemu on 11:51, 11 December 16
I will make some test programs that use r3 for scrolling but do different things to compensate for the problem you see. Would you mind testing them?
Yes by all means please send me some test code! I'm fascinated to know what scrolling tricks are / are usable.
Quote from: keith56 on 12:21, 11 December 16
Yes by all means please send me some test code! I'm fascinated to know what scrolling tricks are / are usable.
http://www.cpctech.org.uk/hscrl.zip
There is a dsk in the zip file with multiple programs to run.
Please run each and report what you see.
Each test uses r3 scrolling, sets mode 1 and fills the screen with chars. The chars will repeat as it scrolls.
Press O,P to scroll left/right.
Hold them down to scroll.
I am interested in:
- if the screen is stable or not
- if the colours are good (normal basic colours of blue and yellow with black border)
- if the display goes black/white or rolls or distorts or anything
- if the scroll is smooth or nearly smooth (firmware timings may cause it to be bit worse) when the keys are held. Or maybe some values are much worse and are really hard to watch?
hrz1.bin - classic f5/f6 (should do the same as ghosts'n'goblins on your setup)
hrz2.bin - set fe during vsync, f5/f6 at other times (this may fix your problem, I make sure hsync is a good value only at vsync time, during the display the screen uses f5/f6)
hrz3.bin - switch f4/f5 (the idea here is that switching f5/f6 is a problem, so try a different switch - same distance between switch values)
hrz4.bin - switch fe/f5 (switch from LONG to SHORT. e is the default.)
Thanks :)
Ok, I tried all 4
I'm afraid none of them work on my converter box,
All 4 cause a roll of the screen every 2nd time I press the right button.
No 2 is the worst, if I hold down right it completely blacks out the screen (Probably this that G&G is using?)
on 1,3 and 4 holding right causes the screen to judder violenty in all directions (picture moves about an inch!) but the screen never blacks out.
Colours appear normal at all times (except when the screen blacks out)
If you want more testing I will do so tonight, or record video if you want to see the effect.
Quote from: keith56 on 00:02, 12 December 16
Ok, I tried all 4
I'm afraid none of them work on my converter box,
All 4 cause a roll of the screen every 2nd time I press the right button.
No 2 is the worst, if I hold down right it completely blacks out the screen (Probably this that G&G is using?)
on 1,3 and 4 holding right causes the screen to judder violenty in all directions (picture moves about an inch!) but the screen never blacks out.
Colours appear normal at all times (except when the screen blacks out)
If you want more testing I will do so tonight, or record video if you want to see the effect.
Thanks.
No 2 was meant to fix it :laugh: The idea behind No 2 was to send a "good" hsync when vsync is active to keep the converter happy but it didn't work.
No 1 is closest to G'n'G *except* the change is made at a different time in the frame compared to G'n'G.
I'll think of some other ideas to see if I can improve things.
Has there ever been any kind of consensus on why adjusting R3 moves the screen by half a CRTC character instead of a whole one? If the pulse width is measured in CRTC cycles, it still doesn't entirely make sense to me, although obviously it's more to do with how the monitor interprets the signal.
Quote from: RichTW on 20:30, 12 December 16
Has there ever been any kind of consensus on why adjusting R3 moves the screen by half a CRTC character instead of a whole one? If the pulse width is measured in CRTC cycles, it still doesn't entirely make sense to me, although obviously it's more to do with how the monitor interprets the signal.
I was thinking about this yesterday. I'm guessing the monitor is synchronising on the centre of the hsync pulse.
What happens:
- CRTC outputs HSYNC which goes into GA
- GA starts blanking (forcing black)
- 2 us after the CRTC HSYNC starts, GA outputs SYNC to monitor
- GA cuts monitor SYNC at 4us max
Normal HSYNC length is above 6. So GA will output 4us of HSYNC to monitor.
Normally we see 2 chars blanking, 4 chars HSYNC to monitor and then 8 chars blanking.
If we set HSYNC length to 5, then GA will output 3us to monitor (mid point 1.5us).
We also get less blanking, the blanking is now cut at the same time as the HSYNC to the monitor.
Depending on R2 setting we can then get border AND/OR graphics to appear where HSYNC and/or blanking would normally be with normal settings.
Televisions are not happy about the graphics and change the colours.
So if R2 is not near HSYNC, you can set border to black and they are happy.
If R2 causes graphics to overlap HSYNC then you can't do much, except set a pen to black and blank the pixels yourself.
@keith56 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1886)
Please download again http://www.cpctech.org.uk/hscrl.zip
Please test hrz5,hrz6,hrz7 and hrz8.
5 changes r2
6 changes r0
7 changes r3 (8/7) - I expect ok and chunky scroll
8 oops same as 7.
I am interested to know what the adaptor does with these.
I *think* the adaptor is syncing on the *end* of the hsync and not the middle.
This means R3 scrolling may never work. This would certainly explain the rolling and it jumping by ~4 chars.
If you type this in basic what happens:
out &bc00,3:out &bd00,&85
out &bc00,3:out &bd00,&86
and please try it with normal border and "border 0".
I have some more questions:
- The adaptor is converting amstrad to vga ? Is it scaling?
- Can you choose the output vga resolution (e.g. 800x600)?
- is the Amstrad screen centralised exactly so that left and right border are the same width?
If it's syncing on the end of the hsync or the start then the borders will not be equal in size I don't think, and the widths may explain what it is syncing on.
Thanks
5 changes r2 - screen went black after character fill, pressing buttons doesn't bring it back
6 changes r0 - screen rolled all over the place then went black (no signal) after the character fill
7 changes r3 (8/7) - Chunky scroll - no problems!
8 oops same as 7. - Same as 7!
7 and 8 have worked fine, the others have not been usable
Quote from: keith56 on 23:08, 13 December 16
5 changes r2 - screen went black after character fill, pressing buttons doesn't bring it back
6 changes r0 - screen rolled all over the place then went black (no signal) after the character fill
7 changes r3 (8/7) - Chunky scroll - no problems!
8 oops same as 7. - Same as 7!
7 and 8 have worked fine, the others have not been usable
Ok.
The results are that R3 smooth scrolling is not possible with your converter and there is no other way to try and do the same with other registers.
Yes - it certainly seems not!
Thanks for all the test files, it was interesting to see them work, and I know now not to spend any time trying to develop using half char H scroll! Unless I don't want to play it myself!