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
- WROCC Newsletter Volume 41:11 reviewed (News:)
- WROCC March 2024 meeting o... Hughes and Peter Richmond (News:1)
- Rougol March 2024 meeting on monday with Bernard Boase (News:)
- Drag'n'Drop 13i2 edition reviewed (News:)
- South-West Show 2024 talks (News:4)
- February 2024 News Summary (News:1)
- Next developer fireside chat (News:)
- DDE31d released (News:)
- South-West Show 2024 Report (News:)
- South-West Show 2024 in pictures (News:)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: The Playpen: No games for Iyonix
 
  No games for Iyonix
  This is a long thread. Click here to view the threaded list.
 
Tony Haines Message #28196, posted by Loris at 16:54, 11/1/2003
madbanHa ha, me mine, mwahahahaha
Posts: 1025
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]
  ^[ Log in to reply ]
 
Phil Mellor Message #28199, posted by monkeyson2 at 17:40, 11/1/2003, in reply to message #28196
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
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 wonder what the Omega will support...
  ^[ Log in to reply ]
 
Tony Haines Message #28329, posted by Loris at 17:09, 14/1/2003, in reply to message #28199
madbanHa ha, me mine, mwahahahaha
Posts: 1025
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 was thinking about this some more.
Perhaps it would be possible to have a fixer which would emulate the proper behaviour.

You'd have to claim the SWI vector, and do some other funky sh*t.

So for example to fix the backscreen problem:

Claim memory to the screensize in an appropriate area.
Supply information on this area when SYS calls request it - eg size of it, the screen memory start and so on.
On V-sync - transfer the contents of the 'current' drawscreen to the graphics card memory. (I don't even know how this is done.)
This would have to be *after* any game-specific v-sync calls.

I dunno how much of a load this would be, but if the processor and memory access are much faster, then previously existing games might still run full-speed.

[Edited by Loris at 17:10, 14/1/2003]
  ^[ Log in to reply ]
 
Simon Wilson Message #28463, posted by ksattic at 19:44, 15/1/2003, in reply to message #28196
ksattic
Finally, an avatar!

Posts: 1291
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)
  ^[ Log in to reply ]
 
James Shaw Message #28480, posted by Hertzsprung at 10:52, 16/1/2003, in reply to message #28463
Hertzsprung
Ghost-like

Posts: 1746
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)
Show off :P
  ^[ Log in to reply ]
 
GuestX Message #28493, posted by guestx at 14:49, 16/1/2003, in reply to message #28196
Member
Posts: 102
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 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.

I suppose it'll get implemented at some point. It's time for some people to get more excited by the ViewFinder update which provided exactly the capability you're missing. ;-)
  ^[ Log in to reply ]
 
Andrew Message #28494, posted by andrew at 14:51, 16/1/2003, in reply to message #28196
HandbagHandbag Boi
Posts: 3439
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]
As I suspected it's smug claptrap. Bank switching works on the Iyonix whether by the same mechanism or not as on RPCs.
  ^[ Log in to reply ]
 
Tony Haines Message #28505, posted by Loris at 18:14, 16/1/2003, in reply to message #28493
madbanHa ha, me mine, mwahahahaha
Posts: 1025
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.
Well other people have said bank switching will work and this is good news.
BTW I'm not sure what you're trying to say about RISC OS bank switching.
I myself change the visible screen-bank with OS_Byte,113 but write to screenmemstart+n*screensize+[screenpos]
(ie don't change write screen-bank)

Anyone have any idea whether this will work?
  ^[ Log in to reply ]
 
Tony Haines Message #28506, posted by Loris at 18:16, 16/1/2003, in reply to message #28494
madbanHa ha, me mine, mwahahahaha
Posts: 1025
As I suspected it's smug claptrap. Bank switching works on the Iyonix whether by the same mechanism or not as on RPCs.
Andrew, are you calling me or Mike Cook Smug?
And why? I don't think either is justified.
Mike Cook was at worst mistaken, I was horrified.
  ^[ Log in to reply ]
 
Andrew Message #28510, posted by andrew at 20:08, 16/1/2003, in reply to message #28506
HandbagHandbag Boi
Posts: 3439
No I'm saying I've seen it a couple of times stated as fact with no qualifying remarks to the sentence.
It's something that I've seen frequently in the IRSC OS community and I might add from those who should know better and have the most influence -they state something rashly like 'it can't be done' or 'you don't need that' and often they're wrong.
Too sure - smacks of smugness rather than naievety.
  ^[ Log in to reply ]
 
Simon Wilson Message #28514, posted by ksattic at 20:50, 16/1/2003, in reply to message #28505
ksattic
Finally, an avatar!

Posts: 1291
I myself change the visible screen-bank with OS_Byte,113 but write to screenmemstart+n*screensize+[screenpos]
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!)
  ^[ Log in to reply ]
 
