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

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

SWI / BASIC command to read number of Pixels in a screen mode

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

Contents

  SWI / BASIC command to read number of Pixels in a screen mode Michael <michaelremerton@gmail.com> - 2011-09-27 14:49 -0700
    Re: SWI / BASIC command to read number of Pixels in a screen mode Alex Macfarlane Smith <nospam@archifishal.co.uk> - 2011-09-27 22:51 +0100
      Re: SWI / BASIC command to read number of Pixels in a screen mode Michael <michaelremerton@gmail.com> - 2011-09-27 15:02 -0700
        Re: SWI / BASIC command to read number of Pixels in a screen mode Michael <michaelremerton@gmail.com> - 2011-09-27 15:18 -0700
          Re: SWI / BASIC command to read number of Pixels in a screen mode Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-09-27 23:36 +0100
        Re: SWI / BASIC command to read number of Pixels in a screen mode Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-09-27 23:34 +0100
          Re: SWI / BASIC command to read number of Pixels in a screen mode Michael <michaelremerton@gmail.com> - 2011-09-27 16:10 -0700
      Re: SWI / BASIC command to read number of Pixels in a screen mode Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-09-27 23:19 +0100
        Re: SWI / BASIC command to read number of Pixels in a screen mode Michael <michaelremerton@gmail.com> - 2011-09-27 16:14 -0700
          Re: SWI / BASIC command to read number of Pixels in a screen mode Steve Drain <steve@kappa.me.uk> - 2011-09-28 11:33 +0100
            Re: SWI / BASIC command to read number of Pixels in a screen mode Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-09-28 17:27 +0200
            Re: SWI / BASIC command to read number of Pixels in a screen mode Michael <michaelremerton@gmail.com> - 2011-09-28 18:57 -0700
          Re: SWI / BASIC command to read number of Pixels in a screen mode Gazza <usenet@garethlock.com> - 2011-10-18 16:12 -0700
            Re: SWI / BASIC command to read number of Pixels in a screen mode "Ste (news)" <steve@revi11.plus.com> - 2011-10-25 14:33 +0100
        Re: SWI / BASIC command to read number of Pixels in a screen mode Martin Wuerthner <spamtrap@mw-software.com> - 2011-09-28 10:47 +0200
          Re: SWI / BASIC command to read number of Pixels in a screen mode Steve Drain <steve@kappa.me.uk> - 2011-09-28 12:02 +0100
            Re: SWI / BASIC command to read number of Pixels in a screen mode Steve Drain <steve@kappa.me.uk> - 2011-09-28 12:09 +0100
              Re: SWI / BASIC command to read number of Pixels in a screen mode "Ste (news)" <steve@revi11.plus.com> - 2011-09-28 15:13 +0100
                Re: SWI / BASIC command to read number of Pixels in a screen mode Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-09-28 17:36 +0200
                  Re: SWI / BASIC command to read number of Pixels in a screen mode Steve Drain <steve@kappa.me.uk> - 2011-09-28 17:32 +0100
          Re: SWI / BASIC command to read number of Pixels in a screen mode Martin <News03@avisoft.f9.co.uk> - 2011-09-28 12:55 +0100
          Re: SWI / BASIC command to read number of Pixels in a screen mode Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-09-28 17:34 +0200
        Re: SWI / BASIC command to read number of Pixels in a screen mode Gazza <usenet@garethlock.com> - 2011-10-18 16:10 -0700
          Re: SWI / BASIC command to read number of Pixels in a screen mode Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-19 06:49 +0200
            Re: SWI / BASIC command to read number of Pixels in a screen mode Steve Drain <steve@kappa.me.uk> - 2011-10-19 10:19 +0100
            Re: SWI / BASIC command to read number of Pixels in a screen mode Erik G <erikg@noname.invalid> - 2011-10-19 15:24 +0200
              Re: SWI / BASIC command to read number of Pixels in a screen mode Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-19 19:47 +0200
                Re: SWI / BASIC command to read number of Pixels in a screen mode druck <news@druck.org.uk> - 2011-10-19 20:36 +0100
                  Re: SWI / BASIC command to read number of Pixels in a screen mode Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-20 17:40 +0200
                    Re: SWI / BASIC command to read number of Pixels in a screen mode druck <news@druck.org.uk> - 2011-10-20 20:13 +0100
    Re: SWI / BASIC command to read number of Pixels in a screen mode Chris Johnson <chrisjohnson+news@spamcop.net> - 2011-09-27 23:21 +0100
    Re: SWI / BASIC command to read number of Pixels in a screen mode Bryan Hogan <spam@nowhere.invalid> - 2011-09-28 01:49 +0100
      Re: SWI / BASIC command to read number of Pixels in a screen mode Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-09-28 18:22 +0200
        Re: SWI / BASIC command to read number of Pixels in a screen mode Michael <michaelremerton@gmail.com> - 2011-09-28 19:12 -0700
          Re: SWI / BASIC command to read number of Pixels in a screen mode "Ste (news)" <steve@revi11.plus.com> - 2011-09-29 12:42 +0100
            Re: SWI / BASIC command to read number of Pixels in a screen mode Steve Drain <steve@kappa.me.uk> - 2011-09-29 16:14 +0100
              Re: SWI / BASIC command to read number of Pixels in a screen mode "Ste (news)" <steve@revi11.plus.com> - 2011-09-30 00:12 +0100
                Re: SWI / BASIC command to read number of Pixels in a screen mode Steve Drain <steve@kappa.me.uk> - 2011-09-30 10:48 +0100

