...with an example disc image and a basic walkthrough of how it all works. Any comments or grunts of bemusement welcome

That is a great article, I and a friend (Gil Jaysmith - Repoton 1&2 on Specky) spent many hours staring at registers and grumbling about FireTrack - if only we had had your clear and concise article then.

I didn't use your method, but changed the number of scan-lines per row to 4 (skipping alternate 4 bytes) for a rally-x game that I never finished.

Thanks! I too was completely baffled by how it could work, having seen it only once, and I didn't even have the game so I couldn't reverse-engineer it! (As it happens, it doesn't use the same method as I described - instead it insists on some really timing sensitive trick where it adds extra scanlines into just one screen row.) It was only after reading some Amstrad CPC articles on this very subject that I finally managed to reproduce the effect on my Beeb. If only I'd known then what I know now.....

By the way, Fortress does the same thing as you were doing - sets 4 line screen rows, to achieve that nice diagonal scrolling. I hope it finds creative ways to interleave screen data with other data, otherwise that's a heck of a lot of memory wasted!

Fortress - I hadn't really thought about it - Oh well, another re-invention.

sprites fit nicely as they have to be in blocks of 4 too - code doesn't fit so well

I also adapted the mapping system that I used on a version of black tiger that i was writing (palettes of pallets of pallets of 1x4 byte blocks) to fit the 4 on/4 off.

If only I could find the code!

richard

Could either of you explain how the 4 scanlines per row thing helps with diagonal scrolling please?

I've been looking at how Fortress sets up the 6845 registers in BeebEm tonight but can't get my head around it. Is it just so that you can scroll in 4 x 4 pixel blocks (without resorting to vertical rupture) or am I missing something?

(I did bang my head earlier today so things might be clearer tomorrow!)

Thanks,

Rob

Yes, this just lets you scroll 4 pixels at a time vertically instead of the usual 8 - Apart from FireTrack, I didn't know of any other game that did less that 8 pixels vertically in the 80s.

Thanks for that - I was starting to think that there must be more to it but I guess it makes sense if one forgets about vertical rupture.

Interestingly, there is an Acorn User article from about 1983 that talks about veritcal rupture but as you say, I think it was only ever used in Firetrack.

Struggling to get back to sleep last night having been woken up by our eldest, I was thinking about Fortress and how much smoother it would have been if it had used vertical rupture. Then, a thought popped into my head: couldn't one combine the vertical rupture with displaying less than 8 vertical pixels per character (as Fortress does) to generate ruptures on more than just every character row?

You could presumably have a rupture at every line - this obviously wouldn't leave much time to do much else as you'd be modifying the 6845 registers every scan line. However, if possible, you could do some pretty impressive rippling demo effects either by scrolling each line horizontally or by duplicating lines to create vertical rippling.

Does this sound right or am I missing something?

Cheers,

Rob

Demo 128 (http://www.youtube.com/watch?v=_JoWIxHPGM4) uses this in three parts - the spinny tower thing, the wavy test card and the zooming chessboard. I did have a couple of other effects along these lines that didn't make it into the demo.

The problem is that you burn through memory extremely quickly - with 1 line per character only 1/8th of memory can actually be used for video, hence these effects can only really be done on a Master.

Thanks Tom - should have guessed that someone would have thought of doing this already

It's a very impressive demo - well done!

Hi RichTW,

I have a few questions about your smoothscroll vertical rupture sample:


310 .crtcvals EQUB127 : EQUB80 : EQUB98 : EQUB&28 : EQUB38 : EQUB0 : EQUB26 : EQUB31 : EQUB&F0 : EQUB7 : EQUB32 : EQUB8

Why set R6 to 26 and R7 to 31 in .init?


I don't see where the 8-"top screen" scan line offset is on screen for the second window unless it is the white bit, but if so, where is the status line?
When I do nearly the same thing, I have to disable video to not have the bottom line bouncing about. How do you avoid this? (or what have I missed?)


I guess vsync2 was from some other/debug/temp code.

Still not sure about those points, nor when T1 is used, but I have my version working, except for what seems to be the same issue as your demo.

There seems to be 8 blank scan lines, then the 8 variable ones.
Does anyone know if that is just the emulators, or if a real beeb is like that too?

It's been a while since I looked at this, but I'm not quite sure what you mean by 8 blank scan lines then 8 variable ones.

When 'line' is at 0, the top line of the character row should be the first visible line, and R5 will be set to 8. As line increments, R5 decrements and the screen is effectively moved upwards, with the raster interrupt masking the invisible lines.

The second window (at the bottom) is stationary, and is fixed in place by the second value of R5 (which is 8 minus the first). This ensures that the second screen always starts in the same place.

I noticed that B-Em sometimes behaves a little oddly with screen positioning if you don't have "Borders" set to "Full", so maybe try that in case it makes a difference.

Hi Rich, (or anyone else,) any ideas on how I can fix my timing?

http://www.retrosoftware.co.uk/forum/viewtopic.php?f=19&t=903&p=6600#p6600

Richard