Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #5533 > unrolled thread

Sprite ops Where am I going wrong?

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Sprite ops Where am I going wrong? J Peachey <john@jpeachey.co.uk> - 2018-10-05 21:53 +0100
    Re: Sprite ops Where am I going wrong? Alex Macfarlane Smith <nospam@archifishal.co.uk> - 2018-10-06 10:02 +0100
      Re: Sprite ops Where am I going wrong? J Peachey <john@jpeachey.co.uk> - 2018-10-06 11:33 +0100
    Re: Sprite ops Where am I going wrong? druck <news@druck.org.uk> - 2018-10-06 10:11 +0100
      Re: Sprite ops Where am I going wrong? J Peachey <john@jpeachey.co.uk> - 2018-10-06 11:29 +0100
      Re: Sprite ops Where am I going wrong? Matthew Phillips <spam2011m@yahoo.co.uk> - 2018-10-07 07:37 +0100
        Re: Sprite ops Where am I going wrong? News <chrisjohnson@spamcop.net> - 2018-10-07 10:21 +0100
        Re: Sprite ops Where am I going wrong? druck <news@druck.org.uk> - 2018-10-07 11:41 +0100
          Re: Sprite ops Where am I going wrong? druck <news@druck.org.uk> - 2018-10-08 19:40 +0100
        Re: Sprite ops Where am I going wrong? J Peachey <john@jpeachey.co.uk> - 2018-10-07 18:43 +0100
          Re: Sprite ops Where am I going wrong? Steve Fryatt <news@stevefryatt.org.uk> - 2018-10-07 19:55 +0100
            Re: Sprite ops Where am I going wrong? J Peachey <john@jpeachey.co.uk> - 2018-10-08 12:01 +0100
    Re: Sprite ops Where am I going wrong? news@sprow.co.uk - 2018-10-06 03:25 -0700
      Re: Sprite ops Where am I going wrong? J Peachey <john@jpeachey.co.uk> - 2018-10-06 11:46 +0100

#5533 — Sprite ops Where am I going wrong?

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:john@jpeachey.co.uk
_______________________|   http://www.jpeachey.co.uk

[toc] | [next] | [standalone]

#5534

On 05/10/2018 21:53, J Peachey wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#5538

In message <LYidnZfNv_qP5yXGnZ2dnUU78RHNnZ2d@brightview.co.uk>
          Alex Macfarlane Smith <nospam@archifishal.co.uk> wrote:

> On 05/10/2018 21:53, J Peachey wrote:
>> 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!

> but it doesn't look like it's changed to me.

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



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

[toc] | [prev] | [next] | [standalone]

#5535

On 05/10/2018 21:53, J Peachey wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#5537

In message <pp9u7h$ojn$1@dont-email.me>
          druck <news@druck.org.uk> wrote:

> On 05/10/2018 21:53, J Peachey wrote:
>> 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.
> ---druck


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

[toc] | [prev] | [next] | [standalone]

#5540

In message <pp9u7h$ojn$1@dont-email.me>
 on 6 Oct 2018 druck  wrote:

> On 05/10/2018 21:53, J Peachey wrote:
> > 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

[toc] | [prev] | [next] | [standalone]

#5541

In article <00bc1f4357.Matthew@sinenomine.freeserve.co.uk>,
   Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> In message <pp9u7h$ojn$1@dont-email.me>
>  on 6 Oct 2018 druck  wrote:

> > On 05/10/2018 21:53, J Peachey wrote:
> > > 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!

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

[toc] | [prev] | [next] | [standalone]

#5542

On 07/10/2018 07:37, Matthew Phillips wrote:
> 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.

This call uses the system sprite area, which is normally empty. It is 
not the Wimp ROM sprite area.

---druck

[toc] | [prev] | [next] | [standalone]

#5555

On 07/10/2018 11:41, druck wrote:
> On 07/10/2018 07:37, Matthew Phillips wrote:
>> 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.
> 
> 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

[toc] | [prev] | [next] | [standalone]

#5543

In message <00bc1f4357.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> In message <pp9u7h$ojn$1@dont-email.me>
>  on 6 Oct 2018 druck  wrote:

>> On 05/10/2018 21:53, J Peachey wrote:
>>> 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!

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:john@jpeachey.co.uk
_______________________|   http://www.jpeachey.co.uk

[toc] | [prev] | [next] | [standalone]

#5544

On 7 Oct, J Peachey wrote in message
    <9a9e5c4357.john@user.orpheusmail.co.uk>:
 
> 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.

> 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.

> 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/

[toc] | [prev] | [next] | [standalone]

#5545

In message <mpro.pg8sk804mw28301w6.news@stevefryatt.org.uk>
          Steve Fryatt <news@stevefryatt.org.uk> wrote:

> On 7 Oct, J Peachey wrote in message
>     <9a9e5c4357.john@user.orpheusmail.co.uk>:

>> 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.
>> 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.

>> 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.

I'll investigate and read up about these to get an understanding.
> 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:john@jpeachey.co.uk
_______________________|   http://www.jpeachey.co.uk

[toc] | [prev] | [next] | [standalone]

#5536

On Friday, 5 October 2018 21:51:01 UTC+1, J Peachey  wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#5539

In message <afb092e7-9fa0-4457-8cfa-3a2ff4cead3f@googlegroups.com>
          news@sprow.co.uk wrote:

> On Friday, 5 October 2018 21:51:01 UTC+1, J Peachey  wrote:
>> 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:john@jpeachey.co.uk
_______________________|   http://www.jpeachey.co.uk

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web