Yeah, I thought that was disappointing. Don't know if the drivers could be improved, but it could be a limitation of the graphic card itself.

I just tried bank switching on my Iyonix in a 1152x896x32bit screenmode and it worked fine.

Using: SYS 6,112,n to switch output to bank n.
And: SYS 6,113,n to switch display to bank n.

The graphics card can do anything it can do in a PC, driver permitting. (so that means no 3D for now)

The thing is it seems to me like a particularly bizarre thing not to have. If you want to draw anything tear-free which will take more than 1 screen refresh to do, you're forced to draw it to some other bit of memory then copy the lot in an interrupt on v-blank. So wasteful, so inelegant.

I saw an innocuous little sentence in Mike Cook's review of the Iyonix which instantly made my heart sink.
If I read it correctly he says the graphics card (and hence the computer) cannot do bank switching... presumably this means that anything needing a shadowscreen will be broken, 32bit compliant or not.
Therefore few games will work and there is no easy way to make things run fast on all machines.

The thing is it seems to me like a particularly bizarre thing not to have. If you want to draw anything tear-free which will take more than 1 screen refresh to do, you're forced to draw it to some other bit of memory then copy the lot in an interrupt on v-blank. So wasteful, so inelegant.

[Edited by Loris at 16:56, 11/1/2003]

I somehow doubt that the graphics card doesn't support double-buffering. Perhaps it's just the particular flavour of RISC OS bank-switching that doesn't work, where you have screen memory located in main memory somewhere (where your game has full access to do whatever it wants with that memory) and would then have to transfer that across to the graphics card's memory when OS_Byte-whatever-it-is gets called.

As I suspected it's smug claptrap. Bank switching works on the Iyonix whether by the same mechanism or not as on RPCs.

I myself change the visible screen-bank with OS_Byte,113 but write to screenmemstart+n*screensize+[screenpos]

*slaps ksattic about a bit for owning an Iyonix when I don't*

Tony, if you let me know how to find out the base address of the second bank of screen memory, I can try this for you (BASIC code would be nice!)

Tony, if you let me know how to find out the base address of the second bank of screen memory, I can try this for you (BASIC code would be nice!)

IMO using screenmode+screensize to access the other bank is bad code. Use OS_ReadVduVariables like a good programmer does, fool!

And use MODE 13+128 to claim the extra RAM needed for the two banks, rather than assuming that the extra memory will be left over from mode 15.

/me tsks you for writing sloppy code

IMO using screenmode+screensize to access the other bank is bad code. Use OS_ReadVduVariables like a good programmer does, fool!

And use MODE 13+128 to claim the extra RAM needed for the two banks, rather than assuming that the extra memory will be left over from mode 15.

Well, at least I understand now why I used to keep coming over programs that had two MODE changes in succession...

[Edited by moss at 10:47, 20/1/2003]

Hey, my code's got smilies in it even though I unticked the smilies box. Has it always had them? Looked alright in preview..

Does the code actually work on a RiscPC? I get nowt but a flickering cursor on the Iyonix.

On the Iyonix, SYS"OS_ReadDynamicArea",2 TO scrmem% puts &51C00000 (hex) into scrmem%. This seems odd to me, because that points to an area of memory at approx 1.28GB. Does this have anything to do with screen memory being held on the graphics card and that memory peeks and pokes may not be able to access it?

Increased screen memory from the 0KB default (???) to something large and then tried again. Bank switching works because the cursor appears on one bank but not the other, but there's nothing drawn on either bank.

Speaking of which, Jeffrey, the PRM doesn't seem to do much to dissuade you from assuming that the screen banks are contiguous. Looking at the ReadVduVars options, it seems one would have to change the read or write bank then do this call to get the start of the current bank for each screen bank you wished to use. Is this what you were suggesting? - it seems like a bit of a chore. I am assuming one could cache the addresses at the start of the program, to avoid doing a costly SYS call in your game loop.

Well so far my screen banking programs have only used two screen banks, and call OS_ReadVduVars after each bank switch to re-read the addresses of the display & VDU bank. One extra SWI each frame isn't too much to ask to ensure that you've got the proper screen addresses, even if the PRMs make no suggestions that they might be at weird places.