Page 2 of 2 — ← Prev page 1 [2]

#789

On 28 Sep, in article <379db81952.martin@bach.planiverse.com>,
   Martin Wuerthner <spamtrap@mw-software.com> wrote:
> In message <87167f1952.martin@blueyonder.co.uk>
>           Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:

> > DIM b% 19
> > !b%=11:REM XWindLimit
> > b%!4=12:REM YWindLimit
> > b%!8=4:REM XEigFactor
> > b%!12=5:REM YEigFactor
> > b%!16=-1:REM terminator
> > SYS "OS_ReadVduVariables",b%,b%
> > screen_width%=!b%<<b%!8:REM in OS units
> > screen_height%=b%!4<<b%!12

> That code will miss a pixel in either direction. Oddly enough, 
> variables 11 and 12 give the number of pixels *minus 1*.

> So, you need :

> screen_width%=((!b%) + 1)<<b%!8
> screen_height%=((b%!4) + 1)<<b%!12

Yes, that is true, but does it also depend if it is the actual width &
height in OS units that is required, or the maximum co-ordinates of the
screen? I think these start at zero, and the limits are...

    screen_maxx%= (!b%)  <<b%!8
    screen_maxy%= (b%!4) <<b%!12

Martin A

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

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

#795

On 28/09/2011 10:47, Martin Wuerthner wrote:

> That code will miss a pixel in either direction. Oddly enough,
> variables 11 and 12 give the number of pixels *minus 1*.

Because the first location is 0,0 not 1,1.


Best wishes,

Rick.

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

#888

On Sep 27, 11:19 pm, Martin Bazley <martin.baz...@blueyonder.co.uk>
wrote:
> The following bytes were arranged on 27 Sep 2011 by Alex Macfarlane Smith :
>
> > On 27/09/2011 22:49, Michael wrote:
> > > I have been traversing the Strong help OS Manual, looking for a
> > > suitable SWI to return the width of a MODE MODE'd Screen (basically
> > > so I run in the same resolution the Machine is already in).
>
> > I think it might be OS_ReadVduVariables, although I can't remember the
> > number you need for it.
>
> DIM b% 19
> !b%=11:REM XWindLimit
> b%!4=12:REM YWindLimit
> b%!8=4:REM XEigFactor
> b%!12=5:REM YEigFactor
> b%!16=-1:REM terminator
> SYS "OS_ReadVduVariables",b%,b%
> screen_width%=!b%<<b%!8:REM in OS units
> screen_height%=b%!4<<b%!12
>
> Testing performed on above routine: no more than everything else ever
> posted to csap late at night.  Warranty given: none.
>
Can't remember the specifics of the call, but 19 ain't a multiple of
4. At least not when I went to school... First line should read DIM b%
20

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

