BBC Basic scrolling and examples with graphics

Hello, I recently discovered BBC Basic exists in RISC OS, for the pi. I know some ZX Spectrum BASIC and have wanted to make a game since I was a kid. So, I would appreciate some input to my questions:

Is smooth vertical scrolling possible?
Are there graphics related (and other) examples to learn from?
There seems to be one book available for the RISC OS BBC Basic, I am sure the book is great but shipping alone to me is 40 pounds. Are there BBC Micro BASIC books that cover graphics that you would recommend?

Thank you for your valuable time.

KB

Kevin: my apologies, when clearing up some spam before I woke up properly, I inadvertently deleted your account. You will have to re-create it.

Dave: oops!

Kevin: I wonder if the Archimedes Game Maker’s Manual might be of assistance? The ARM cove will not work (it is written for an older type of processor) but the BASIC and general concepts should be just fine – http://www.riscos.com/support/developers/agrm/

To be honest, though, that book was written in the days when 8MHz processors were commonplace, and these days we’re at least 100x faster. So you probably won’t need to worry about assembler. All of the popular AmCog games (http://www.amcog-games.co.uk/) are written in BASIC.

No Worries Dave. Mr. Murray I guess my concern is that as I am past middle age by a significant margin, with kid, job etc, time is limited. I would like to be sure that the language suits my needs. For the unshaded vector style game I want to make I am looking for smooth vertical scrolling and fast line drawing. I would prefer to not spend 60 some pounds on the BASIC book only to find out these things are not doable. I appreciate everyones time and guidance.

Thank you.

KB

I think Rick was pointing at the AMCOG link to emphasise the fact that BASIC is in use to do the things you’re talking about. The first link should provide

1. Plenty of reading material if you browse through the complete text
2. A zip file full of examples of what can be done and how.

As noted by Rick any assembler code is likely to need a little work to remove dependencies on the behaviour of the old CPU’s but even that isn’t that arduous most of the time.

Have a read of the material on the first link and come back with any questions. There are more texts out there with transferable knowledge.

I would prefer to not spend 60 some pounds on the BASIC book only to find out these things are not doable. I appreciate everyones time and guidance.

Some confusion? the book is £25, international postage (assuming you’re outside the EU) is £15.50, so £40.50 in total not sixty

Unfortunately import duty and local sales tax could easily be £20 :-(

Is smooth vertical scrolling possible?

Yes. My application !SignalBox (available from !Store for RISC OS and from my web site for Windows) implements scrolling by following the mouse movement and when it gets close to the edge of a scrolled window (one that cannot fit the whole work area inside the viewport) moves the work area as the mouse gets closer to the edge and slows down the mouse movement (on screen) to suit. It was not that easy to implement …

Look for PROCautoscroll here

The guts of how to do it are in the Programmers’ Reference Manual though (rather than a BASIC tutor). This is in Documents.Books.PRMs on the Raspberry Pi.

Yes. My application !SignalBox (available from !Store for RISC OS and from my web site for Windows) implements scrolling by following the mouse movement and when it gets close to the edge of a scrolled window (one that cannot fit the whole work area inside the viewport) moves the work area as the mouse gets closer to the edge and slows down the mouse movement (on screen) to suit.

That’s scrolling in a Wimp window, which wasn’t what I read the OP as asking for, however. My impression was that we were talking full-screen games…

In which case, as I recall, hardware scrolling in one direction is easy but in the other less so (I have a memory of vertical being easy, and horizontal only working in blocks of multiple pixels, but that could be reversed). But, as others have said, we now have far more processor power than anyone dreamed of in the old days.

So, I’m going to echo those who have said “AMCOG”, and – more specifically – the AMCOG Development Kit which is available through PlingStore (!Store, which I think comes installed on the Pi image). It’s a BASIC toolkit of parts to make games like those in the AMCOG stable, and should provide all of the guidance that the OP needs.

It was not that easy to implement

In your usage case, isn’t it much easier to get the Wimp to sort it for you, using Wimp_AutoScroll?

Is smooth vertical scrolling possible?

Yes, smooth scrolling is possible, but how you implement it will depend on the machine/OS version you’re coding it for.

Assuming you have a Pi running RISCOS 5 then you can either update the full frame during VSync using triple buffers (see OS_Byte 112 / 113 for details), or you can stick with one screen buffer and scroll it by setting the start address of the screen via OS_Word 22

Use a combination of OS_ReadVduVariables 149 and 7 to get the screen start address and size. Getting the start of the framestore and its size is a bit more difficult, as I don’t believe there is a way to do it directly.

To get the framestore information, you need to use OS_CallAVector to call GraphicsV 9 to get the physical address of the framestore, then convert that to a logical address via OS_Memory 0

EDIT: Error corrected

In your usage case, isn’t it much easier to get the Wimp to sort it for you, using Wimp_AutoScroll?

That call is not in the PRMs so I didn’t know about it.

Use a combination of OS_ReadVduVariables 149 and 150 to get the screen start address and size.

150 gets the total screen memory (i.e. framestore size). The size of one bank is indicated in mode variable 7.

Getting the start of the framestore and its size is a bit more difficult, as I don’t believe there is a way to do it directly.

Select the first screen bank (i.e. bank 1), and then read VDU variable 148/149 (as appropriate) and 150. Should work on everything except RISC OS 6 (which doesn’t map screen banks as one contiguous buffer, and doesn’t support OS_Word 22). Edit: Possibly won’t work on RISC OS 4 either.

To get the framestore information, you need to use OS_CallAVector to call GraphicsV 9 to get the physical address of the framestore

Which will only work on RISC OS 5 machines which aren’t using the screen dynamic area.

OS_CallAVector can’t be used from BASIC.

Not true for a very long time; I think it was BASIC 1.05 which fixed SYS to allow the “full” set of registers to be used (R0-R9). Or at least, that’s the version I listed when I was helping update the BASIC manual.

That call is not in the PRMs, so I didn’t know about it

Printed version I assume.
A quick search¹ in the online resource reveals this page created back in 2009 and last edited in 2013.

{1] I vaguely recalled seeing autoscroll referenced, so I just threw a query at a certain lookup engine.

Select the first screen bank (i.e. bank 1), and then read VDU variable 148/149 (as appropriate) and 150

Is that documented anywhere? If that works for RISCOS 5, then that’s easier than faffing about with physical address conversion. It’s not necessarily true of all RISCOS versions though. I seem to recall RISCOS 4 maps the banks in reverse order and in 1MB chunks, which is one of the reasons I stopped supporting it for gaming.

Which will only work on RISC OS 5 machine

Hence my opening statement about it being different based on machine/OS version and then going on to say…assuming a Pi with RISCOS 5.

The only sure way to do smooth scrolling that works across all machines/OS versions is to triple buffer and redraw the whole frame…which probably isn’t going to cut it in BASIC.

Not true for a very long time; I think it was BASIC 1.05 which fixed SYS to allow the “full” set of registers to be used (R0-R9)

Never knew that, have now removed that bit from my post to save confusion.

It’s a bit of a stretch but some of the demos from here http://www.bbcbasic.co.uk/index.html work on brandy, so they may work in RISC OS.

That call is not in the PRMs so I didn’t know about it.

It’s from the Nested Wimp, so it’s only 20 years old… :-)

The old Acorn-era PRMs aren’t a good reference any more, unfortunately: there have been too many changes which never got documented in them. The Nested Wimp, which arrived just before Acorn’s demise, is a good example, but there’s plenty of other stuff as well.

The ROOL Wiki PRM is a good place to start for adding in the missing bits, as are the StrongHelp manuals. Beyond that, it can be a tricky job to fill in the gaps — but for many developers, just being aware of changes to the Wimp (which are in the Wiki) is often enough.

Is smooth vertical scrolling possible?

Way back (with slower machines) vertical scrolling was very quick as the pointer to where the screen started in memory could just be changed. One line of data (the one that disappeared off the top/bottom and appeared at the bottom/top) would have to be written as well. This was hardware scrolling.

Now a machine like the ARMX6 needs hardware acceleration (which it now has) to make vertical scrolling (e.g. f12 then *HELP modules) fast.

It’s from the Nested Wimp, so it’s only 20 years old… :-)