John Hoare Message #28525, posted by moss at 09:35, 17/1/2003, in reply to message #28514

Posts: 9348
*slaps ksattic about a bit for owning an Iyonix when I don't* :P
  ^[ Log in to reply ]
 
Simon Wilson Message #28555, posted by ksattic at 14:58, 17/1/2003, in reply to message #28525
ksattic
Finally, an avatar!

Posts: 1291
*slaps ksattic about a bit for owning an Iyonix when I don't* :P
:o
  ^[ Log in to reply ]
 
Phil Mellor Message #28556, posted by monkeyson2 at 15:22, 17/1/2003, in reply to message #28555
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
I could have been owning an Iyonix if I hadn't tried to own an Omega. :| :| :|
  ^[ Log in to reply ]
 
Tony Haines Message #28559, posted by Loris at 16:04, 17/1/2003, in reply to message #28514
madbanHa ha, me mine, mwahahahaha
Posts: 1025
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!)
Thanks Simon,
I'll see if I can write an example program tonight.
  ^[ Log in to reply ]
 
Tony Haines Message #28633, posted by Loris at 13:03, 19/1/2003, in reply to message #28514
madbanHa ha, me mine, mwahahahaha
Posts: 1025
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!)
Here is a BASIC screenbank test program.
It should (and does on my RPC) display a white dot approximately in the middle of the black screen.
Pressing a button will switch screen modes and draw the dot in a slightly different position.
Holding eg. the space-bar down should make the dot 'jiggle' between the 2 positions.

Hold down shift and press another button to quit.


ON ERROR MODE13:REPORT:P." at line ";ERL:END
MODE 15
MODE 13
SYS"OS_ReadDynamicArea",2 TO scrmem%
scrmem%+=320*128+160
bank%=2
scrsize%=320*256
REPEAT
SYS"OS_Byte",113,bank%
scrpos%=scrmem%+scrsize%*(bank%-1)
scrpos%?(bank%*2)=255
A=GET
bank%=3-bank%
UNTIL INKEY(-1)


Explanation of code:
The extra mode call at the start just claims enough screen memory for a shadow-bank. I don't normally do this (its a bit hacky), but it is simplest and shortest method in basic. This might not work on Iyonix - if not just ensure that there is at least 160k in the screen memory using the task display before running the program.

The SYS"OS_ReadDynamicArea" call reads the start of screen memory.
The next line just gives the address of the screen center rather than the top-left.

The loop toggles between screenbanks 1 and 2, and draws a white pixel (colour 255) to a position slightly modified by the screen bank (so you should see it move).
The line defining scrpos% is calculating the base address to draw to. It adds on either 0 or 1 times the memory size of the screen to the pointer.

I hope this works because if not I'm not sure how any other form of direct screen access will.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #28666, posted by Phlamethrower at 23:24, 19/1/2003, in reply to message #28633
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
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 :P
  ^[ Log in to reply ]
 
Andrew Message #28689, posted by andrew at 10:05, 20/1/2003, in reply to message #28666
HandbagHandbag Boi
Posts: 3439
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 :P
If it works I couldn't give a flying turkey.
  ^[ Log in to reply ]
 
Tony Haines Message #28697, posted by Loris at 10:29, 20/1/2003, in reply to message #28666
madbanHa ha, me mine, mwahahahaha
Posts: 1025
IMO using screenmode+screensize to access the other bank is bad code. Use OS_ReadVduVariables like a good programmer does, fool!
I wasn't aware readvduvars would let you read the start of the shadowscreen(s). You learn something new every day.

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.
Gah. I did point out that it was bad practice at least. I'd forgotten about the +128 business, but the problem with that is that you can only get enough for 1 more screen. (And this method seemed incredibly hacky for Acorn even at the time.) I usually write in ARM code now, and change screensize with ... changedynamicarea,2 IIRC.
  ^[ Log in to reply ]
 
