Discussion:
Sprite ops Where am I going wrong?
(too old to reply)
J Peachey
2018-10-05 20:53:18 UTC
Permalink
Hi all,

I'm trying to get back into programming, and thought that I would update
one of my simplest applications, which simply retrieves the rom and ram
sprites as it does not work on Titanium.

The program is in Basic

I had thought that it was because I was using SYS"Wimp_BaseOfSprites",
which I know has been deprecated - however at some point I have actually
recoded and it no longer uses this call.

The code that was working on my Iyonix was fairly basic.

SYS"Wimp_SpriteOp",12,,f$ for rom sprites and
SYS"OS_SpriteOp",&112,R1%,f$

Where in both cases f$ is the output path. What has changed that the above
code no longer works on modern systems, going through PRM -2005 I'm
obviously missing something.

Is there a later version of the PRM than the 2005 copy that I have?

Any pointers to what I'm doing wrong would be appreciated.

John
--
_________________________________________
|
| mailto:***@jpeachey.co.uk
_______________________| http://www.jpeachey.co.uk
Alex Macfarlane Smith
2018-10-06 09:02:08 UTC
Permalink
Post by J Peachey
Hi all,
I'm trying to get back into programming, and thought that I would update
one of my simplest applications, which simply retrieves the rom and ram
sprites as it does not work on Titanium.
The program is in Basic
I had thought that it was because I was using SYS"Wimp_BaseOfSprites",
which I know has been deprecated - however at some point I have actually
recoded and it no longer uses this call.
The code that was working on my Iyonix was fairly basic.
SYS"Wimp_SpriteOp",12,,f$ for rom sprites and
SYS"OS_SpriteOp",&112,R1%,f$
Where in both cases f$ is the output path. What has changed that the above
code no longer works on modern systems, going through PRM -2005 I'm
obviously missing something.
Is there a later version of the PRM than the 2005 copy that I have?
http://foundation.riscos.com/support/developers/prm/sprites.html#79910 or
https://www.riscosopen.org/wiki/documentation/show/OS_SpriteOp%2012

but it doesn't look like it's changed to me.
Post by J Peachey
Any pointers to what I'm doing wrong would be appreciated.
John
J Peachey
2018-10-06 10:33:35 UTC
Permalink
Post by Alex Macfarlane Smith
Post by J Peachey
Hi all,
I'm trying to get back into programming, and thought that I would update
one of my simplest applications, which simply retrieves the rom and ram
sprites as it does not work on Titanium.
The program is in Basic
I had thought that it was because I was using SYS"Wimp_BaseOfSprites",
which I know has been deprecated - however at some point I have actually
recoded and it no longer uses this call.
The code that was working on my Iyonix was fairly basic.
SYS"Wimp_SpriteOp",12,,f$ for rom sprites and
SYS"OS_SpriteOp",&112,R1%,f$
Where in both cases f$ is the output path. What has changed that the above
code no longer works on modern systems, going through PRM -2005 I'm
obviously missing something.
Is there a later version of the PRM than the 2005 copy that I have?
http://foundation.riscos.com/support/developers/prm/sprites.html#79910 or
https://www.riscosopen.org/wiki/documentation/show/OS_SpriteOp%2012
Thanks for those links, I agree it doesn't look to have changed- so i
think its down to some faulty programming!
Post by Alex Macfarlane Smith
but it doesn't look like it's changed to me.
Post by J Peachey
Any pointers to what I'm doing wrong would be appreciated.
John
--
_________________________________________
| University of Glos. Blighting Longlevens.
| mailto:***@jpeachey.co.uk
_______________________| http://www.jpeachey.co.uk
druck
2018-10-06 09:11:04 UTC
Permalink
Post by J Peachey
The code that was working on my Iyonix was fairly basic.
SYS"Wimp_SpriteOp",12,,f$ for rom sprites and
SYS"OS_SpriteOp",&112,R1%,f$
Where in both cases f$ is the output path. What has changed that the above
code no longer works on modern systems,
How does it "no longer works"? Error message?

---druck
J Peachey
2018-10-06 10:29:26 UTC
Permalink
Post by druck
Post by J Peachey
The code that was working on my Iyonix was fairly basic.
SYS"Wimp_SpriteOp",12,,f$ for rom sprites and
SYS"OS_SpriteOp",&112,R1%,f$
Where in both cases f$ is the output path. What has changed that the above
code no longer works on modern systems,
How does it "no longer works"? Error message?
Sorry that would have been useful.

