| |
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?  |
| |
[ 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: 600
|
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 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
There must be some way to do it, surely? ...So, that's a no, then?
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: 228
|
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 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
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 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
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: 73
|
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.  |
| |
[ Log in to reply ] |
| |
|