#890

On 19/10/2011 01:10, Gazza wrote:

[re. DIM b% 19]

> Can't remember the specifics of the call, but 19 ain't a multiple of
> 4. At least not when I went to school... First line should read DIM b%
> 20

This is a "Know Your Language" or "RTFM" question. ;-)

In the PDF version of BBC BASIC user guide [p166] it states quite 
clearly that DIM pointer% 100 will reserve from pointer%+0 to 
pointer%+100, in other words 101 bytes of memory. INDICES COUNT FROM 
ZERO (aka This Isn't VisualBasic [*]).

Thus, DIM b% 19 will dimension ?0...?19 or twenty bytes of memory, as 
desired. ;-)


[ http://foundation.riscos.com/Private/manuals/BASIC/BBCBASIC.pdf ]


Best wishes,

Rick.

* - Not strictly true, it can be configured, but count-from-one is the
     default and inalterable when referring to file offsets, and it is a
     monumental pain in the ass given the Windows API itself, plus C,
     plus just about everything else, uses '0' to mean the start of the
     file. Meh.
     Where VB does win is you can dimension stuff like "-15 To 15". Not
     that I've actually needed to do so, mind you.

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

#892

On 19/10/2011 05:49, Rick Murray wrote:
> On 19/10/2011 01:10, Gazza wrote:
>
> [re. DIM b% 19]
>
>> Can't remember the specifics of the call, but 19 ain't a multiple of
>> 4. At least not when I went to school... First line should read DIM b%
>> 20
>
> This is a "Know Your Language" or "RTFM" question. ;-)

I'll endorse that. ;-)

Re-quote: "Can't remember the specifics of the call"

Please look at the manual. My StrongHelp BASIC manual is quite 
comprehensive and it would be easy to check before posting:

  http://www.kappa.me.uk/basic.htm

> Thus, DIM b% 19 will dimension ?0...?19 or twenty bytes of memory, as
> desired. ;-)

It might also be worth repeating that DIM b% 20 reserves 24 bytes.

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

#893

On 19-10-2011 6:49, Rick Murray wrote:
> This is a "Know Your Language" or "RTFM" question. ;-)
> 
> In the PDF version of BBC BASIC user guide [p166] it states quite
> clearly that DIM pointer% 100 will reserve from pointer%+0 to
> pointer%+100, in other words 101 bytes of memory. INDICES COUNT FROM
> ZERO.
> 
> Thus, DIM b% 19 will dimension ?0...?19 or twenty bytes of memory, as
> desired. ;-)
> 
> 
> [ http://foundation.riscos.com/Private/manuals/BASIC/BBCBASIC.pdf ]

Crikey! Thanks for that. As far as I can remember (all the way to using
BBC BASIC for the first time in 1985) I had always believed DIM p% 100
would reserve 100 bytes. Even going so far as using "DIM p% last%+1" to
force reservation of enough bytes.

This only goes to show: it's never too late to learn ;-P

BTW regular arrays also reserve "+1" items. E.g. "DIM a%(20)" will
create 21 elements, numbered 0 to 20. But I already knew that one :-)

On a practical note, getting this news out there may well cause trouble,
as follows:

Many programmers have, due to this quirk, reserved more memory than they
intended (as Steve D pointed out, DIM b% 20 reserves 24 bytes). It is
quite possible that there is a bug in their program that writes more
bytes then there is room for in the block. Accidentally writing one
extra byte or word can happen quite easily.

The combination of these circumstances had the happy result of working
correctly, effectively masking the bug.