The person who reported the problem gets an invalid Object Id ()x7c129180)
(ox4277c180) (0x2) code 0

This error I can't replicate - but think this is due to the fact that the
two sprite save commands fail. Instead I get am error Sprite doesn't exist
(rom), or no system memory reserved for the system sprite area(ram).
Depending on whether the app tries to save either rom or ram sprites.

The program works if I use the SYS"Wimp_BaseOfSprites", which obviously
returns the addresses of the wimp pool- but which I was trying to get away
from.

It would seem that I would need to find the addresses of the sprite pools
and then use OS_SpriteOp,&112 etc

Thanks for the help so far.
Post by druck
---druck
--
_________________________________________
| University of Glos. Blighting Longlevens.
| mailto:***@jpeachey.co.uk
_______________________| http://www.jpeachey.co.uk
Matthew Phillips
2018-10-07 06:37:59 UTC
Permalink
Post by druck
Post by J Peachey
The code that was working on my Iyonix was fairly basic.
SYS"Wimp_SpriteOp",12,,f$ for rom sprites and
SYS"OS_SpriteOp",&112,R1%,f$
Where in both cases f$ is the output path. What has changed that the above
code no longer works on modern systems,
How does it "no longer works"? Error message?
It would be good to see what f$ is set up to also.

I've never used this call, so I tried it out quickly on an Iyonix, just using
the following:

SYS"Wimp_SpriteOp",12,,"ADFS::HardDisc4.$.Aaaa"

I get "Sprite doesn't exist". That's on RISC OS 5.16. But the same happens
on our RISC PC, on 4.02.

So if John's code is working on his Iyonix, it must be doing something
different to what I tried. Give us a bit more of the program and we might be
able to help better!
--
Matthew Phillips
Durham
News
2018-10-07 09:21:56 UTC
Permalink
Post by Matthew Phillips
Post by druck
Post by J Peachey
The code that was working on my Iyonix was fairly basic.
SYS"Wimp_SpriteOp",12,,f$ for rom sprites and
SYS"OS_SpriteOp",&112,R1%,f$
Where in both cases f$ is the output path. What has changed that the above
code no longer works on modern systems,
How does it "no longer works"? Error message?
It would be good to see what f$ is set up to also.
I've never used this call, so I tried it out quickly on an Iyonix,
SYS"Wimp_SpriteOp",12,,"ADFS::HardDisc4.$.Aaaa"
I get "Sprite doesn't exist". That's on RISC OS 5.16. But the
same happens on our RISC PC, on 4.02.
So if John's code is working on his Iyonix, it must be doing
something different to what I tried. Give us a bit more of the
program and we might be able to help better!
I get the same on modern hardware (my Iyonix died a while ago now).

I am a little confused. The PRM says that R2 is a ptr to sprite name,
and also says sprites are always accessed by name.

Looking at the analogous OS_SpriteOp 12, it does say R2 is pointer to
pathname, so that should be ok.

I cannot get this call to work on ARMX6 hardware - the "Sprite
doesn't exist" error is raised.
--
Chris Johnson
druck
2018-10-07 10:41:37 UTC
Permalink
Post by Matthew Phillips
I've never used this call, so I tried it out quickly on an Iyonix, just using
SYS"Wimp_SpriteOp",12,,"ADFS::HardDisc4.$.Aaaa"
I get "Sprite doesn't exist". That's on RISC OS 5.16. But the same happens
on our RISC PC, on 4.02.
This call uses the system sprite area, which is normally empty. It is
not the Wimp ROM sprite area.

---druck
druck
2018-10-08 18:40:30 UTC
Permalink
Post by druck
Post by Matthew Phillips
I've never used this call, so I tried it out quickly on an Iyonix, just using
SYS"Wimp_SpriteOp",12,,"ADFS::HardDisc4.$.Aaaa"
I get "Sprite doesn't exist".  That's on RISC OS 5.16.  But the same
happens
on our RISC PC, on 4.02.
This call uses the system sprite area, which is normally empty. It is
not the Wimp ROM sprite area.
Sorry as pointed out, that is wrong, I was thinking of OS_SpriteOp, not
Wimp_SpriteOp - long day.

---druck

