Horizontal scrolling, scoreboards and CRTC. [SOLVED]

[Axelay]

I can't understand well your post (my low english level hitting me again), but are you saying that you achieved to "move" the interruptions position handling CRTC registers??
I thought that:

No, I'm not sure "what" I achieved!    But what I'm taking from this:

;; standard screen is 39 chars tall and vsync at 30
;; with 25 chars displayed
;;
;; we want to change this to 26 chars displayed with vsync at 31
;;
;; Char Lines to end of screen: 39-31 = 8
;; Scan Lines to end of screen: 8*8 = 64
;; Interrupt occurs two lines after VSYNC, so lines until end of screen when interrupt occurs: 64-2 = 62
;;
;; If we then wait for one interrupt, we will be 10 (62-52 = 10) lines into the next screen.
;;
;; Then interrupts are:
;; 10, 62, 114, 166, 218
;;
;; And we will then be 10 lines into second screen.

is that changing R7 will change when vsync occurs relative to the interupts.  So I'm asking is this meaning that the first interrupt 'effectively' moves according to the value in R7, such as now 10 lines into the screen rather than 2 in this example? (if I'm understanding it correctly)

[FatAgnus]

I understand it as:
R7 allow us select into which CHAR ROW interruptions "are restarted": when R7 is reached, VSYNC HAPPENS, and internal interruption scan counter  is set to 0, and when internal interruption scan is 2 again, INT0 is triggered (seeing INT0 as "the one with Vsync active"), so its position relative to screen does not change. R7=value selected->VSYNC triggered and internal INTERRUPT (no VCC/VLC) reset->when interruption internal counter=2, INT0 triggered...
So, when restarted, that CHAR ROW become the "first displayed" (VCC<>0, but as Vsync will happen, that line is "raised up" to screen top (still unseen, lets say "top of upper border")

I read that quote only as if the interruptions positions where "transformed" to "current  VCC/VLC" relative positions instead to "VSYNC/Internal int courter" relative positions.
INT0 is always scan 2 RESPECT VSYNC/Internal interruption counter (top of displayed screen).
INT0<>2 means it's expressed as "offset" respect current VCC/VLC (but still phisically at top of displayed screen)

I mean: R7 allow us decide which row of data-border will be the first one displayed over the physic screen, but not to decide when int0 will happen over the physic screen.
EDITED! First version of this post was trash! Sorry.

[Executioner]

The raster 52 divider (R52) is reset two scan lines after the VSYNC, and will continue to generate interrupts every 52 scan lines from that point, (unless it's top bit is reset with OUT 7Fxx, but I'd stay away from that if I were you).

The VSYNC position itself in the frame is directly affected by R7. The VSYNC will occur at (R9 + 1) * R7 scan lines into the frame, regardless of the R5 setting, So the first interrupt will always be (R9 + 1) * R7 + 2. (except see my note below..)

Changing register 5 (top_value) will move the next frame up or down the monitor, then after the next frame has started the R5 value should be 8 - top_value. These non-zero R5 values add up to give 8 scan lines and therefore require that R4 is one less for the whole frame. ie. (R4a + 1) + (R4b + 1) = 38, or for the whole frame ((R4a + 1) * (R9a + 1) + R5a) + ((R4b + 1) * (R9b  + 1) + R5b) = 312. This can be extended to as many splits as you like, eg. Add in ((R4c + 1) * (R9c + 1) + R5c).

In most cases R9 = 7 and there are 8 scan lines per character, so this equation (for a single split) is simplified to:

(R4a + 1) * 8 + R5a + (R4b + 1) * 8 + R5b = 312.

And for R5b = 8 - R5a it's:

(R4a + 1) * 8 + (R4b + 1) * 8 + 8 = 312

@Axelay: Changing R7 directly affects the position of every interrupt relative to the VCC/VLC up or down by (R9 + 1) scan lines since R52 is reset by the VSYNC interrupt. It's actually a bit more complicated than that, because the VSYNC interrupt itself will not actually occur if R52 is less than 32 at 2 scan lines after the VSYNC signal. In practice, so long as your screen has 312 scan lines this should never happen, but at 313 scan lines you'd get a R52 interrupt one scan line into the VSYNC.

[FatAgnus]

Superb explanation.

BTW, nice mode 1 scoreboard implemented...
...and, of course, time to avoid the use of DI-EI...
Splits are very tolerant when abusing of DI-EI.
But semi-linear buffer needed for the data to show into it (I cant use the free mem at &8000&c000, because screen's scroll will overwrite it), ISN'T tolerant at all... one scan of delay and you are dead.
It is time to learn about SET-RES optimization so I can leave my crappy-optimized code.

I love assembler. I will never end this project, but I love it.

[Axelay]

@Executioner: Thanks for the explanation.  I think I might be getting on top of this.  I'm fairly sure I "followed those rules" with the vertical scroll example, and I've since created a couple more variations of the original split code arnoldemu gave with different proportions, including one with 3 screens.  I just have to try them all on a real CPC next, and if they still work then I think I'll finally be in a position to create most kinds of split I could want for a game.

[arnoldemu]

@Executioner: Thanks for the explanation.  I think I might be getting on top of this.  I'm fairly sure I "followed those rules" with the vertical scroll example, and I've since created a couple more variations of the original split code arnoldemu gave with different proportions, including one with 3 screens.  I just have to try them all on a real CPC next, and if they still work then I think I'll finally be in a position to create most kinds of split I could want for a game.

So your next game may have smooth hardware vertical scrolling?
I'm drooling at the thought.

[McKlain]

A vertical scrolling shoot'em'up, perhaps? Hohoho 

[FatAgnus]

THANX EVERYONE.
New scoreboard fully functional, and game fully unstable.
Much better now (much better when game stabilized again, of course)

Let's kill a bunch of "di".

[Axelay]

Well I've had some success with testing, all 3 splits worked on the 464 (CRTC 0) and 6128 (CRTC 1), so I'm pretty happy about that.  At last! 


@arnoldemu: Many thanks for the example, seems to have been the final piece I needed.

So your next game may have smooth hardware vertical scrolling?

It's quite possible...    It certainly makes the option more attractive as I had started a vertically scrolling game over a year ago but put it aside because the split wasn't interrupt based and while 'interweaving' the game code with the split was only a minor headache,  the consequences of a game frame taking a fraction long also seemed too high a risk the more I thought about it.  So I'll probably take that code and adapt it for the new interrupt driven split for a start, then see how I feel about it, because it's still just a prototype and I'm still not sure I can get the code to match what I have in mind.


In the mean time though, I am very much looking forward to seeing how FatAgnus' game turns out.  Already sounds great too!

[McKlain]

Already sounds great too!

I'm glad you liked it, it was my first attempt at doing something for the CPC (and using Arkos). 

[FatAgnus]

Thanks Axelay, it's a proud for us to hear that from you.


Well, Blastardo is now stabilized with the new split-based-scoreboard (visual artifacts fixed and fail-safe to 25fps if slowdowns happens)
And yes, now there is a slowdown: putting Invader on top of  the Big Boss, with a bomb hanging of it, while shooting "laser", all at the same time, and we fall down to 25 fps... now code is slightly more time consuming, but, anyway, the new scoreboard worth it.


Time to optimize, addition of new gfx, more BigBoss movements-attacks, BigBoss shoots, better gameplay (eehrrmmm... there is NOT gameplay at all right now, so simply: "TODO: do it playable")... OMG...

[FatAgnus]

I'm coding Blastardo fully from WinAPE.
WinAPE is a superb piece of software, but, of course, it isn't a real CPC.
I use R3 register, so the new scoreboard (AND the Invader itself) could display shaking slightly left and right when running into real CPC hardware.
The scoreboard design is linear and simply, trying to "theoretically"  minimize the flickering.
BUT MY CPCs ARE 980km AWAY from me. I can't test it.


So I would be very grateful  if someone could test this version with real CPC464-CPC6128 hardware, with Amstrad's GT-CTM monitors (Blastardo WILL NOT WORK with modulators -I don't know valid R3 values for modulators, if there're ones-)
This is a "blind" project, and if it looks ugly running into real machines, it has no sense.


Thanks in advance.

[Axelay]

I was able to try this on my CPC464 on a CTM.  I transferred the main file to a tape image, and it still worked fortunately, or I'd have had to get the 6128 back out to try it!


Anyway,  I cant say I noticed any of the shaking I expected to see with the score panel.  I know I should be able to see it because I could when I subsequently tried one of my own R3 scrolling tests.  But with Blastardo I guess the contrast is a lot lower with the pale green background colour you've used (as opposed to the black I've been using) and you've gone with a simpler design rather than the high res text I used.  So I guess the significant point is that if it did exhibit shaking, it wasnt drawing my eye to it.  If I get some time I'll try it on the 6128 on the weekend as well.


Oh, and I "discovered" Tab drops a bouncy bomb! 

[FatAgnus]

THANK YOU VERY MUCH AXELAY!
It's a relief!
I was horrified imagining it "shaking insanely"!

I uploaded a CDT version (clean for "eyes", but crappy, for use only with CPC464), avoiding load screen's corruption ("press play" etc)

EDIT:
About bombs: the loader's scroller has "the history", key assignment, credits and greetings... yes, in Spanish. (time to add "Axelay" to greetings!)
"TAB" key load-throw-reload the "hanging bouncing bombs" (still with a limited "bouncing algorithm", they will bound against map instead screen limits... some day...). 2 bombs kill a computer, (6 bombs to reach Big Boss scene)

[FatAgnus]

Oppppssss! I'm hopping similar results over a GT monitor... its pixels are much more defined, it could be problematic...
I remember how fuzzy CTM pixels looked when comparing MY GREAT GT-CPC464 with a friend's CTM-CPC6128... 25 years ago!

EDIT: Wow! Trocoloco told me right now he tested it and display was OK over 6128+CTM...
AND OVER TV! He used a ihomemade SCART lead.
I miss so much my CPCs (I build a "speed write 0" CDT version only for hear it loading from JavaCPC's TapeDesk!)