Going back to existing code and tightening the block reservations would
probably be a bad idea. To prevent possible obscure bugs from popping up
the code would have to be carefully examined for correct use of the block.

As for new programs: it is (like it always has been) the responsibility
of the programmer to reserve enough space for memory blocks.

In the end, reserving a bit too much space will almost never cause any
trouble, while reserving too little usually will.

But it is good to know how much memory DIM <var> <expr> actually
reserves :-D

-- 
Erik G.
From address is fake
See http://www.xs4all.nl/~erikgrnh/

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

#894

On 19/10/2011 15:24, Erik G wrote:

> Many programmers have, due to this quirk, reserved more memory than they
> intended

...or needed. I tend to reserve 32/64/128 bytes even if I know I'm only 
going to need 24(etc). Because, you know, you might need more later, and 
I'm a little paranoid given blah%!offset% will happily mess with memory 
regardless of bounds. Plus, while it is nice to challenge yourself to a 
tight code program (like "what can I do with 2K?"), memory is cheap. You 
can afford to waste a few bytes here and there, within reason, of course.

This might stem back to an early Wimp program that just kept on screwing 
up its menus. Hours and hours of debug. No joy. Days of rewriting the 
same damn menu handling code. No joy. So, dragging the machine, I dumped 
the menu block to a dot matrix over and over and over, like fifty odd 
pages of it (and a rather warm ribbon). Turns out a minor dim error in a 
far flung part of the program was screwing with the menu block.
Grrrr!


> Going back to existing code and tightening the block reservations would
> probably be a bad idea. To prevent possible obscure bugs from popping up
> the code would have to be carefully examined for correct use of the block.

Given the small sizes (%20 = 24 bytes, not twenty), I suspect most 
programmers would not consider it time well spent.


> In the end, reserving a bit too much space will almost never cause any
> trouble, while reserving too little usually will.

Story above. ;-)


Just don't, you know, reserve entire words for bitfield elements!


Best wishes,

Rick.

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

#897

On 19/10/2011 18:47, Rick Murray wrote:
  ...or needed. I tend to reserve 32/64/128 bytes even if I know I'm only
> going to need 24(etc). Because, you know, you might need more later, and
> I'm a little paranoid given blah%!offset% will happily mess with memory
> regardless of bounds. Plus, while it is nice to challenge yourself to a
> tight code program (like "what can I do with 2K?"), memory is cheap. You
> can afford to waste a few bytes here and there, within reason, of course.

Please tell me that was an attempt at humour?

---druck

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

#898

On 19/10/2011 21:36, druck wrote:

> Please tell me that was an attempt at humour?

Awww... Too obvious? I'll try harder next time. 8-)


Best wishes,

Rick.

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

#899

On 20/10/2011 16:40, Rick Murray wrote:
> On 19/10/2011 21:36, druck wrote:
>
>> Please tell me that was an attempt at humour?
>
> Awww... Too obvious? I'll try harder next time. 8-)

Just checking, as we've seen all that and worse from BASIC coders in 
this newsgroup over the years!

---druck

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

#777

In article
<11510590.202.1317160195012.JavaMail.geo-discussion-forums@yqnk41>,
   Michael <michaelremerton@gmail.com> wrote:
> I had thought OS_ScreenMode would have done it but nope!

The best call is OS_ReadModeVariable.

On entry R0 = screen mode or -1 for current mode.
         R1 = variable number

Variable number is
  4 - XEigFactor
  5 - YEigFactor
 11 - XWindLimit (number of x pixels - 1)
 12 - YWindLimit (number of y pixels - 1)

You need the eig factors to convert pixels to os units.

-- 
Chris Johnson

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

#784

In message <11510590.202.1317160195012.JavaMail.geo-discussion-forums@ 
yqnk41>
          Michael <michaelremerton@gmail.com> wrote:

> suitable SWI to return the width of a MODE MODE'd Screen

