Video memory locations on the RPi

Hi all,

I’d like to write to video memory on the Raspberry Pi in assembly. Does anyone have a list of the various memory locations in each video mode? I presume the RPi has a memory-mapped display?

Thanks,

Ben

You need to use OS_ReadVDUVariables – especially numbers 148-150.

Is all writing to video done through swi calls? It seems unnecessarily slow. On the PC, for instance, you can call int 10h, but it’s many times faster to write directly to &a000h.

Is all writing to video done through swi calls?

Erm, no. Which is why there’s a call to find the screen memory location, size and other metrics. Which I’ve just given you.

Once you have the screen address it won’t change without you being informed via a Wimp message (if you’re multitasking – if you’re singletasking the screen is yours to do with as you wish).

As nemo says, use OS_ReadVDUVariables to get the address of the video buffer.

Depending on what you’re doing, you may prefer to create an off-screen buffer (or sprite as we call them round here), draw directly into that, and then splash that onto the screen through a system call (OS_SpriteOp) taking advantage of hardware acceleration where available. But, it depends on what you’re trying to do.

What are you trying to draw?

In any OS there are backdoor methods and as in Windows people use them and then complain when the OS authors change the underlying code such that the backdoor doesn’t exist or doesn’t behave the same way.
The SWI calls are the published API.

In the RO world the chief users of the backdoor bits were games and of course various utilities.
Jon Abbot spends his time fiddling with old games to make them work on the newer hardware partly due to hardware driven change and partly due to people heading for the backdoor access.
I’m sure Nemo can list a few things broken by changes that didn’t touch the SWI access route (with a few inserted grumbles in the narrative)

Hi, thanks chaps – sorry nemo, misunderstood your initial response. At the moment, I’m just mucking about learning ARM assembler in RISC OS Pico. I expect if I’m let anywhere near the video memory, I’ll draw an invader, or something of that sort. :-)

Not trying to be particularly clever at the moment, but thanks for the tips on the off-screen buffer.

invader

OK, so bitimages. That’s Sprites

When I converted a game to run in a window I got it to write to a Sprite the size and format of the screen it thought it was using, then plotted that into the window every frame with OS_SpriteOp. There are various calls available, including simple ones that just blit the bits, and more complex ones that do scaling and format conversion on the fly.

Having had a quick read of the docs, it looks as though using the Sprite calls requires the SpriteExtend module to be loaded, which I don’t think happens in Pico.

I think in my case I’ll just have to make a call to get the display area and address the video area directly…

Having had a quick read of the docs, it looks as though using the Sprite calls requires the SpriteExtend module to be loaded, which I don’t think happens in Pico.

Depends which sprite calls you’re interested in – the basic operations are implemented in the kernel, and they might be all that you need.

https://www.riscosopen.org/wiki/documentation/show/OS_SpriteOp

The ones marked ‘1’ or ‘3’ require SpriteExtend.

Jeffrey – thanks for that.

That said, I’m concerned that as historically these routines have been taken out of the Kernel, there’s a chance other ones will be too in the future?

Those routines were not ‘taken out’ of the kernel, they were never there in the first place. They were added by SpriteExtend, hence its name.

Mind you, RISC OS Ltd spent an inordinate amount of effort taking things out of the RO4 Kernel and into separate modules for no adequately explained reason, so I can understand your assumption.

On the downside, the calls that SpriteExtend provided are the scaling and format-conversion ones that might be most useful. On the upside, SpriteExtend is distributable, so that’s OK.

Nemo,
I’m interested in trying out that game ‘BigBang’ that you posted a gif of. Is it available to download anywhere?

The original Big Bang is available here (and is wonderful – originally released by Psycore and written by Miles Visman… the graphics are lovely and quite mad)

I did not release my windowed multi-tasking version for two reasons:

1. The original hadn’t been released from copyright (as of 2015 it now has)
2. I disabled the sound

It was a pain to convert because internally it doesn’t use a stack, which made all the multitasking stuff more fiddly than it would have been.

However, to enable the sound to work I’d have to rip the sound code and all the samples out of application space and into the RMA. The simpler approach would be to move the whole executable into a Dynamic Area (don’t tell Jeffrey) so it can multitask the graphics while the sound runs on interrupts. My conversion predated DAs though!

I suppose I could revisit it – I do have source – but I’d have to put it on my list, and it’s a LONG list. Try the single-tasking version first… if you’re desperate for the windowed version, persuade me.

The original hadn’t been released from copyright (as of 2015 it now has)

Is there any proof of that? I can release it for use with ADFFS if I have documentary proof that copyright was released.

Just had it running with VRPC-DL RO 5.25.
(module z15 needed its 32bit flag set – is the module needed?)

Running in Demo mode – nice to watch?

Cross between a Cat & Dog :-)

The original hadn’t been released from copyright (as of 2015 it now has)

Is there any proof of that? I can release it for use with ADFFS if I have documentary proof that copyright was released.

Regarding the copies hosted on AcornArcade/TIB, AFAIK we were only given distribution rights.

http://www.iconbar.com/forums/viewthread.php?threadid=7182

Not sure if the situation has changed since then – presumably nemo knows more than I.

So sorry for the imprecision. If there is a version that can be distributed, then one can distribute an upgrade to that which does not contain any copyright material. Since there wasn’t a freely distributable version, I could not release a desktop version.

I bought my copy upon first release. I think BigBang, ArcElite and Pacmania are the only RISC OS games I ever bought.

Anyway, I have a few other things on my list to finish first.

z15

That little module implements a new mode – MODE 112 – which is derived from mode 15, the mode BigBang starts in. Theoretically, pressing M switches between the two modes in-game, but I don’t remember what effect it had or even if it worked.

It’s not used in the Desktop version.