John Hoare Message #28701, posted by moss at 10:37, 20/1/2003, in reply to message #28697

Posts: 9348
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]
  ^[ Log in to reply ]
 
Andrew Message #28712, posted by andrew at 10:46, 20/1/2003, in reply to message #28701
HandbagHandbag Boi
Posts: 3439
:laugh:
  ^[ Log in to reply ]
 
Tony Haines Message #28975, posted by Loris at 18:24, 20/1/2003, in reply to message #28701
madbanHa ha, me mine, mwahahahaha
Posts: 1025
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]
You edited it and left it looking like *that*?

Oh ooh, mode 15

ah ah ahh mode 13

yes! yes! yes!
  ^[ Log in to reply ]
 
John Hoare Message #28977, posted by moss at 18:30, 20/1/2003, in reply to message #28975

Posts: 9348
I decided to add in the filth :P
  ^[ Log in to reply ]
 
Tony Haines Message #29004, posted by Loris at 19:15, 20/1/2003, in reply to message #28633
madbanHa ha, me mine, mwahahahaha
Posts: 1025
Hey, my code's got smilies in it even though I unticked the smilies box. Has it always had them? Looked alright in preview..
  ^[ Log in to reply ]
 
John Hoare Message #29006, posted by moss at 19:17, 20/1/2003, in reply to message #29004

Posts: 9348
Hey, my code's got smilies in it even though I unticked the smilies box. Has it always had them? Looked alright in preview..
Remember, when you preview it turns the Smiley box back on - you have to uncheck it again :(
  ^[ Log in to reply ]
 
Simon Wilson Message #29040, posted by ksattic at 22:07, 20/1/2003, in reply to message #29006
ksattic
Finally, an avatar!

Posts: 1291
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?

I'll see if I can try the code on a RiscPC.
  ^[ Log in to reply ]
 
Simon Wilson Message #29041, posted by ksattic at 22:10, 20/1/2003, in reply to message #29040
ksattic
Finally, an avatar!

Posts: 1291
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.
  ^[ Log in to reply ]
 
Tony Haines Message #29140, posted by Loris at 11:45, 21/1/2003, in reply to message #29040
madbanHa ha, me mine, mwahahahaha
Posts: 1025
Does the code actually work on a RiscPC? I get nowt but a flickering cursor on the Iyonix.
As I said, I've tested it and it works on my SA-RPC.

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?
It shouldn't matter what the actual screen memory address is. Having this value possibly is something to do with the graphics card, but it isn't that unusual to have specific areas of memory starting at large boundaries. That said perhaps this is a slightly odd one - 1280 + 28 Mb.

I'd expect to be able to read and write to screen memory directly, because otherwise few things doing anything slightly graphically complex will work.


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.
It is possible I suppose that screen memory is protected while in Basic..

Or maybe as Jeffrey pointed out I might not be writing to the screen, if the memory is organised differently.

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.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #29157, posted by Phlamethrower at 12:19, 21/1/2003, in reply to message #29140
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
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.
  ^[ Log in to reply ]
 
Tony Haines Message #29225, posted by Loris at 13:48, 21/1/2003, in reply to message #29157
madbanHa ha, me mine, mwahahahaha
Posts: 1025
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.
Except it isn't one, its two (since you must first change the write screenbank, which I don't usually need to do). And it might not matter at the high end, but it is going to be more significant at the low end (possibly RPC-600). So around 150 extra SWIs per second. A quick websearch suggested 25Mhz for this processor so around 25,000,000 cycles per second. How many cycles do these SWI calls take? I dunno, but I wouldn't be surprised if it were 100 or so.
So this might be using, say, 1/2000th of the processor. This might seem like not very much, but it is a bit of a whack for doing what a single (well, 75) load instruction could have done.
  ^[ Log in to reply ]
 
Pages (2): 1 > >|

The Icon Bar: The Playpen: No games for Iyonix