J Peachey
2018-10-07 17:43:01 UTC
Permalink
Post by Matthew Phillips
Post by druck
Post by J Peachey
The code that was working on my Iyonix was fairly basic.
SYS"Wimp_SpriteOp",12,,f$ for rom sprites and
SYS"OS_SpriteOp",&112,R1%,f$
Where in both cases f$ is the output path. What has changed that the above
code no longer works on modern systems,
How does it "no longer works"? Error message?
It would be good to see what f$ is set up to also.
I've never used this call, so I tried it out quickly on an Iyonix, just using
SYS"Wimp_SpriteOp",12,,"ADFS::HardDisc4.$.Aaaa"
I get "Sprite doesn't exist". That's on RISC OS 5.16. But the same happens
on our RISC PC, on 4.02.
So if John's code is working on his Iyonix, it must be doing something
different to what I tried. Give us a bit more of the program and we might be
able to help better!
That is basically all the code, the rest is just the Appbasic wrapper -f$
is returned by the saveas function - but the error occurs if I hard write
the path into the code.

I've had a chance to wake up my Iyonix - and the code does not work on
that either.

The code prior to my rewrite is

DEFPROC save_rom(f$)
REM LOCAL R0%,R1%

REM SYS"Wimp_BaseOfSprites" TO R0%,R1%
REM SYS"OS_SpriteOp",&112,R0%,f$
SYS"Wimp_SpriteOp",12,,f$
ENDPROCDEF

PROCsave_ram(f$)
LOCAL R0%,R1%
REM SYS"Wimp_BaseOfSprites" TO R0%,R1%
SYS"OS_SpriteOp",&112,R1%,f$
ENDPROC
The stuff remmed out is the previous working code

I did alter Wimp_spriteOp,12 to &112 or as Sprow suggested &10c but this
simply stuffed my Titanium - I had to power off.

I have been rewriting the above procs without the Wimp frontend to try and
discover what is wrong.

I note Druck has offered that the Wimp_spriteOp is for the system Sprite
area - however the manual states that "performs sprite operations on
sprites from the wimps pool" - which is I think different to the system
sprite area - which you used to use the old * star commands to manipulate.

I'm starting to think that Wimp_spriteOp is perhaps the wrong route, and
that SpriteOp with &112 is the way to go - but how do you find where the
rom and ram sprite pools are?