Dragging out some very old code of mine:

SYS "OS_ReadModeVariable",-1,3 TO ,,ncolours%:ncolours%+=1
SYS "OS_ReadModeVariable",-1,4 TO ,,screenXfact%
SYS "OS_ReadModeVariable",-1,5 TO ,,screenYfact%
SYS "OS_ReadModeVariable",-1,11 TO ,,screenXpix%
SYS "OS_ReadModeVariable",-1,12 TO ,,screenYpix%
screenXmax%=screenXpix%<<screenXfact%
screenYmax%=screenYpix%<<screenYfact%

Bryan.
-- 
RISC OS London Show - Saturday 29th October 2011
http://www.riscoslondonshow.co.uk/

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

#797

On 28/09/2011 02:49, Bryan Hogan wrote:

> Dragging out some very old code of mine:
> SYS "OS_ReadModeVariable",-1,3 TO ,,ncolours%:ncolours%+=1
> SYS "OS_ReadModeVariable",-1,4 TO ,,screenXfact%
> SYS "OS_ReadModeVariable",-1,5 TO ,,screenYfact%
> SYS "OS_ReadModeVariable",-1,11 TO ,,screenXpix%
> SYS "OS_ReadModeVariable",-1,12 TO ,,screenYpix%
> screenXmax%=screenXpix%<<screenXfact%
> screenYmax%=screenYpix%<<screenYfact%

Which could perhaps be rewritten as:

DIM blk% 32
blk%!0  = 3  : blk%!4  = 4  : blk%!8  = 5
blk%!12 = 11 : blk%!16 = 12 : blk%!20 = -1
SYS "OS_ReadVduVariables", blk%, blk%
ncolours%    = blk%!0 + 1
screenXfact% = blk%!4
screenYfact% = blk%!8
screenXpix%  = blk%!12
screenYpix%  = blk%!16
screenXmax% = screenXpix% << screenXfact%
screenYmax% = screenYpix% << screenYfact%


We've replaced five OS calls with one. To give you an idea of why this 
is important, I ran your code 20,000 times on RPCemu (RO5) and it took 
519cs. My suggestion, 245cs - *twice* as fast.


And, for what it's worth, editing my suggestion to use SWI number (not 
name) and single letter uppercase variables (X%, Y%, etc) can take this 
down to 115cs - *FIVE* times faster! That said, this stage ought to be 
handled by a BASIC squisher once the program has been tested - for 
debugging code like X%=P%<<E% is a massive PITA. ;-)


Best wishes,

Rick.

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

#800

On Wednesday, September 28, 2011 5:22:54 PM UTC+1, Rick Murray wrote:
> On 28/09/2011 02:49, Bryan Hogan wrote:
> 
> > Dragging out some very old code of mine:
> > SYS "OS_ReadModeVariable",-1,3 TO ,,ncolours%:ncolours%+=1
> > SYS "OS_ReadModeVariable",-1,4 TO ,,screenXfact%
> > SYS "OS_ReadModeVariable",-1,5 TO ,,screenYfact%
> > SYS "OS_ReadModeVariable",-1,11 TO ,,screenXpix%
> > SYS "OS_ReadModeVariable",-1,12 TO ,,screenYpix%
> > screenXmax%=screenXpix%<<screenXfact%
> > screenYmax%=screenYpix%<<screenYfact%
> 
> Which could perhaps be rewritten as:
> 
> DIM blk% 32
> blk%!0  = 3  : blk%!4  = 4  : blk%!8  = 5
> blk%!12 = 11 : blk%!16 = 12 : blk%!20 = -1
> SYS "OS_ReadVduVariables", blk%, blk%
> ncolours%    = blk%!0 + 1
> screenXfact% = blk%!4
> screenYfact% = blk%!8
> screenXpix%  = blk%!12
> screenYpix%  = blk%!16
> screenXmax% = screenXpix% << screenXfact%
> screenYmax% = screenYpix% << screenYfact%
> 
> 
> We've replaced five OS calls with one. To give you an idea of why this 
> is important, I ran your code 20,000 times on RPCemu (RO5) and it took 
> 519cs. My suggestion, 245cs - *twice* as fast.
> 
> 
> And, for what it's worth, editing my suggestion to use SWI number (not 
> name) and single letter uppercase variables (X%, Y%, etc) can take this 
> down to 115cs - *FIVE* times faster! That said, this stage ought to be 
> handled by a BASIC squisher once the program has been tested - for 
> debugging code like X%=P%<<E% is a massive PITA. ;-)


