R3 on all versions of CRTC. Any Issues?

[AHack]

Now that I have retired, I always wanted to go back and write a game for the CPC - the first computer I learnt z80 on.


From what I remember about using R3 is that the values may work on one CRTC and not others. What are the safe values to use? What are the best practices for it's use? I presume that you need the standard values at the beginning and end of a frame, then do a rupture in the middle for a scrolling screen, while the top and bottom of the screen use panels that are standard CRTC values for the best chance of compatability.


The idea I want to do is have one 16KB chunk for the scrolling screen divided into sections, so in the rupture you can show the parts for a Mode 0 1 pixel scroll. Sort of like the game Dropzone on the C64 but a slightly bigger scroll area at the bottom. I could do this without using the R3 scroll trick and have 2 areas of 16KB each for a double buffer screen arrangement. But this wastes memory and by using R3 I only need 16kB. That leaves plenty of memory for a game.


I also remember the R3 trick had issues on TV modulators and showed black an white images. Was there a clever trick discovered to stop that from happening? I don't care about modern TVs, Flat screens and such, so long as it will work on 80s setups.


If R3 can be reliable then I would be tempted to use it for what I have in mind on a 64KB machine. If it is still dodgey to use I would use 128KB machines or memory expansions and use 32KB screen space and avoid R3.


Any advice would be great before I decide which direction to go

[TotO]

I can't answer to you about the R3 values, but here my point of view about its usage into games:
- R3 allows smooth horizontal scrolling for amazing games like Relentless
- The CPC was originaly sold in combo with its monitor and it is compatible
- When sold with a MP2 adapter, the TV Set was CRT compatible too
- Many peoples use emulators today and R3 display fine on them
- High end LCD TV like Toshiba (not Samsung) display properly

[GUNHED]

For our Giana Sisters Clone we use R3 scrolling, as far as I see it works with all CRTC's. (See first video)


It also can be used to "slow" scrolling, see 2nd video (end of it).





https://www.youtube.com/watch?v=FGfhO-VGNzs



https://www.youtube.com/watch?v=zBXRbDGjYYQ


It's more smooth on real CPCs.

[Rhino]

For our Giana Sisters Clone we use R3 scrolling, as far as I see it works with all CRTC's. (See first video)


It also can be used to "slowe" scrolling, see 2nd video (end of it).





https://www.youtube.com/watch?v=FGfhO-VGNzs



https://www.youtube.com/watch?v=zBXRbDGjYYQ


It's more smooth on real CPCs.

Those are amazing games. Are they finished?

[Rhino]

Now that I have retired, I always wanted to go back and write a game for the CPC - the first computer I learnt z80 on.


From what I remember about using R3 is that the values may work on one CRTC and not others. What are the safe values to use? What are the best practices for it's use? I presume that you need the standard values at the beginning and end of a frame, then do a rupture in the middle for a scrolling screen, while the top and bottom of the screen use panels that are standard CRTC values for the best chance of compatability.


The idea I want to do is have one 16KB chunk for the scrolling screen divided into sections, so in the rupture you can show the parts for a Mode 0 1 pixel scroll. Sort of like the game Dropzone on the C64 but a slightly bigger scroll area at the bottom. I could do this without using the R3 scroll trick and have 2 areas of 16KB each for a double buffer screen arrangement. But this wastes memory and by using R3 I only need 16kB. That leaves plenty of memory for a game.


I also remember the R3 trick had issues on TV modulators and showed black an white images. Was there a clever trick discovered to stop that from happening? I don't care about modern TVs, Flat screens and such, so long as it will work on 80s setups.


If R3 can be reliable then I would be tempted to use it for what I have in mind on a 64KB machine. If it is still dodgey to use I would use 128KB machines or memory expansions and use 32KB screen space and avoid R3.


Any advice would be great before I decide which direction to go

I think you'll be interested in this thread:

http://www.cpcwiki.eu/forum/programming/a-pixel-scroll-with-register-3/15/

[AHack]

Those games look great! It's pretty sad that hardly any games used the full potential of the CPC. Those Spectrum ports basically crippled software development.


That thread is exactly what I wanted to read. It gives the best values to use. Also, from reading through it, the black and white images are not fixable for the TV modulator. That's a shame! I think most people probably owned the computer and monitor setup and is probably ok to use because of that.