I thought that this would be a simple way to get back into programming as
the code that does the work is only 2/3 lines long. :0(

Thanks for your help guys

John
--
_________________________________________
| University of Glos. Blighting Longlevens.
| mailto:***@jpeachey.co.uk
_______________________| http://www.jpeachey.co.uk
Steve Fryatt
2018-10-07 18:55:26 UTC
Permalink
On 7 Oct, J Peachey wrote in message
Post by J Peachey
The code prior to my rewrite is
DEFPROC save_rom(f$)
REM LOCAL R0%,R1%
REM SYS"Wimp_BaseOfSprites" TO R0%,R1%
REM SYS"OS_SpriteOp",&112,R0%,f$
SYS"Wimp_SpriteOp",12,,f$ ENDPROC
DEF PROCsave_ram(f$)
LOCAL R0%,R1%
REM SYS"Wimp_BaseOfSprites" TO R0%,R1%
SYS"OS_SpriteOp",&112,R1%,f$
ENDPROC
The stuff remmed out is the previous working code
I did alter Wimp_spriteOp,12 to &112 or as Sprow suggested &10c but this
simply stuffed my Titanium - I had to power off.
Coding by trial and error is never good...

OS_SpriteOp 12 is the call that you need, which is OS_SpriteOp &0C. To
supply a sprite area, you add 256, or &100, giving OS_SpriteOp &10C. If
you're using Wimp_SpriteOp, you pass 12 (or &0C) and let the Wimp add the
&100 and fill in R1 for you.

This means that you need OS_SpriteOp &10C, passing the sprite area address
in R1 and the file name in R2.

&112 is *not* the operation that you require.
Post by J Peachey
I have been rewriting the above procs without the Wimp frontend to try and
discover what is wrong.
I note Druck has offered that the Wimp_spriteOp is for the system Sprite
area - however the manual states that "performs sprite operations on
sprites from the wimps pool" - which is I think different to the system
sprite area - which you used to use the old * star commands to manipulate.
Druck's wrong. The call that he highlighted was Wimp_SpriteOp 12 which, on
paper at least, operates on the Wimp Sprite Pool and *not* the System Sprite
Area. However, as others have said, Wimp_SpriteOp 12 gives the "Sprite
doesn't exist" error on RISC OS 5.24.

Use of the System Sprite Area is, indeed, deprecated.
Post by J Peachey
I'm starting to think that Wimp_spriteOp is perhaps the wrong route, and
that SpriteOp with &112 is the way to go - but how do you find where the
rom and ram sprite pools are?
I was going to say that I couldn't understand why you were trying to leave
Wimp_BaseOfSprites behind, but having done a bit of googling it seems that
it was deprecated when Low and High priority pools came in. It seems that,
if I've understood the ROL and ROOL docs correctly now you should do the
something like following:

1. Try Wimp_ReadSysInfo 19, to see if the system that you're running on
supports Low, High and Priority pools. If it does, use these values.

2. If that fails, try Wimp_ReadSysInfo 16 to see if the system that you're
running on supports Low and High pools. If it does, use these values.

3. If that fails, read the ROM and RAM sprite pools with Wimp_BaseOfSprites
and use those.

I think something like the following code covers the options, although I'd
suggest tidying up the logic a bit.

PRINT "Trying Wimp_ReadSysInfo 19..."

SYS "XWimp_ReadSysInfo", 19 TO priority%, high%, low%; flags%
IF (flags% AND 1) = 1 THEN
PRINT "We don't understand Wimp_ReadSysInfo 19,"
PRINT "so trying Wimp_ReadSysInfo 16..."

SYS "XWimp_ReadSysInfo", 16 TO low%, high%; flags%
IF (flags% AND 1) = 1 THEN
PRINT "We don't understand Read SYS Info 16 either,"
PRINT "so using Wimp_BaseOfSprites..."
low% = 0
high% = 0

SYS "Wimp_BaseOfSprites" TO rom%, ram%
PRINT "ROM=&";~rom%;" and RAM=&";~ram%
ELSE
PRINT "High=&";~high%;" and Low=&";~low%
rom% = 0
ram% = 0
ENDIF

priority% = 0
ELSE
PRINT "Priority=&";~priority%;" High=&";~high%;" and Low=&";~low%
rom% = 0
ram% = 0
ENDIF

IF rom% <> 0 THEN SYS "OS_SpriteOp", &10C, rom%, "ROMSpr"
IF ram% <> 0 THEN SYS "OS_SpriteOp", &10C, ram%, "RAMSpr"
IF low% <> 0 THEN SYS "OS_SpriteOp", &10C, low%, "LowSpr"
IF high% <> 0 THEN SYS "OS_SpriteOp", &10C, high%, "HighSpr"
IF priority% <> 0 THEN SYS "OS_SpriteOp", &10C, priority%, "PrioritySpr"

Can anyone correct or clarify?
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
J Peachey
2018-10-08 11:01:14 UTC
Permalink
Post by Steve Fryatt
On 7 Oct, J Peachey wrote in message
Post by J Peachey
The code prior to my rewrite is
DEFPROC save_rom(f$)
REM LOCAL R0%,R1%
REM SYS"Wimp_BaseOfSprites" TO R0%,R1%
REM SYS"OS_SpriteOp",&112,R0%,f$
SYS"Wimp_SpriteOp",12,,f$ ENDPROC
DEF PROCsave_ram(f$)
LOCAL R0%,R1%
REM SYS"Wimp_BaseOfSprites" TO R0%,R1%
SYS"OS_SpriteOp",&112,R1%,f$
ENDPROC
The stuff remmed out is the previous working code
I did alter Wimp_spriteOp,12 to &112 or as Sprow suggested &10c but this
simply stuffed my Titanium - I had to power off.
Coding by trial and error is never good...
OS_SpriteOp 12 is the call that you need, which is OS_SpriteOp &0C. To
supply a sprite area, you add 256, or &100, giving OS_SpriteOp &10C. If
you're using Wimp_SpriteOp, you pass 12 (or &0C) and let the Wimp add the
&100 and fill in R1 for you.
This means that you need OS_SpriteOp &10C, passing the sprite area address
in R1 and the file name in R2.
&112 is *not* the operation that you require.
Yep - that was a schoolboy error - mixing hex and decimal together, rather
than using two hex values.
Post by Steve Fryatt
Post by J Peachey
I have been rewriting the above procs without the Wimp frontend to try and
discover what is wrong.
I note Druck has offered that the Wimp_spriteOp is for the system Sprite
area - however the manual states that "performs sprite operations on
sprites from the wimps pool" - which is I think different to the system
sprite area - which you used to use the old * star commands to manipulate.
Druck's wrong. The call that he highlighted was Wimp_SpriteOp 12 which, on
paper at least, operates on the Wimp Sprite Pool and *not* the System Sprite
Area. However, as others have said, Wimp_SpriteOp 12 gives the "Sprite
doesn't exist" error on RISC OS 5.24.
Use of the System Sprite Area is, indeed, deprecated.
Post by J Peachey
I'm starting to think that Wimp_spriteOp is perhaps the wrong route, and
that SpriteOp with &112 is the way to go - but how do you find where the
rom and ram sprite pools are?
I was going to say that I couldn't understand why you were trying to leave
Wimp_BaseOfSprites behind, but having done a bit of googling it seems that
it was deprecated when Low and High priority pools came in. It seems that,
if I've understood the ROL and ROOL docs correctly now you should do the
1. Try Wimp_ReadSysInfo 19, to see if the system that you're running on
supports Low, High and Priority pools. If it does, use these values.
I'll investigate and read up about these to get an understanding.
Post by Steve Fryatt
2. If that fails, try Wimp_ReadSysInfo 16 to see if the system that you're
running on supports Low and High pools. If it does, use these values.
3. If that fails, read the ROM and RAM sprite pools with Wimp_BaseOfSprites
and use those.
I think something like the following code covers the options, although I'd
suggest tidying up the logic a bit.
PRINT "Trying Wimp_ReadSysInfo 19..."
SYS "XWimp_ReadSysInfo", 19 TO priority%, high%, low%; flags%
IF (flags% AND 1) = 1 THEN
PRINT "We don't understand Wimp_ReadSysInfo 19,"
PRINT "so trying Wimp_ReadSysInfo 16..."
SYS "XWimp_ReadSysInfo", 16 TO low%, high%; flags%
IF (flags% AND 1) = 1 THEN
PRINT "We don't understand Read SYS Info 16 either,"
PRINT "so using Wimp_BaseOfSprites..."
low% = 0
high% = 0
SYS "Wimp_BaseOfSprites" TO rom%, ram%
PRINT "ROM=&";~rom%;" and RAM=&";~ram%
ELSE
PRINT "High=&";~high%;" and Low=&";~low%
rom% = 0
ram% = 0
ENDIF
priority% = 0
ELSE
PRINT "Priority=&";~priority%;" High=&";~high%;" and Low=&";~low%
rom% = 0
ram% = 0
ENDIF
IF rom% <> 0 THEN SYS "OS_SpriteOp", &10C, rom%, "ROMSpr"
IF ram% <> 0 THEN SYS "OS_SpriteOp", &10C, ram%, "RAMSpr"
IF low% <> 0 THEN SYS "OS_SpriteOp", &10C, low%, "LowSpr"
IF high% <> 0 THEN SYS "OS_SpriteOp", &10C, high%, "HighSpr"
IF priority% <> 0 THEN SYS "OS_SpriteOp", &10C, priority%, "PrioritySpr"
Can anyone correct or clarify?
Thanks for that I will indeed have a play around with the code to see
whether that works.

John
--
_________________________________________
| University of Glos. Blighting Longlevens.
| mailto:***@jpeachey.co.uk
_______________________| http://www.jpeachey.co.uk
n***@sprow.co.uk
2018-10-06 10:25:11 UTC
Permalink
Post by J Peachey
SYS"Wimp_SpriteOp",12,,f$ for rom sprites and
SYS"OS_SpriteOp",&112,R1%,f$
Any pointers to what I'm doing wrong would be appreciated.
&10C surely?
Sprow.
J Peachey
2018-10-06 10:46:08 UTC
Permalink
Post by n***@sprow.co.uk
Post by J Peachey
SYS"Wimp_SpriteOp",12,,f$ for rom sprites and
SYS"OS_SpriteOp",&112,R1%,f$
Any pointers to what I'm doing wrong would be appreciated.
&10C surely?
Sprow.
Yep I can see that -I've mixed Hex &100 and decimal 12 together - however
the calls still error 'sprite doesn't exist, so I am doing something
fundementally wrong at the moment.

John
--
_________________________________________
| University of Glos. Blighting Longlevens.
| mailto:***@jpeachey.co.uk
_______________________| http://www.jpeachey.co.uk
Loading...