Is it present on VRPC? Any programme I write has to work on VRPC so the PRMs are what I use.

Select the first screen bank (i.e. bank 1), and then read VDU variable 148/149 (as appropriate) and 150

Is that documented anywhere?

I don’t think so.

If that works for RISCOS 5, then that’s easier than faffing about with physical address conversion.

I’ll admit I can’t remember if I’ve tried it, but I’m fairly certain it’s true. It should be easy enough to test on a machine which uses the screen DA – check if bank 1 is always located at the start of the DA. AFAIK RISC OS 5 uses the same logic for calculating bank addresses as RISC OS 3.

I seem to recall RISCOS 4 maps the banks in reverse order and in 1MB chunks, which is one of the reasons I stopped supporting it for gaming.

Yeah, I guess that’s possible – I’ve added a note to my post, thanks.

Now a machine like the ARMX6 needs hardware acceleration (which it now has) to make vertical scrolling (e.g. f12 then *HELP modules) fast.

Vertical scrolling is still possible, to a limited extent. The big feature that’s missing is having the video DMA wrap back round to the start of the buffer if it runs off the end – it’s essentially the difference between the GPU treating screen memory as a flat piece of paper that can be shifted up and down, or a piece of paper that’s been rolled into a tube and can be scrolled forever. Unfortunately the code which scrolls the screen at the command line only deals with the latter case. On some machines there are also some hardware tricks which could be used to get the wrapping behaviour working.

It’s from the Nested Wimp, so it’s only 20 years old… :-)

Is it present on VRPC? Any programme I write has to work on VRPC so the PRMs are what I use.

You decide if it is present. WIMP 3.98 is the “Nested WIMP” version, and can be softloaded on everything since RISC OS 3.10. It is part of “Universal Boot”. It is in-built in everything from RISC OS 3.80 upwards.

Have try with my PiTopV1. It kills not the complete keyboard. Only the “Mouse” (TouchPad + Button). The keyboard and a external Mouse is working but I have not a Hub here, so only one USB port is usable.
If I use the commandline I have access to the Floppy.

I seem to recall RISCOS 4 maps the banks in reverse order and in 1MB chunks, which is one of the reasons I stopped supporting it for gaming.

Erm. RO 4.39:

Incidentally, doing this reminded me that OsByte 112 and 113 are buggy (and OsByte 250 completely useless) for reading bank numbers. Sadly the only reliable way to read the banks is like this:

SYS6,112TO,V%:IFV%=0:SYS6,112TO,V%
SYS6,112,V%:SYS6,113TO,B%:IFB%=0:SYS6,113TO,B%
SYS6,113,B%:PRINT"VDU bank: ";V%'"Display bank: ";B%

What joy. (This is true of RO5 as well as RO4)