Half of me wants to do what I have in mind for 64KB memory restrictions just as a purest challenge but 128KB is temping as well... you could do something special with that amount of memory.


My original thoughts on this years ago was to convert Dropzone from the C64 to the Amstrad. You could basically have 16KB screen divided up into 4 sections and do a rupture to do the scrolling at the bottom of the screen. The rest of the screen would be static and would be in another bank of RAM. Doing this way you can avoid using R3. You would need special sprite routines to detect the rupture cross over. But that was years ago and that really is not showing off what an Amstrad can do. I feel something better could be done, something that a C64 could not do.


Another technique you could do if you are willing to sacrifice colours is to have a 16KB screen, use mode 0 and restrict your colours to four and with careful palette switching you can embed 2 screens into one, then use the R3 trick to get a mode 0 one pixel scroll. So you end up with something like this:



https://www.youtube.com/watch?v=Y27tpOod364&t=93s


That will leave 48KB to the game. You could probably add in a vertical scroll to make it interesting. You still update the right hand side for the horizontal scroll but because you rupture a panel in at the bottom you have a bit of room to vertical scroll in.


If 4 colours is too restrictive you could make the game 128KB and do the same thing with 16 colours but sacrifice colour swapping for more screen memory. Basically a horizontal shooter with a bit of vertical scroll... now that would be something to see. With a 128KB you could avoid using R3 and have 4 screens (64KB) and the game has 64KB. With R3 you would have 2 screens (32KB) and the game has 96KB.


The purest in me wants to use 64KB but 128KB is very tempting. 4 colours or 16 colours is the choice. I'm having fun thinking about all this

[GUNHED]

Well (on CPC) what came from the scene during the last years was / is more often far better than 99% of the commercial games. (Our stuff will hopefully be finished till next year too). 
This weekend I had the time again to use R3 scrolling with CRTC2 and in this case a green monitor, works well.    (CRTC 0, 1, and 6128 Plus work of course too).

[AHack]

Well (on CPC) what came from the scene during the last years was / is more often far better than 99% of the commercial games. (Our stuff will hopefully be finished till next year too). 
This weekend I had the time again to use R3 scrolling with CRTC2 and in this case a green monitor, works well.    (CRTC 0, 1, and 6128 Plus work of course too).

I did some tests on real hardware today and my ruptures and scrolling section work as expected. I agree that 99% of commercial games were crap back in the day. Admittedly a lot of these techniques were not around in the early days of the machine and from the word go publishers wanted Spectrum ports... which basically killed the creativity that should of come. The Amstrad CPC never really used it's full potential until in recents years with some great homebrew games.


The 17 year old me from the 80s would of loved the little demo I did today, running on real hardware (emulators don't do it justice)... if I had written the demo back then it would of made such a big impact. I'm lously basing my idea off a well known C64 game. I think the Amstrad version will run rings around it.


Also, I would like to say Winape is such a good tool to develope and test things quickly. I shudder to think of the processes involved in getting something to run like it was still the 80s.

[Longshot]

Skatewars used register 3 to slow down the hardware scroll en 1989 (Coder Jon Menzies).I do not know if this was used in other games of the time.https://www.youtube.com/watch?v=swe-83TA6hc

[AHack]

In the end I decided not to use R3 for scrolling because I want my project to work on every thing with no issues and such.


So how do you get a variable speed horozontal scrolling playfield working with the restrictions of a 64K machine? Thinking about it you have one choice really... you have one 16KB area that is static and the other 16KB area you fit four screens worth into it for scrolling. Fitting four screens worth leaves an area not very big in the vertical size. With this restriction you can do a game like Dropzone which was on the Atari 800 and C64 and do a much better job with what the Amstard has to offer.


The project I'm working on will be sort of based on a Dropzone type of game. The advantage of doing a game like this is the static screen is ideal for fast sprite plotting with very rare plotting in the scrolling area. Also, with using ruptures you get overscan top and bottom which will make the game stand out from what the Atari 800 or C64 can do. Another great thing about a game like this is there is not much in the way of graphics and maps to eat into memory. It's actually the ideal horozontal scrolling type game for the Amstard.


The 17 year old in me is excited about doing this! Going back and programming the Amstrad again you start to realise that it has hidden potential to beat machines like the C64.