Wow! So many responses! :@) Cheers guys.

In order to save time here, I will respond in one message!

I have used the OS ReadMode (mostly as that was before I saw the Basalt one as I am also using that)

I did try on my Beagle Board XM RISC OS 5.17:

 VDU READ 4 TO xeig%,yeig%; 11 TO xlim%,ylim% 
   width%=xlim%+1<<xeig% 
   height%=ylim%+1<<yeig%

Worked fine here

 width%=VDU11+1<<VDU4 
  height%=VDU12+1<<VDU5 

Didn't..."Missing ( at 0" (My Lines appear to increment on 1 from 0)

Changing to:

 width%=VDU(11)+1<<VDU(4) 
  height%=VDU(12)+1<<VDU(5) 

worked though!


Many thanks again to all who posted, I now have appropriately positioned sprites in accordance with the screen!

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

#804

In article
<18557126.1072.1317262366991.JavaMail.geo-discussion-forums@yqgn17>,
   Michael <michaelremerton@gmail.com> wrote:
> "Missing ( at 0" (My Lines appear to increment on 1 from 0)

This highlights why it's important to make things clear to both the human
reader/developer and to the language itself what you mean with appropriate
braces. Yes, in BASIC this slows the code down fractionally, but I believe
it's worth it:

  width_os% = ((VDU 11) + 1) << VDU 4

Ta,

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

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

#805

On 29/09/2011 12:42, Ste (news) wrote:
> In article
> <18557126.1072.1317262366991.JavaMail.geo-discussion-forums@yqgn17>,
>     Michael<michaelremerton@gmail.com>  wrote:
>> "Missing ( at 0" (My Lines appear to increment on 1 from 0)
>
> This highlights why it's important to make things clear to both the human
> reader/developer and to the language itself what you mean with appropriate
> braces. Yes, in BASIC this slows the code down fractionally, but I believe
> it's worth it:
>
>    width_os% = ((VDU 11) + 1)<<  VDU 4

In this case it is not Michael's fault, but if anything it is mine. He 
uses Basalt, which translates any use of VDU as a function, and the 
syntax then requires parentheses, which were not present. You can still 
use the Basalt syntax with RO5 without Basalt itself, and satisfy your 
clarity criterion:

     width_os% = (VDU(11) + 1)<<  VDU 4

;-)

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

#809

In article <QX%gq.80$fb.22@newsfe27.ams2>,
   Steve Drain <steve@kappa.me.uk> wrote:
> You can still use the Basalt syntax with RO5 without Basalt itself, and
> satisfy your clarity criterion:
>
>      width_os% = (VDU(11) + 1)<<  VDU 4

In that case, would it not be something more like:

  width_os% = (VDU(11) + 1) << VDU(4)

?

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

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

#813

On 30/09/2011 00:12, Ste (news) wrote:
> In article<QX%gq.80$fb.22@newsfe27.ams2>,
>     Steve Drain<steve@kappa.me.uk>  wrote:
>> You can still use the Basalt syntax with RO5 without Basalt itself, and
>> satisfy your clarity criterion:
>>
>>       width_os% = (VDU(11) + 1)<<   VDU 4
>
> In that case, would it not be something more like:
>
>    width_os% = (VDU(11) + 1)<<  VDU(4)
>
> ?

Of course; too quick on the trigger.

Steve

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web