log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- 10 RISC OS gift ideas for Christmas (News:)
- Drag'N'Drop Autumn edition now available (News:)
- !DualHead puts 2 screens in one (News:)
- RISC OS London Show 2017 - Notes from the talks (News:6)
- November News (News:)
- !Organizer 2.28 reviewed (News:2)
- !OBrowse reviewed (News:10)
- Aemulor (Gen:16)
- DDE reaches release 28 and above (News:)
- Elesar quicks dispels stormy clouds (News:2)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
Site Search
 
Article archives
The Icon Bar: Programming: Double screen banks
 
  Double screen banks
  swirlythingy (22:20 19/7/2012)
  swirlythingy (12:11 23/7/2012)
    arawnsley (12:19 23/7/2012)
      swirlythingy (19:24 23/7/2012)
    Phlamethrower (19:20 23/7/2012)
      swirlythingy (19:28 23/7/2012)
        CJE (10:36 24/7/2012)
  davidm_uk (17:58 10/12/2012)
    Phlamethrower (18:22 10/12/2012)
      swirlythingy (21:31 10/12/2012)
        davidm_uk (09:40 11/12/2012)
          swirlythingy (16:44 11/12/2012)
            sa_scott (20:33 11/12/2012)
        Phlamethrower (10:24 11/12/2012)
 
Martin Bazley Message #120825, posted by swirlythingy at 22:20, 19/7/2012

Posts: 460
Can anyone suggest a foolproof way of changing into a screen mode with two banks (from a single-tasking task), that works on RISC OS 3, 4, 5 and 6?

I've tried OS_Byte 114 to force shadow state, but that causes the Wimp to get confused when the program exits on RISC OS 3.

I've tried cacheing the current screen mode and changing back into it manually, but that errors on an ARMini.

I've tried using OS_ChangeDynamicArea 2 to force the screen memory to be big enough, but that functionality seems to have been removed in RISC OS 6.

There must be some way to do it, surely?

NB: I'm using a mode specifier block, not a mode number, so "MODE 128+28" is out.
  ^[ Log in to reply ]
 
Martin Bazley Message #120835, posted by swirlythingy at 12:11, 23/7/2012, in reply to message #120825

Posts: 460
There must be some way to do it, surely?
...So, that's a no, then? unhappy
  ^[ Log in to reply ]
 
Andrew Rawnsley Message #120836, posted by arawnsley at 12:19, 23/7/2012, in reply to message #120835
R-Comp chap
Posts: 465
If your first option works on everything but RO3 (which is set in stone), why not use that method, but trap OS3 and use method 2 (if it works) in that scenario?

I appreciate that it isn't the most elegant solution, but it just means that you're providing a legacy code-path for OS3 users, and a general codepath for everyone else. Not unreasonable to ensure compatibility with 20 year old computers...
  ^[ Log in to reply ]
 
Jeffrey Lee Message #120839, posted by Phlamethrower at 19:20, 23/7/2012, in reply to message #120835
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15057
There must be some way to do it, surely?
...So, that's a no, then? unhappy
Pretty much!

There's some documentation on ROL's site for the changes they've in RISC OS 6 with regards to screen banks: here for an overview and here for OS_ScreenMode. It looks like all you need to do is change into the target mode and then start trying to use the screen banks - the driver should then allocate the memory for you.

I've tried cacheing the current screen mode and changing back into it manually, but that errors on an ARMini.
Errors how? Remember that it'll most likely give you a pointer to a mode specifier block, so you'll have to copy the block somewhere.
  ^[ Log in to reply ]
 
Martin Bazley Message #120840, posted by swirlythingy at 19:24, 23/7/2012, in reply to message #120836

Posts: 460
I'm just convinced that, given that double screen banks was the single most common technique employed on a multitude of RISC OS computer games, there absolutely must be an approved way of doing it. Surely something as important as that would never be forced to rely on undefined or deprecated behaviour in the OS?

Andrew, you have the Krisalis back catalogue, so you must know what I'm talking about. What do those games do when they want to use double-buffering?
  ^[ Log in to reply ]
 
Martin Bazley Message #120841, posted by swirlythingy at 19:28, 23/7/2012, in reply to message #120839

Posts: 460
Errors how? Remember that it'll most likely give you a pointer to a mode specifier block, so you'll have to copy the block somewhere.
That's what I was doing (which works on everything else I've tested it on), but I had to remove that code because it caused a "Screen mode not available" error when I tried to change back into the block I had just copied. Mad, I know...

Has there been some sort of backward-incompatible change made to the OS since RISC OS 3 which means there is no longer a defined way of allocating screen memory?
  ^[ Log in to reply ]
 
Chris Evans Message #120844, posted by CJE at 10:36, 24/7/2012, in reply to message #120841
CJE Micros chap
Posts: 198
Errors how? Remember that it'll most likely give you a pointer to a mode specifier block, so you'll have to copy the block somewhere.
That's what I was doing (which works on everything else I've tested it on), but I had to remove that code because it caused a "Screen mode not available" error when I tried to change back into the block I had just copied. Mad, I know...

Has there been some sort of backward-incompatible change made to the OS since RISC OS 3 which means there is no longer a defined way of allocating screen memory?
I would have expected "MODE 128+28" to be the official way initially.
Maybe they never defined an official way for dual bank when using a mode specifier block!
  ^[ Log in to reply ]
 
