One for Rich really.

I've been looking at your vertical 'rupture' code and trying to adapt it to my own requirements.

However I'm not very up to speed on 6845 registers etc. On your example you set (I think) a mode 2 screen 16 chars wide with these vdu settings;



So when I try and scroll my screen in my game using the main code the screen scrolls lovely and smoothly but the actual level graphics are plotted incorrectly as they are designed for a wider screen.

I realise I just need to omit the code that sets the 16 char wide screen to get full width. But in doing so the scrolling breaks badly as I don't understand exactly what values in your code to alter to make it work with a full width screen.

The code I'm using is the test code you sent me once some time ago when you were looking at the problems with BeebEm. You said it was ok to 'borrow' it

Do you want me to list it for you ? Or have you got a copy.

By the way thanks for all your vertical rupture work, the scrolling is uber smooth

One of the things you'll likely need to do is correctly set the hardware scrolling wrap-around offset. In the demo it's set for a 10k screen so that the screen wraps back around to &5800. If your screen is bigger than this, you'll need to adjust it accordingly.

It's the lines which go something like:



or somesuch.

The values for other screen sizes are in the AUG, but I seem to remember that in my edition of the AUG, they were completely wrong, so maybe you'll just need a little trial and error.

As far as a full-width screen goes, yep - there's no more to it than setting CRTC R1 = 80 and CRTC R2 = 98 (defaults for Mode 2), or of course omitting the setup completely if you're already in Mode 2!

See if that does the trick!

I feel a right thicky with all this but must admit that I'm somewhat lacking in my 6845 skills.... to say the least.

I presumed from the lines above you were programming registers 12,13 of the 6845, but altering the value of 15 either way didn't seem t make any difference to what I saw. I have seen where you use the value &58/8 and presume that was something to do with screen start as well.

I think my problem maybe that I need to program my screen for the size i want then alter the rest of the code.

I'm planning the following. 2 char lines for score etc. and 18 char lines for the playing area. Am I right in saying that I also need a blank line just above and below the playing area to allow for that area to be shifted up/down a pixel line at a time ? if so that's a total screen of 22 char lines. Or 13.75K

So maybe if I tackle getting my custom sized screen correct first it might then be easier to get the scrolling working.

Hi Steve,

Ok, the problem is this:

The Beeb video hardware imposes certain limits with regard to hardware scrolling, namely that there are only 4 hard-coded screen sizes which can be used - 8k, 10k, 16k or 20k. These 4 possibilities are represented by 2 bits in the addressable latch. The reason this is needed is that the video hardware needs to 'know' which address to loop back to when the screen address reaches &8000.

If you turn to page 419 of the AUG, you can see how the addressable latch works. It is accessed via the bottom 4 bits of &FE40. Bits 0-2 hold the number of the addressable latch bit you want to write (0-7), and bit 3 contains the value to be written (0 or 1).

So, to turn the Caps Lock light off, we need to write a 1 to addressable latch bit 6 (the AUG doesn't mention it, but writing a zero turns the LEDs on, and vice versa), which would go something like this:



Interrupts are disabled to ensure the OS doesn't get to change any register values midway through the process.

As you can see, addressable latch bits 4 and 5 control the screen size. The values they represent are totally hardcoded just to be able to accommodate all the standard Beeb modes - the problem with this is that even if you wanted to have a 12k hardware scrolled screen, you'd have to specify a screen size of at least 16k in the addressable latch, and hence allocate this much screen memory, even if you didn't display it all at once.

The other problem is that the AUG is wrong regarding the meaning of the bits! The correct table should look like this:



All this addressable latch business is doing is defining the screen size for the video hardware, so that it knows where to wrap-around to. The start of screen address is still set using CRTC R12/R13, as you've seen.

Anyway, here's the bad news: you'll have to rethink the screen size of your playing area so that it's either a 10k or a 16k screen. Assuming you want to keep the screen at full width (20 characters), a 10k screen would be 16 lines high, but actually you could only display 15 at once due to the way the technique works (this is the 'hidden' line that is scrolled on from the top of the screen that you alluded to - there's no equivalent at the bottom though). Or alternatively, a 16k screen would be 25 lines high (but again, only able to display 24 at once).

In my demo, I have exactly a 10k scrolling area (16 Mode 2 characters wide * 20 lines), and then an additional 2 line window underneath which isn't scrolled. As before, only 19 lines of the playing area are actually displayed in total. This seemed to be the best compromise between size of play area and memory usage.

Hope this hasn't shafted your plans too much

Give me a shout if there's anything else I can give you a hand with.

Hi Rich,

That's a great explanation, thank you.

I've just done some testing and 15 visible lines is too restrictive so will have to go with the 25 line (16K) version. I can't alter the horizontal resolution as it would mean a lot of jiggling with the graphics and possible re-think of some levels, which isn't practical if I wish to keep reasonably faithful to the original.

I really wanted that 6.25K of memory to actually store the current island and graphics in and putting this down to 4K is really putting me up against it, but in a good way, it'll be interesting to still get it all in there. I don't expect my game code to consume all the rest of the memory anyway, so still perhaps room for manoeuvre.

In order not to lose any more memory though I will have to put the score on the playing area (but a lot of versions did this) but that will eat into processor time though... decisions decisions.

Anyway, I'll have another stab at this tomorrow with this renewed knowledge

Thanks for your help.

I did my custom screen easy enough.

What I'm doing now is going through all your code, I've put names for addresses so that it reads easier and I'm now going through commenting it all. It's fascinating how it all fits together. The addressable latch on System VIA PortB bits 0-3 for instance. I'd have never spotted that from the code (although the section with it in did look weird when not knowing it was connected to IC 32).

When I've completed the task is it OK if I add it as a link on the Rupture page you've already done ? I think that would help anyone else who wants vertical pixel line scrolling.

Once I've commented it all ( and then hopefully understood it) I'll probably be able to get it going properly for me

oh yeah... I need to finish off that page sometime with the full explanation of the smooth scrolling. Guess that would've been helpful to you before...

One thing that's maybe worth saying is that my implementation of the technique relies on there being a static window underneath the playing area. It'll still be possible to go without it, but then your timing has to be much more sensitive, or you'll get little flickers of the top of your playing area again underneath.

Maybe give me a day or so and I'll try and update the page with some more details... maybe could help you a little too! Of course feel free to add anything in - it is a Wiki after all!

I've just been doing some tests using simple code so I can grasp the effect different registers have on screen when I noticed something....

You mentioned you could have a 16K scrolled screen, which would be 25 lines. However 16K (16384) is not an even number of lines, it's 25.6. Would this be an issue ?

If not an issue I'm waiting with baited breath for your Wiki update as I'm totally struggling getting 25lines to work despite going though your code !