News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

About hardware scrolling with CRTC Reg 3

Started by Rhino, 10:00, 21 June 14

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

AMSDOS

I wasn't aware Ghost 'n Goblins was using multiple scrolls, or are you suggesting the R3 has a different function in Ghost 'n Goblins, or is the program I posted demonstrating the technique found in G 'n' G?
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

arnoldemu

Quote from: AMSDOS on 10:57, 27 June 14
I wasn't aware Ghost 'n Goblins was using multiple scrolls, or are you suggesting the R3 has a different function in Ghost 'n Goblins, or is the program I posted demonstrating the technique found in G 'n' G?
The program demonstrates the method used in Ghosts n Goblins (using R3 to make it smoother), but it uses a continuous scroll compared to a push scroll as in Ghosts n Goblins.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

AMSDOS

#27
Ah yes. What it needs is an example which behaves more like G 'n G.


I don't recall seeing any BASIC program with data using this method, though it should be possible to make something which behaves more like G 'n G.


I've put together some examples with the idea of having a fixed person onscreen with the scenery above it that moves when Space is pressed, this is what I came up with after a bit of optimisation:



10 DIM map%(20):MODE 1:INK 1,26:INK 3,19:BORDER 0
20 GOSUB 2010:GOSUB 3010
30 FOR x=1 TO 10
40 LOCATE x+10,10:PEN 1
50 IF map%(x)=1 THEN PRINT CHR$(143)
60 NEXT x
70 PEN 2:LOCATE 15,12:PRINT CHR$(250)
80 place%=10
90 WHILE INKEY(18)=-1
100 IF INKEY(47)<>-1 THEN place%=place%+1:GOSUB 1010
110 WEND
120 MODE 2:CALL &BC02:PEN 1:END
1000 REM Space has been Pressed, Time to Move Scenery
1010 IF place%=21 THEN place%=1
1020 PEN 1:LOCATE 15,12:PRINT" "
1030 CALL &BD19:CALL &100
1040 OUT &BC00,3:OUT &BD00,5
1050 CALL &BD19
1060 OUT &BC00,3:OUT &BD00,&BE
1070 LOCATE 10,10:PRINT" "
1080 PEN 2:LOCATE 15,12:PRINT CHR$(250);
1090 PEN 1:LOCATE 20,10:IF map%(place%)=1 THEN PRINT CHR$(143)
1100 RETURN
2000 REM Scenery Data
2010 FOR n%=1 TO 20:READ map%(n%):NEXT n%
2020 RETURN
2030 DATA 1,1,1,0,0,1,1,0,1,1,1,0,1,1,0,1,0,1,1,1
3000 REM M/C to Firmware Scroll
3010 FOR addr=&100 TO &108
3020 READ a$:POKE addr,VAL("&"+a$)
3030 NEXT addr:RETURN
3040 DATA cd,0b,bc,23,23,cd,05,bc,c9



So when Space is held down, the man on the screen blinks a lot, I'm assuming due to the use of BASIC PRINT & LOCATE. I've improved this by deleting where the man is on screen (bit like Ghost 'n Goblins) and redraw after the Scrolling is done.


I've made some variations which leads up to this program which can be found on the attached disk image, I used the Position version to make sure the Data from the small array was being displayed correctly.
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

ralferoo

Quote from: Rhino on 21:36, 23 June 14
Yes, but programming the CRTC for 307 scanlines instead of 312, it is possible to get a vertical timings of 50Hz.
There's two things at play here...

You're right in saying that 307 scanlines with 65us lines is about 50Hz, it's actually slightly further out than the standard CPC display (19955us compared to 19968us). As you point out, this isn't going to cause a problem with vertical timing, because just as there's a horizontal PLL at 15.625kHz (or 64us), there's also a vertical PLL at 50Hz (312.5*64us). So, any slight vertical timing errors will become corrected over time (in fact, it's essential because the TV's vertical sync is very unlikely to be close to the camera's vertical sync initially as despite them running at 50Hz, they're not actually driven by the mains frequency.

However, the point is that running the horizontal clock at 65us is likely to cause your signal to not be correctly recognised by some LCD TVs. It should always work fine on an analogue CRT where the only concern is the PLL, but there's no guarantee if you're sending out such an out-of-spec signal to a digital system which expects you to send a correct signal.


Powered by SMFPacks Menu Editor Mod