David Miller Message #121632, posted by davidm_uk at 17:58, 10/12/2012, in reply to message #120825
Member
Posts: 2
I've tried using OS_ChangeDynamicArea 2 to force the screen memory to be big enough, but that functionality seems to have been removed in RISC OS 6
Interesting... I'm having trouble using this technique in RISC OS 5 (and it definitely worked in 3, 3.5, 3.6 and 3.7). Are you sure it was removed in 6, or could it have been removed earlier (which would explain my problems)?

I will try OS_Byte 114. Is this different to *SHADOW 1?
  ^[ Log in to reply ]
 
Jeffrey Lee Message #121633, posted by Phlamethrower at 18:22, 10/12/2012, in reply to message #121632
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15057
Errors how? Remember that it'll most likely give you a pointer to a mode specifier block, so you'll have to copy the block somewhere.
That's what I was doing (which works on everything else I've tested it on), but I had to remove that code because it caused a "Screen mode not available" error when I tried to change back into the block I had just copied. Mad, I know...
This is fixed now! (Actually a few weeks ago, but I forgot about this thread)

I've tried using OS_ChangeDynamicArea 2 to force the screen memory to be big enough, but that functionality seems to have been removed in RISC OS 6
Interesting... I'm having trouble using this technique in RISC OS 5 (and it definitely worked in 3, 3.5, 3.6 and 3.7). Are you sure it was removed in 6, or could it have been removed earlier (which would explain my problems)?
For RISC OS 5, it only works for machines which actually use the screen dynamic area - i.e. BeagleBoard & PandaBoard. Iyonix & Raspberry Pi don't use the screen dynamic area, so there's no way to request a specific number of screen banks - you're just stuck with however many the system decides to give you.
  ^[ Log in to reply ]
 
Martin Bazley Message #121634, posted by swirlythingy at 21:31, 10/12/2012, in reply to message #121633

Posts: 460
This is fixed now! (Actually a few weeks ago, but I forgot about this thread)
What, you mean it was an honest-to-goodness bug in the OS all along? Given that was the original error which caused me to start attempting to rewrite large parts of Magic Mushrooms, that's actually pretty annoying. Mind you, I did get some much neater code, several fixed longstanding bugs and a substantially rewritten editor out of the whole caper, so I probably made a net profit.
For RISC OS 5, it only works for machines which actually use the screen dynamic area - i.e. BeagleBoard & PandaBoard. Iyonix & Raspberry Pi don't use the screen dynamic area, so there's no way to request a specific number of screen banks - you're just stuck with however many the system decides to give you.
Does this mean that bank-swapping is technically completely impossible, or just that dynamic area 2 is deprecated?

I'm not running the bleeding-edge builds on any of my computers, so could someone tell me if the game still works without flickering?

If it does, David may find the code I eventually settled on educational. It involves a combination of OS_Bytes 114, 251 and 112, and you need to manually undo some of it in your program's exit routine. I'm no longer entirely sure what it all does!
  ^[ Log in to reply ]
 
David Miller Message #121638, posted by davidm_uk at 09:40, 11/12/2012, in reply to message #121634
Member
Posts: 2

If it does, David may find the code I eventually settled on educational. It involves a combination of OS_Bytes 114, 251 and 112, and you need to manually undo some of it in your program's exit routine. I'm no longer entirely sure what it all does!
Martin,

I would definitely be interested in seeing this!

David

[Edited by davidm_uk at 09:40, 11/12/2012]
  ^[ Log in to reply ]
 
Jeffrey Lee Message #121639, posted by Phlamethrower at 10:24, 11/12/2012, in reply to message #121634
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15057
This is fixed now! (Actually a few weeks ago, but I forgot about this thread)
What, you mean it was an honest-to-goodness bug in the OS all along?
Yes. Sorry!

For RISC OS 5, it only works for machines which actually use the screen dynamic area - i.e. BeagleBoard & PandaBoard. Iyonix & Raspberry Pi don't use the screen dynamic area, so there's no way to request a specific number of screen banks - you're just stuck with however many the system decides to give you.
Does this mean that bank-swapping is technically completely impossible, or just that dynamic area 2 is deprecated?
Just that dynamic area 2 is deprecated.
  ^[ Log in to reply ]
 
Martin Bazley Message #121644, posted by swirlythingy at 16:44, 11/12/2012, in reply to message #121638

Posts: 460
If it does, David may find the code I eventually settled on educational. It involves a combination of OS_Bytes 114, 251 and 112, and you need to manually undo some of it in your program's exit routine. I'm no longer entirely sure what it all does!
I would definitely be interested in seeing this!
Good for you. Have you tried downloading the game?
  ^[ Log in to reply ]
 
Stephen Scott Message #121657, posted by sa_scott at 20:33, 11/12/2012, in reply to message #121644
Member
Posts: 70
FYI, I've included the URL of this thread in a 'live' document, which I've posted about on the ROOL and Raspberry Pi forums.

The document is on Google Docs:

https://docs.google.com/document/d/1EcaOgk704TPt5hruKm-hVUuVT_iWtnG8BRUaIUU-Jd0/edit

I'm trying to get together a guide of how to convert old games to RISC OS Pi, with three distinct sections on sprite handling, mode independence, and screen banking.

Wish I had more time to muck about with my Pi, I am desperate to get my games working on it. big smile
  ^[ Log in to reply ]
 

The Icon Bar: Programming: Double screen banks