troed wrote:Hmm. Now I haven't ever done any STE hw scroll coding myself so my knowledge on how it works is based on writeups by others. It's quite telling that it's possible to gain 16 pixels always though.
This is handled in Steem and there's also this (simplified) code when the program reads the video counter.
Code: Select all
if (HSCROLL<>0 at cycle 0)
starts_counting=CYCLES_FROM_HBL_TO_LEFT_BORDER_OPEN/2 - bytes_ahead
video_counter=video_counter_at_cycle_0 + c
In short, the value is adapted by 8 if HSCROLL<>0.
That's correct or many programs wouldn't work. And I also (think I) saw this on my STE.
Video counter starts earlier only if HSCROLL<>0, I try to reconcile this with your writeup.
In the STE there's no separate GLUE/Shifter/MMU anymore.
I'd like this to be clarified, I've read MMU+GLUE, or MMU+Shifter, so is it GLUE+MMU+Shifter?
We can speculate as to all the reasons of why - but one reason besides lower cost could be that the amount of signals between these chips was getting high when adding hw scroll. The only "chip" able to do the 1 pixel manipulation needed by hw scroll is the "Shifter", so I don't think there's anything else needed in the GLUE statemachine. It simply raises PRELOAD earlier than on the ST, and the signal PRELOAD is then handled according to the pseudo-code as seen by the "GLUE", but as seen by the "Shifter" it then takes the hw registers into account when deciding when to start outputting pixels. (And since the chips are no longer separate this is of course not separate logic with separate signals). This also suggests the "MMU" puts the video addresses on the bus earlier than on the ST for the information to already be available for the "Shifter" to output - if anyone has scoped that it would be good to verify.
In your writeup you state yourself that the video counter doesn't change:
VAR PRELOAD MMU starts LOADing Shifter with words for hardware scroll purposes, no screen address changes
I don't see how the MMU can fetch memory and not change the counter, nor what it does after preload in that case: fetch same memory? Always prefetch 8 bytes in advance of counter?
I think that your fine explanations for those shifter tricks, included 2 novel ones you found:
Code: Select all
4 IF(RES == LO) PRELOAD will run until cycle 16 (56-16)/2 = +20
44 IF(RES == HI) PRELOAD will exit after 4 cycles (376-44)/2 = +6
48 IF(RES == HI) PRELOAD will exit after 8 cycles (376-48)/2 = +4
work because the video memory isn't fetched during preload when HSCROLL=0.
If you compare +26 with +20, on a +20 line, there are 12 cycles/6 bytes more of non-fetching during preload.