Drawing Arcs  Hewlett Packard
This is a discussion on Drawing Arcs  Hewlett Packard ; Hello all,
I recently became a little obsessed with trying to speed up the
drawing of arcs on the HP 50g because the ARC command is somewhat
slow. I searched previous posts and found the question had been
brought up ...

Drawing Arcs
Hello all,
I recently became a little obsessed with trying to speed up the
drawing of arcs on the HP 50g because the ARC command is somewhat
slow. I searched previous posts and found the question had been
brought up before but I couldn't find any real answers or attempts by
others to tackle the issue. So after searching the internet for ideas
I cobbled together a SysRPL program that is faster than the ARC
command but I still feel it could be optimized, which is why I'm
posting it here to see if anyone might be interested in pointing out
ways to optimize it, both for speed and size.
A few notes:
 the program assumes DEG mode set
 the program uses the midpoint circle algorithm (aka Bresenham's
circle algorithm)
 Inputs (5 reals) are as follows:
 5: X0 **pixel x coordinate for arc centre (ex: 65)
 4: Y0 **pixel y coordinate for arc centre (ex: 40)
 3: B1 **bearing from arc centre to beginning of arc (ex:
45, bearings are clockwise from North)
 2: B2 **bearing from arc centre to end of arc (ex: 90,
bearings are clockwise from North)
 1: y **Radius
 the program is set up for demonstration purpose, therefore the use
of DOCLLCD, PIXON, and WaitForKey
 program size is ~850 bytes as shown
 to draw a full circle at X0=65, Y0=40, B1=0, B2=360, y=30 takes ~2.0
seconds
 to draw same circle with ARC command takes ~4.2 seconds
::
CK5NOLASTWD
DOCLLCD
TURNMENUOFF
%1
OVER
%
%0
DUP
{
LAM X0
LAM Y0
LAM B1
LAM B2
LAM y
LAM d
LAM x
LAM A
}
BIND
BEGIN
LAM d
%0<
ITE
::
LAM d
LAM x
%2
%*
%3
%+
%+
'
LAM d
STO
;
::
LAM d
LAM x
%2
%*
LAM y
%2
%*
%
%5
%+
%+
'
LAM d
STO
LAM y
%1
'
LAM y
STO
;
LAM x
LAM y
%REC>%POL
%360
%MOD
'
LAM A
STO
DROP
% 90.
LAM A
%
DUP
LAM B1
%>=
SWAP
LAM B2
%<=
AND
IT
::
LAM X0
LAM x
%+
LAM Y0
LAM y
%
COERCE2
PIXON
;
LAM A
LAM B1
%>=
LAM A
LAM B2
%<=
AND
IT
::
LAM X0
LAM y
%+
LAM Y0
LAM x
%
COERCE2
PIXON
;
%180
LAM A
%
DUP
LAM B1
%>=
SWAP
LAM B2
%<=
AND
IT
::
LAM X0
LAM y
%+
LAM Y0
LAM x
%+
COERCE2
PIXON
;
% 90.
LAM A
%+
DUP
LAM B1
%>=
SWAP
LAM B2
%<=
AND
IT
::
LAM X0
LAM x
%+
LAM Y0
LAM y
%+
COERCE2
PIXON
;
% 270.
LAM A
%
DUP
LAM B1
%>=
SWAP
LAM B2
%<=
AND
IT
::
LAM X0
LAM x
%
LAM Y0
LAM y
%+
COERCE2
PIXON
;
%180
LAM A
%+
DUP
LAM B1
%>=
SWAP
LAM B2
%<=
AND
IT
::
LAM X0
LAM y
%
LAM Y0
LAM x
%+
COERCE2
PIXON
;
%360
LAM A
%
DUP
LAM B1
%>=
SWAP
LAM B2
%<=
AND
IT
::
LAM X0
LAM y
%
LAM Y0
LAM x
%
COERCE2
PIXON
;
% 270.
LAM A
%+
DUP
LAM B1
%>=
SWAP
LAM B2
%<=
AND
IT
::
LAM X0
LAM x
%
LAM Y0
LAM y
%
COERCE2
PIXON
;
LAM x
%1+
'
LAM x
STO
LAM x
LAM y
%>
UNTIL
SetDAsTemp
WaitForKey
2DROP
ABND
;
@
Any suggestions would be appreciated.
Jacob

Re: Drawing Arcs
Hello,
use NULLLAMs instead of named LAMs. Accessing them is a lot faster as
their position in memory is caluclated wheras named LAMs are searched.
As a matter of fact you can use any fixed address for binding a LAM, I
usually use TRUE for this because it is on an even address (IIRC) but
this should not matter on a 50G where the SATURN is emulated.
To access NULLLAMs above the current temporary enviroment you have to
add one for the protection word.
You can used DEFINE to make your code more readable with NULLLAMs .
Also according to the timings of EMU48 'case' is faster than 'ITE'.
HTH,
Andreas
http://www.software49g.gmxhome.de

Re: Drawing Arcs
Hello,
for REALLY FAST arc and circle drawing routines,
you might want to take a look at Mark Power's web page:
http://www.btinternet.com/~mark.power/hp48.htm
or more exactly :
http://www.btinternet.com/~mark.power/hp48/glib07.zip
The binary was made for the real HP48 series,
but since the sources are included (HP/JAZZ syntax) ,
you will be able to port them to the 50g.
HTH
Raymond
"Jacob Wall" schrieb im Newsbeitrag
news:57ba5eebfd0c46f9b94c9d47dfffea64@w1g2000prk.googlegroups.com...
> Hello all,
>
> I recently became a little obsessed with trying to speed up the
> drawing of arcs on the HP 50g because the ARC command is somewhat
> slow. I searched previous posts and found the question had been
> brought up before but I couldn't find any real answers or attempts by
> others to tackle the issue. So after searching the internet for ideas
> I cobbled together a SysRPL program that is faster than the ARC
> command but I still feel it could be optimized, which is why I'm
> posting it here to see if anyone might be interested in pointing out
> ways to optimize it, both for speed and size.
>
> [..]
> Any suggestions would be appreciated.
>
> Jacob

Re: Drawing Arcs
Andreas, thanks for the NULLLAMs tip, I was not aware of the
advantages of using NULLLAMs, and in fact it makes quite a difference,
the circle that took ~2.0 seconds to draw only takes ~1.26 seconds to
draw after the changes. I did not notice any real gains when
substituting 'case' for 'ITE'
Raymond, I took a look at Mark Power's web page and looked at the
documentation for his graphics library. I only see a Circle command,
no Arc command. Also I unfortunately know nothing of machine code,
but thanks to the comments in the source file I can tell the same
midpoint circle algorithm is used. When I remove the tests from my
program that decide whether or not the pixel is within the arc or not,
the circle that now takes ~1.26 seconds to draw, only takes ~0.6
seconds. I'm sure that would be (much?) faster in machine code, but
it is beyond my knowledge.
So if anyone is interested in creating a machine code version of my
program I'd be quite interested, seeing as how I don't know how to do
it.
Now, for short arcs (<45 degrees of arc) the ARC command is still
faster than my program, however at 180 degrees of arc, ARC takes more
than double the time, and the full circle more than triple the time.
If an arc of any degree could be drawn in under 0.5 seconds at say the
30 pixel radius......
Jacob

Re: Drawing Arcs
Hi,
right, I just saw Mark's Graphics Library doesn't include an ARC function.
However the the CIRCLE command ist very fast, between less
than 100ms (0.1 sec!) for small circles and about 350ms for bigger ones,
like 75 pixel radius (150 pix diameter;)
Please note that these times were measured on a real HP48SX,
with 2 (TWO) MHz CPU clock!
On the doorstop series (49,50) these routines may be even faster.
I didn't dig into the sources so far,
maybe someone with more free time could do that,
to add an ARC like cmd?
BTW:
At least in the real HP48 series calcs the PIXON cmd is the braking part,
even the internal versions of PIXON/PIXOFF/PIXTOG are very slow,
so these were the essentials to be replaced, which was done in Mark's lib.
Raymond
"Jacob Wall" schrieb im Newsbeitrag
news:b0be004b5d434599872b019a20da7c45@w39g2000prb.googlegroups.com...
> Andreas, thanks for the NULLLAMs tip, I was not aware of the
> advantages of using NULLLAMs, and in fact it makes quite a difference,
> the circle that took ~2.0 seconds to draw only takes ~1.26 seconds to
> draw after the changes. I did not notice any real gains when
> substituting 'case' for 'ITE'
>
> Raymond, I took a look at Mark Power's web page and looked at the
> documentation for his graphics library. I only see a Circle command,
> no Arc command. Also I unfortunately know nothing of machine code,
> but thanks to the comments in the source file I can tell the same
> midpoint circle algorithm is used. When I remove the tests from my
> program that decide whether or not the pixel is within the arc or not,
> the circle that now takes ~1.26 seconds to draw, only takes ~0.6
> seconds. I'm sure that would be (much?) faster in machine code, but
> it is beyond my knowledge.
>
> So if anyone is interested in creating a machine code version of my
> program I'd be quite interested, seeing as how I don't know how to do
> it.
>
> Now, for short arcs (<45 degrees of arc) the ARC command is still
> faster than my program, however at 180 degrees of arc, ARC takes more
> than double the time, and the full circle more than triple the time.
> If an arc of any degree could be drawn in under 0.5 seconds at say the
> 30 pixel radius......
>
> Jacob

Re: Drawing Arcs
hello,
why don't you try to do it in ASM? it will be faster... amd nore fun to
code...
cyrille
"Jacob Wall" wrote in message
news:57ba5eebfd0c46f9b94c9d47dfffea64@w1g2000prk.googlegroups.com...
> Hello all,
>
> I recently became a little obsessed with trying to speed up the
> drawing of arcs on the HP 50g because the ARC command is somewhat
> slow. I searched previous posts and found the question had been
> brought up before but I couldn't find any real answers or attempts by
> others to tackle the issue. So after searching the internet for ideas
> I cobbled together a SysRPL program that is faster than the ARC
> command but I still feel it could be optimized, which is why I'm
> posting it here to see if anyone might be interested in pointing out
> ways to optimize it, both for speed and size.
>
> A few notes:=
>  the program assumes DEG mode set
>  the program uses the midpoint circle algorithm (aka Bresenham's
> circle algorithm)
>  Inputs (5 reals) are as follows:
>  5: X0 **pixel x coordinate for arc centre (ex: 65)
>  4: Y0 **pixel y coordinate for arc centre (ex: 40)
>  3: B1 **bearing from arc centre to beginning of arc (ex:
> 45, bearings are clockwise from North)
>  2: B2 **bearing from arc centre to end of arc (ex: 90,
> bearings are clockwise from North)
>  1: y **Radius
>  the program is set up for demonstration purpose, therefore the use
> of DOCLLCD, PIXON, and WaitForKey
>  program size is ~850 bytes as shown
>  to draw a full circle at X0=65, Y0=40, B1=0, B2=360, y=30 takes ~2.0
> seconds
>  to draw same circle with ARC command takes ~4.2 seconds
>
>
> ::
> CK5NOLASTWD
> DOCLLCD
> TURNMENUOFF
> %1
> OVER
> %
> %0
> DUP
> {
> LAM X0
> LAM Y0
> LAM B1
> LAM B2
> LAM y
> LAM d
> LAM x
> LAM A
> }
> BIND
> BEGIN
> LAM d
> %0<
> ITE
> ::
> LAM d
> LAM x
> %2
> %*
> %3
> %+
> %+
> '
> LAM d
> STO
> ;
> ::
> LAM d
> LAM x
> %2
> %*
> LAM y
> %2
> %*
> %
> %5
> %+
> %+
> '
> LAM d
> STO
> LAM y
> %1
> '
> LAM y
> STO
> ;
> LAM x
> LAM y
> %REC>%POL
> %360
> %MOD
> '
> LAM A
> STO
> DROP
> % 90.
> LAM A
> %
> DUP
> LAM B1
> %>=
> SWAP
> LAM B2
> %<=
> AND
> IT
> ::
> LAM X0
> LAM x
> %+
> LAM Y0
> LAM y
> %
> COERCE2
> PIXON
> ;
> LAM A
> LAM B1
> %>=
> LAM A
> LAM B2
> %<=
> AND
> IT
> ::
> LAM X0
> LAM y
> %+
> LAM Y0
> LAM x
> %
> COERCE2
> PIXON
> ;
> %180
> LAM A
> %
> DUP
> LAM B1
> %>=
> SWAP
> LAM B2
> %<=
> AND
> IT
> ::
> LAM X0
> LAM y
> %+
> LAM Y0
> LAM x
> %+
> COERCE2
> PIXON
> ;
> % 90.
> LAM A
> %+
> DUP
> LAM B1
> %>=
> SWAP
> LAM B2
> %<=
> AND
> IT
> ::
> LAM X0
> LAM x
> %+
> LAM Y0
> LAM y
> %+
> COERCE2
> PIXON
> ;
> % 270.
> LAM A
> %
> DUP
> LAM B1
> %>=
> SWAP
> LAM B2
> %<=
> AND
> IT
> ::
> LAM X0
> LAM x
> %
> LAM Y0
> LAM y
> %+
> COERCE2
> PIXON
> ;
> %180
> LAM A
> %+
> DUP
> LAM B1
> %>=
> SWAP
> LAM B2
> %<=
> AND
> IT
> ::
> LAM X0
> LAM y
> %
> LAM Y0
> LAM x
> %+
> COERCE2
> PIXON
> ;
> %360
> LAM A
> %
> DUP
> LAM B1
> %>=
> SWAP
> LAM B2
> %<=
> AND
> IT
> ::
> LAM X0
> LAM y
> %
> LAM Y0
> LAM x
> %
> COERCE2
> PIXON
> ;
> % 270.
> LAM A
> %+
> DUP
> LAM B1
> %>=
> SWAP
> LAM B2
> %<=
> AND
> IT
> ::
> LAM X0
> LAM x
> %
> LAM Y0
> LAM y
> %
> COERCE2
> PIXON
> ;
> LAM x
> %1+
> '
> LAM x
> STO
> LAM x
> LAM y
> %>
> UNTIL
> SetDAsTemp
> WaitForKey
> 2DROP
> ABND
> ;
> @
>
> Any suggestions would be appreciated.
>
> Jacob

Re: Drawing Arcs
Raymond, agreed that the CIRCLE command is extremely fast from Mark's
library, I tried it with Emu48 emulating a 48gx, with "Authentic
Calculator Speed" set (although when comparing side by side with Emu48
emulating the 50g and a real 50g, there are discrepancies, although
not too major) Having said that I am not sure that the PIXON in the
50g is the culprit, I think its the fact that for each loop there are
24 tests (%>=, %<=, AND, each appearing 8 times) to decide whether the
pixel of each octant is within the arc, and furthermore COERCE2 also
appears 8 times each loop, if there was such a thing as negative
BINTS...... I got rid of the %REC>%POL and substituted with %ANGLE
which yielded a slight improvement. (~1.14 seconds for the 30 pixel
radius circle, ~0.86 seconds for half circle, ~0.72 seconds for
quarter) Actually now looking at those numbers, maybe PIXON is a
factor, but regardless, even bare minimum the program takes ~0.57
seconds, with zero degrees of arc.
Cyrille, having just recently got into SysRPL and ASM looking like a
different animal altogether, I think I'll hold off just a little on
trying my hand at it, although I suspect that in order to get the
desired speed, ASM will need to be employed.
Jacob

Re: Drawing Arcs
On Jul 28, 1:02*am, Jacob Wall wrote:
<...>
> Having said that I am not sure that the PIXON in the
> 50g is the culprit, I think its the fact that for each loop there are
<...>
That's easy to test: simply replace PIXON with the proper number of
DROPs and run the same circle with and without PIXON. The difference
is exactly the overhead introduced by PIXON.
Claudio

Re: Drawing Arcs
On Jul 29, 5:12*pm, Claudio Lapilli wrote:
> On Jul 28, 1:02*am, Jacob Wall wrote:
> <...>
>
> > Having said that I am not sure that the PIXON in the
> > 50g is the culprit, I think its the fact that for each loop there are
>
> <...>
>
> That's easy to test: simply replace PIXON with the proper number of
> DROPs and run the same circle with and without PIXON. The difference
> is exactly the overhead introduced by PIXON.
>
> Claudio
Yes so easy in fact, I didn't think of it. After replacing PIXON with
2DROP, the 30 pixel radius circle took ~1.02 seconds, which is ~0.11
seconds faster than my best performance with PIXON, not very
significant. Thanks Claudio, that clears the PIXON question.
Jacob

Re: Drawing Arcs
hello,
most of the time is probably spent in the memory allocation used whenever a
new object is created. If you can simplify your program so that there are
less objects created, it will run faster.
you can also try to make sure that only small integers are used as they do
not need to be created as they are already present in ROM.
cyrille
"Jacob Wall" wrote in message
news:7a89d114f0694732bdb40fce24ee190a@p10g2000prf.googlegroups.com...
On Jul 29, 5:12 pm, Claudio Lapilli wrote:
> On Jul 28, 1:02 am, Jacob Wall wrote:
> <...>
>
> > Having said that I am not sure that the PIXON in the
> > 50g is the culprit, I think its the fact that for each loop there are
>
> <...>
>
> That's easy to test: simply replace PIXON with the proper number of
> DROPs and run the same circle with and without PIXON. The difference
> is exactly the overhead introduced by PIXON.
>
> Claudio
Yes so easy in fact, I didn't think of it. After replacing PIXON with
2DROP, the 30 pixel radius circle took ~1.02 seconds, which is ~0.11
seconds faster than my best performance with PIXON, not very
significant. Thanks Claudio, that clears the PIXON question.
Jacob

Re: Drawing Arcs
I have a few suggestions to optimize your routine:
Do not use angles inside the loop. I think it will be a lot faster if
you determine the start and end pixel count for each octant outside
the loop. By pixel count I mean the number of iterations in the
Bressenham loop, which will be pixels in the X direction for some
octants and in the Y direction for others.
The start and end points will therefore be integers, which will allow
you to completely remove real arithmetic inside the loop. Using only
bints will be a lot faster.
So you run the full octant iteration, and only call PIXON for pixels
between the start and end points for each quadrant, removing from the
loop all real comparisons, the conversion from real to polar and the
MOD operation, these last two being very expensive.
Claudio

Re: Drawing Arcs
Hello,
Thanks to all of you who offered suggestions and insight, I've gained
more knowledge about the workings of these machines as a result.
Claudio, another great tip to calculate pixel ranges for each octant
beforehand. This certainly improves performance, especially when the
octant in question is not part of the desired arc, which tells me that
the addition/subtraction of x & y to center X & Y to determine the
pixel to be turned on is where I can still improve it, which as
Cyrille pointed out would be quicker if integers were used. I'll look
further into this in the days to come and will post the new and
improved version of the program once it's complete if anyone is
interested.
As it stands the 30 pixel radius arc times are:
full circle: ~0.88 seconds
half circle: ~0.61 seconds
quarter circle: ~0.48 seconds
eighth circle: ~0.43 seconds
minimum runtime using 1 degree of arc is ~0.36 seconds
Thanks again,
Jacob

Re: Drawing Arcs
Hello,
Just to follow up, not too long ago I wished for:
"If an arc of any degree could be drawn in under 0.5 seconds at say
the
30 pixel radius...... "
Well that is now a reality. Here are the times with the new and
improved program: (30 pixel radius)
full circle: ~0.38 seconds
half circle: ~0.27 seconds
quarter circle: ~0.22 seconds
eight circle: ~0.21 seconds
minimum runtime using 0 degree of arc is ~0.17 seconds
The only thing now is that the program is 1180 Bytes, or about 330
Bytes bigger than the original program.
Below is the new program source, still the same 5 inputs as before.
::
CK5NOLASTWD
DOCLLCD
TURNMENUOFF
5ROLL
5ROLL
COERCE2
5UNROLL
5UNROLL
DUP
COERCE
%1
3PICK
%
BINT0
DUP
5ROLL
DUP
%*
%2
%/
%SQRT
COERCE
BINT2
{}N
BINT8
NDUPN
DROP
NULLLAM
BINT15
NDUPN
DOBIND
11GETLAM
UNCOERCE
12GETLAM
%POL>%REC
%ABS
SWAP
%ABS
SWAP
COERCE2
12GETLAM
COERCE
11GETLAM
UNCOERCE
13GETLAM
%POL>%REC
%ABS
SWAP
%ABS
SWAP
COERCE2
13GETLAM
COERCE
BINT3
BINT1
DO
BINT9
BINT1
DO
DUP
BINT45
INDEX@
#*
#1+
#<
IT
::
DROP
INDEX@
::
DUP
BINT1
#=case
TrueTrue
DUP
BINT2
#=case
FalseFalse
DUP
BINT3
#=case
TrueFalse
DUP
BINT4
#=case
FALSETRUE
DUP
BINT5
#=case
TrueTrue
DUP
BINT6
#=case
FalseFalse
DUP
BINT7
#=case
TrueFalse
DUP
BINT8
#=case
FALSETRUE
;
ITE
::
4ROLL
DROP
;
::
ROT
DROP
;
ITE
::
SWAP
JINDEX@
INDEX@
GETLAM
PUTLIST
INDEX@
PUTLAM
;
::
SWAP
BINT3
JINDEX@
#
INDEX@
GETLAM
PUTLIST
INDEX@
PUTLAM
;
DUP
BINT14
JINDEX@
#
PUTLAM
ISTOPSTO
;
LOOP
LOOP
13GETLAM
12GETLAM
#>
BINT9
BINT1
DO
DUP
INDEX@
12GETLAM
#>
INDEX@
13GETLAM
#<
ROT
ITE
AND
OR
IT
::
BINT0
INDEX@
PUTLAM
;
LOOP
DROP
BEGIN
::
10GETLAM
%0<
case
::
10GETLAM
9GETLAM
UNCOERCE
%2
%*
%3
%+
%+
10PUTLAM
;
::
10GETLAM
9GETLAM
UNCOERCE
%2
%*
11GETLAM
UNCOERCE
%2
%*
%
%5
%+
%+
10PUTLAM
11GETLAM
#1
11PUTLAM
;
;
1GETLAM
DUPTYPELIST?
ITE
::
INCOMPDROP
DUP
9GETLAM
#>
SWAP
9GETLAM
#=
OR
SWAP
DUP
9GETLAM
#<
SWAP
#0=
OR
AND
IT
::
15GETLAM
9GETLAM
#+
14GETLAM
11GETLAM
#
PIXON
;
;
DROP
2GETLAM
DUPTYPELIST?
ITE
::
INCOMPDROP
DUP
9GETLAM
#>
SWAP
9GETLAM
#=
OR
SWAP
DUP
9GETLAM
#<
SWAP
#0=
OR
AND
IT
::
15GETLAM
11GETLAM
#+
14GETLAM
9GETLAM
#
PIXON
;
;
DROP
3GETLAM
DUPTYPELIST?
ITE
::
INCOMPDROP
DUP
9GETLAM
#>
SWAP
9GETLAM
#=
OR
SWAP
DUP
9GETLAM
#<
SWAP
#0=
OR
AND
IT
::
15GETLAM
11GETLAM
#+
14GETLAM
9GETLAM
#+
PIXON
;
;
DROP
4GETLAM
DUPTYPELIST?
ITE
::
INCOMPDROP
DUP
9GETLAM
#>
SWAP
9GETLAM
#=
OR
SWAP
DUP
9GETLAM
#<
SWAP
#0=
OR
AND
IT
::
15GETLAM
9GETLAM
#+
14GETLAM
11GETLAM
#+
PIXON
;
;
DROP
5GETLAM
DUPTYPELIST?
ITE
::
INCOMPDROP
DUP
9GETLAM
#>
SWAP
9GETLAM
#=
OR
SWAP
DUP
9GETLAM
#<
SWAP
#0=
OR
AND
IT
::
15GETLAM
9GETLAM
#
14GETLAM
11GETLAM
#+
PIXON
;
;
DROP
6GETLAM
DUPTYPELIST?
ITE
::
INCOMPDROP
DUP
9GETLAM
#>
SWAP
9GETLAM
#=
OR
SWAP
DUP
9GETLAM
#<
SWAP
#0=
OR
AND
IT
::
15GETLAM
11GETLAM
#
14GETLAM
9GETLAM
#+
PIXON
;
;
DROP
7GETLAM
DUPTYPELIST?
ITE
::
INCOMPDROP
DUP
9GETLAM
#>
SWAP
9GETLAM
#=
OR
SWAP
DUP
9GETLAM
#<
SWAP
#0=
OR
AND
IT
::
15GETLAM
11GETLAM
#
14GETLAM
9GETLAM
#
PIXON
;
;
DROP
8GETLAM
DUPTYPELIST?
ITE
::
INCOMPDROP
DUP
9GETLAM
#>
SWAP
9GETLAM
#=
OR
SWAP
DUP
9GETLAM
#<
SWAP
#0=
OR
AND
IT
::
15GETLAM
9GETLAM
#
14GETLAM
11GETLAM
#
PIXON
;
;
DROP
9GETLAM
#1+
DUP
9PUTLAM
11GETLAM
#>
UNTIL
ABND
SetDAsTemp
WaitForKey
2DROP
;
@
Jacob

Re: Drawing Arcs
Hello,
now that's an improvement.
However on a real HP48SX your program takes ~2.9 secs for the full circle,
and ~1.9 secs on an HP48GX ;)
Raymond
"Jacob Wall" schrieb im Newsbeitrag
news:809075ce44fa419483f663b2f4deef2b@a8g2000prf.googlegroups.com...
> Hello,
>
> Just to follow up, not too long ago I wished for:
> "If an arc of any degree could be drawn in under 0.5 seconds at say
> the
> 30 pixel radius...... "
>
> Well that is now a reality. Here are the times with the new and
> improved program: (30 pixel radius)
> full circle: ~0.38 seconds
> half circle: ~0.27 seconds
> quarter circle: ~0.22 seconds
> eight circle: ~0.21 seconds
> minimum runtime using 0 degree of arc is ~0.17 seconds
>
> The only thing now is that the program is 1180 Bytes, or about 330
> Bytes bigger than the original program.
>
> Below is the new program source, still the same 5 inputs as before.
>
> [..]
>
> Jacob

Re: Drawing Arcs
On Aug 2, 8:40*pm, Jacob Wall wrote:
> Hello,
>
> Just to follow up, not too long ago I wished for:
> "If an arc of any degree could be drawn in under 0.5 seconds at say
> the
> 30 pixel radius...... "
>
> Well that is now a reality. *Here are the times with the new and
> improved program: (30 pixel radius)
> full circle: ~0.38 seconds
Cool!
Cutting execution time by half always feels good, doesn't it?... :)
I have one more idea, that could make it slower or faster (who knows
until you test it). The overhead of running the Bresenham loop is not
too much, and your program seems to have a lot of overhead by trying
to manage all octants at the same time (using lists, and many case's
and ITE's).
Now here's another way of doing it, which could potentially be faster
due to less object handling:
1) Calculate all initial parameters for the loop just like you are
doing now, but save them on a LAM for later use.
2) Run one Bresenham loop for each octant (reusing the saved
parameters).
The advantage is obvious for arcs that don't involve all octants: you
don't need to run the loop, so it will execute faster in that case.
Another advantage is that for any partial octants, you can stop the
loop as soon as you reach the stopping point.
The worst case would be the full circle, in this case you would be
running 8 independent complete loops. In this case, it may run slower
than your current routine, but not too much I think, since speed loss
may be compensated somewhat because you'll be using less LAM's, no
lists, etc.
And you could leave both algorithms, and choose which one to use at
run time based on the start and end angles, using your current routine
for arcs that involve several octants (you could measure the timings
on both routines to determine what's the best "switching" angle of
aperture).
It all depends if you want to keep breaking records or you are
satisfied with what you got... :)
Regards,
Claudio

Re: Drawing Arcs
Claudio, yeah I'm curious to see what difference it would make to run
one Bresenham loop for each octant, and time permitting I will look
into it.
> It all depends if you want to keep breaking records or you are
> satisfied with what you got... :)
For now I am satisfied, but as Raymond pointed out, the program still
takes a little too long if run on the 48. Appreciate you taking the
time to run the program on the 48 Raymond. That really makes Mark
Power's machine code graphics library that much more impressive. As a
new to SysRPL programmer, I'm just happy that I can draw arcs and
circles now and not have to wait and wonder if my calculator decided
to go on strike :)
Jacob

Re: Drawing Arcs
Jacob, your proposed exercice is very interesting,
Since you took good care and had great results with SysRPL, would you
mind if i try to have a look at ASM side, which i'm currently
learning ?
I only own an HP48SX myself, but it is probably possible to create a
code which would be compatible with both HP48S and your HP50
Regards

Re: Drawing Arcs
Jacob, your proposed exercice is very interesting,
Since you took good care and had great results with SysRPL, would you
mind if i try to have a look at ASM side, which i'm currently
learning ?
I only own an HP48SX myself, but it is probably possible to create a
code which would be compatible with both HP48S and your HP50
Regards

Re: Drawing Arcs
hello,
you can use that for a base.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%
% Circle asm toolbox %
% %
% input: D0: @ grob %
% Aa: Centre x %
% Ba: Centre y %
% Ca: Rayon %
% the circle must be in the 2047, 2047 square %
% Grob can not be bigger than 2048 pixels %
% %
% 5 different calls: %
% aCircleW Draw a White line %
% aCircleG1 Draw a light gray line %
% aCircleG2 Draw a dark gray line %
% aCircleB Draw a Black line %
% aCircleXor Invert a line %
% %
% Uses: Carry, P, RSTK2 %
% D0 (Last pix Plane1) %
% D1 (Last pix plane2) %
% R3a: +/ Line Width %
% R4a: Plane length %
% Cs: Pixel Mask %
% As: Undefine %
% Bs: Undefine %
% IRAMBUFF (50 nibbles) %
% %
% All functions work either in W&B or gray scale %
% All functions are using standard bresenham algo %
% D0, D1 are pointing on the 2 bit plans. %
% During the process, %
% Am: 4*X Error %
% Bm: 4*Y Error %
% Cm: Error %
% Dm: 2* Radius %
% Ax: XCurrent %
% Bx: XMax (Grob Width) %
% Cx: YCurrent %
% Dx: YMax (Grob Height) %
% D0: Pointer on bit plan 1 %
% D1: Pointer on bit plan 2 %
% Cs: Pixel mask %
% R3a: Line Width or  Line Width %
% R4a: Plan length %
% IRAMBUFF: Pixon routine %
% %
% The Bresenham algo is use to draw the circle. %
% The original Bresenham use to compute the circle %
% Only on 1/8 of the circle and draw the other part%
% using symetrie. Doing a full pixon is quite slow %
% with a saturn, so, we are using 8 times %
% bresenham to draw suxcecivly the 8 octants of %
% the circle. Am, Bm and Cm are use to store the %
% values needed by bresenam, Ax, Bx, Cx and Dx are %
% used to store the current pixel coordinates %
% and the grob dimention to perform the cliping. %
% D0, D1 and Cs are use to point on the current %
% pixel. %
% %
% The algo we are using is: %
% X=2*Rayon1 %
% Y=1 %
% cx=cx+rayon %
% cy=cy %
% Error = 0 %
% pixon(Cx, Cy) %
% while Y
% Begin %
% Error=Error+Y %
% Y=Y+2 %
% cy=cy+1 %
% If error>=X then %
% Begin %
% error= errorX %
% X=X2 %
% cx=cx1 %
% End %
% pixon(Cx, Cy) %
% End; %
% while X<>0 do %
% Begin %
% Error=ErrorX %
% X=X2 %
% cx=cx1 %
% If error<0 then %
% Begin %
% error= error+Y %
% Y=Y+2 %
% cy=cy+1 %
% End %
% pixon(Cx, Cy) %
% End; %
% %
% The same routine is used all the time, but %
% a different Pixon routine is copied in IRAMBUFF %
% for each type of line, and this routine is used %
% to affect the pixels. the _Prepx routine are used%
% to copy the pixon routine in RAM. Note that to %
% decrease teh amount of used register by this %
% routine, the code is charged in Cm using LC with %
% P=3. in order to have a readable code, the LC %
% mnemonic is not used, bu is replaced by the hex %
% opcode: 3x where x is the number of nibbles to %
% load in C1. at the end of the routine, C[34] are%
% loaded with 00. This means the this part of the %
% Ca register is lost %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%
*aCircleB
GOSUB _PrepB
GOTO _Circle
*aCircleW
GOSUB _PrepW
GOTO _Circle
*aCircleG1
GOSUB _PrepG1
GOTO _Circle
*aCircleG2
GOSUB _PrepG2
GOTO _Circle
*aCircleXor
GOSUB _PrepXor
*_Circle
A+C.A % Compute cx (cx+Rayon)
C=0.M C+C.A CSL.A CSL.A CSL.W D=C.M % Dm=Rayon*2
CSL.M CSL.M C=A.A A=C.W % Am=Rayon*2=X
GOSUBL aGrey?
D010 C=DAT0.A D=C.X % Read Max Y
D0+5 C=DAT0.A BCEX.A RSTK=C % Read Max X, Save cy
D0+5
GOSUBL ComputePixel % Compute pixel mask and D0 and D1
C=RSTK % Restore cy
ASR.M ASR.M % X=Am=Rayon
C=0.M % Y=Cm=0
B=0.M % Er=0
{ ?A>=B.X EXIT ?C>=D.X EXIT GOSBVL =IRAMBUFF } % Pixon ( With cliping )
?A=0.M RTY % Quick exit on Radius=0
A1.M C+1.M % Because the bresenham algo need to add (X1) or
Y+1, we already add the 1 to X and Y
P=14
% Octant 1 From a=0 to  45
{
?A<=C.M EXIT % End of octant? X
B+C.M % er+Y
C+2.M C+1.X % Y+2, cy+1
CR3EX.A % cy+1 part2
AD0EX A+C.A AD0EX
?ST=0.=fGray { AD1EX A+C.A AD1EX }
CR3EX.A
?B= X
{
BA.M % er  X
A2.M A1.X % X2, cx1
CSRB.S ?C#0.S { C+8.S D11 D01 } % cx1 part2
} % Else, error<0
{ ?A>=B.X EXIT ?C>=D.X EXIT GOSBVL =IRAMBUFF } % Pixon ( With cliping )
UP
}
% Octant 2. From a=45 to 90
{
?A#0.P EXIT % End of octan?
BA.M % er  X
A2.M A1.X % X2, cx1
CSRB.S ?C#0.S { C+8.S D11 D01 } % cx1 part2
?B=0.P % if B>0 then do nothing
{ % else,
B+C.M C+2.M C+1.X % er+Y, Y+2, cy+1
CR3EX.A % cy+1 part2
AD0EX A+C.A AD0EX
?ST=0.=fGray { AD1EX A+C.A AD1EX }
CR3EX.A
}
{ ?A>=B.X EXIT ?C>=D.X EXIT GOSBVL =IRAMBUFF } % Pixon ( With cliping )
UP
}
% Octant 3 From a=90 to 135
% Doing the same thing again, but inverting Y and X
C=D.M A=C.M B=0.M C=0.M % ReInitializing values
A1.M C+1.M % Because the bresenham algo need to add (X1) or
Y+1, we already add the 1 to X and Y
{
?A<=C.M EXIT % End of octant? X
B+C.M % er+Y
C+2.M A1.X % Y+2, cx1
CSRB.S ?C#0.S { C+8.S D11 D01 } % cx1 part2
?B= X
{
BA.M % er  X
A2.M C1.X % X2, cy1
CR3EX.A % cy1 part2
AD0EX AC.A AD0EX
?ST=0.=fGray { AD1EX AC.A AD1EX }
CR3EX.A
} % Else, error<0
{ ?A>=B.X EXIT ?C>=D.X EXIT GOSBVL =IRAMBUFF } % Pixon ( With cliping )
UP
}
% Octant 4. From a=135 to 180
{
?A#0.P EXIT % End of octan?
BA.M % er  X
A2.M C1.X % X2, cy1
CR3EX.A % cy1 part2
AD0EX AC.A AD0EX
?ST=0.=fGray { AD1EX AC.A AD1EX }
CR3EX.A
?B=0.P % if B>0 then do nothing
{ % else,
B+C.M C+2.M A1.X % er+Y, Y+2, cx1
CSRB.S ?C#0.S { C+8.S D11 D01 } % cx1 part2
}
{ ?A>=B.X EXIT ?C>=D.X EXIT GOSBVL =IRAMBUFF } % Pixon ( With cliping )
UP
}
% Octant 5 From a=180 to 225
% Doing the same thing again, but inverting Y and X again and differantly
C=D.M A=C.M B=0.M C=0.M % Reinitializing values
A1.M C+1.M % Because the bresenham algo need to add (X1) or
Y+1, we already add the 1 to X and Y
{
?A<=C.M EXIT % End of octant? X
B+C.M % er+Y
C+2.M C1.X % Y+2, cy1
CR3EX.A % cy1 part2
AD0EX AC.A AD0EX
?ST=0.=fGray { AD1EX AC.A AD1EX }
CR3EX.A
?B= X
{
BA.M % er  X
A2.M A+1.X % X2, cx+1
C+C.S SKNC { C+1.S D1+1 D0+1 } % cx+1 part2
} % Else, error<0
{ ?A>=B.X EXIT ?C>=D.X EXIT GOSBVL =IRAMBUFF } % Pixon ( With cliping )
UP
}
% Octant 6. From a=225 to 270
{
?A#0.P EXIT % End of octan?
BA.M % er  X
A2.M A+1.X % X2, cx+1
C+C.S SKNC { C+1.S D1+1 D0+1 } % cx+1 part2
?B=0.P % if B>0 then do nothing
{ % else,
B+C.M C+2.M C1.X % er+Y, Y+2, cy1
CR3EX.A % cy1 part2
AD0EX AC.A AD0EX
?ST=0.=fGray { AD1EX AC.A AD1EX }
CR3EX.A
}
{ ?A>=B.X EXIT ?C>=D.X EXIT GOSBVL =IRAMBUFF } % Pixon ( With cliping )
UP
}
% Octant 7 From a=270 to 315
% Doing the same thing again, but inverting Y and X again and differantly
C=D.M A=C.M B=0.M C=0.M % Reinitializing values
A1.M C+1.M % Because the bresenham algo need to add (X1) or
Y+1, we already add the 1 to X and Y
{
?A<=C.M EXIT % End of octant? X
B+C.M % er+Y
C+2.M A+1.X % Y+2, cx+1
C+C.S SKNC { C+1.S D1+1 D0+1 } % cx+1 part2
?B= X
{
BA.M % er  X
A2.M C+1.X % X2, cy+1
CR3EX.A % cy+1 part2
AD0EX A+C.A AD0EX
?ST=0.=fGray { AD1EX A+C.A AD1EX }
CR3EX.A
} % Else, error<0
{ ?A>=B.X EXIT ?C>=D.X EXIT GOSBVL =IRAMBUFF } % Pixon ( With cliping )
UP
}
% Octant 8. From a=315 to 360
{
BA.M % er  X
A2.M C+1.X % X2, cy+1
CR3EX.A % cy+1 part2
AD0EX A+C.A AD0EX
?ST=0.=fGray { AD1EX A+C.A AD1EX }
CR3EX.A
?B=0.P % if B>0 then do nothing
{ % else,
B+C.M C+2.M A+1.X % er+Y, Y+2, cx+1
C+C.S SKNC { C+1.S D1+1 D0+1 } % cx+1 part2
}
?A#0.P EXIT % End of octan?
{ ?A>=B.X EXIT ?C>=D.X EXIT GOSBVL =IRAMBUFF } % Pixon ( With cliping )
UP
}
P=0 RTN
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Return informations on a graphic object %
% %
% Input: D0: @ grob %
% P=0, HEX %
% Output: ST=0/1 fGray %
% 0: Grob W&B %
% 1: Grob Gray %
% R4a: Plane Length in nibbles %
% R3a: Line Width %
% D0: @ first pixel of the screen %
% %
% uses: RSTK1, Ca, Carry, mp %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
*aGrey?
R3=A.A A=B.A R4=A.A % Save Aa in R3 and Ba in R4
D0+15 C=DAT0.A C+7.A CSRB.A CSRB.A CBIT=0.0 % Compute line width
D05 A=DAT0.A % read Grob height
B=0.A A+A.A % Some special multiplication
?CBIT=0.1 { B+A.A } A+A.A % I know that
?CBIT=0.2 { B+A.A } A+A.A % 1: C is between 0 and
2048/2=1024
?CBIT=0.3 { B+A.A } A+A.A % 2: C is even
?CBIT=0.4 { B+A.A } A+A.A % So I explode the loop,
?CBIT=0.5 { B+A.A } A+A.A % testing only bit 1 to 9
?CBIT=0.6 { B+A.A } A+A.A % of C
?CBIT=0.7 { B+A.A } A+A.A % an other great thing is
?CBIT=0.8 { B+A.A } A+A.A % that C is not change during
this
?CBIT=0.9 { B+A.A } A+A.A % multiplication
?CBIT=0.10 { B+A.A } A+A.A
?CBIT=0.11 { B+A.A } A+A.A
?CBIT=0.12 { B+A.A } A+A.A
?CBIT=0.13 { B+A.A } A+A.A
?CBIT=0.14 { B+A.A } A+A.A
?CBIT=0.15 { B+A.A }
D05 A=DAT0.A A15.A D0+15 % read grob size (only bitplans)
D0 point on the first pixel
ST=0.=fGray ?A=B.A { ST=1.=fGray } % if plane length = grob plane
size, we are in W&B
A=B.A AR4EX.A B=A.A % Save Bitplane size, restore B
CR3EX.A A=C.A % Save Line Width, restore Aa
RTN
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%
% Compute Address of first pixel to draw %
% Input: R3a: Line Width ( Even, < 512 ) %
% R4a: Plane Width %
% St=x fGray %
% Aa: X %
% Ca: Y %
% D0: @ First pixel %
% P=0, HEX %
% %
% return: D0: @ Pixel, D1: @ Pixel plan 2 %
% Cs: Pixel Mask %
% P=0, HEX %
% %
% Uses: Cw, D0, D1, Carry, P, RSTK1 %
% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%
*ComputePixel
AD0EX ABEX.A % We must now compute the position of the first
pixel
AR3EX.A C+C.A % D0=Aa Ba=D0 Aa=Ba
?ABIT=0.1 { B+C.A } C+C.A % We Want: D0=@Pix+Y*Width+X/4, D1=D0+PlanSize if
fGray
?ABIT=0.2 { B+C.A } C+C.A % Step 1: Compute B=B+Y*Width ( Width even <=
512 )
?ABIT=0.3 { B+C.A } C+C.A
?ABIT=0.4 { B+C.A } C+C.A
?ABIT=0.5 { B+C.A } C+C.A
?ABIT=0.6 { B+C.A } C+C.A
?ABIT=0.7 { B+C.A } C+C.A
?ABIT=0.8 { B+C.A } C+C.A
?ABIT=0.9 { B+C.A }
AR3EX.A % restore Aa=Ba
CD0EX D0=C % Ca=X
P=C.0 CSRB.A CSRB.A B+C.A % Compute pixel address
C=R4.A C+B.A ?ST=1.=fGray { C=B.A } D1=C % Point on pixel on plan 2 if grey
else, stay on same plan
ABEX.A AD0EX % Restore Ba=Ba, Aa=Aa, D0 point on pixel on plan
1
LC 1248124812481248 P=0 % Compute pixel mask
RTN
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%
% For many of the graphical primitives, %
% The same routine is used all the time, but %
% a different Pixon routine is copied in IRAMBUFF %
% The _Prepx routine are used %
% to copy the pixon routine in RAM. Note that to %
% decrease teh amount of used register by this %
% routine, the code is charged in Cms using LC with%
% P=3. in order to have a readable code, the LC %
% mnemonic is not used, but is replaced by the hex %
% opcode: 3x where x is the number of nibbles to %
% load in C1. at the end of the routine, C[34] is %
% loaded with 00. This means that this part of the %
% Ca register is lost %
% All prep routines use Cms, D1 and carry. %
% at the end of the routine, Ca=Ca&00fff %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%
*_PrepB
D1=(5)=IRAMBUFF P=3
$3B A=DAT0.S A!C.S DAT0=A.S DAT1=C.M D1+12
$38 ?ST=0.=fGray RTY A=DAT1.S DAT1=C.M D1+9
$39 A!C.S DAT1=A.S RTN DAT1=C.M
LC 00 P=0 RTN
*_PrepW
D1=(5)=IRAMBUFF P=3
$3A A=DAT0.S A!C.S AC.S DAT1=C.M D1+11
$38 DAT0=A.S ?ST=0.=fGray RTY DAT1=C.M D1+9
$3A A=DAT1.S A!C.S AC.S DAT1=C.M D1+11
$35 DAT1=A.S RTN DAT1=C.M
LC 00 P=0 RTN
*_PrepG1
D1=(5)=IRAMBUFF P=3
$3B A=DAT0.S A!C.S DAT0=A.S DAT1=C.M D1+12
$38 ?ST=0.=fGray RTY A=DAT1.S DAT1=C.M D1+9
$3C A!C.S AC.S DAT1=A.S RTN DAT1=C.M D1+12 DAT1=C.S
LC 00 P=0 RTN
*_PrepG2
D1=(5)=IRAMBUFF P=3
$3A A=DAT0.S A!C.S AC.S DAT1=C.M D1+11
$38 DAT0=A.S ?ST=0.=fGray RTY DAT1=C.M D1+9
$3B A=DAT1.S A!C.S DAT1=A.S DAT1=C.M D1+12
$31 RTN DAT1=C.M
LC 00 P=0 RTN
*_PrepXor
D1=(5)=IRAMBUFF P=3
$3A A=DAT0.S B=A.S A!C.S DAT1=C.M D1+11
$3A B&C.S AB.S DAT0=A.S DAT1=C.M D1+11
$34 ?ST=0.=fGray RTY DAT1=C.M D1+5
$3A A=DAT1.S B=A.S A!C.S DAT1=C.M D1+11
$3C B&C.S AB.S DAT1=A.S RTN DAT1=C.M D1+12 DAT1=C.S
LC 00 P=0 RTN
"Yann" wrote in message
news:e7958dff41194c78b079cde12bd80a9e@m73g2000hsh.googlegroups.com...
> Jacob, your proposed exercice is very interesting,
> Since you took good care and had great results with SysRPL, would you
> mind if i try to have a look at ASM side, which i'm currently
> learning ?
>
> I only own an HP48SX myself, but it is probably possible to create a
> code which would be compatible with both HP48S and your HP50
>
> Regards

Re: Drawing Arcs
On Aug 5, 8:33*am, Yann wrote:
> Jacob, your proposed exercice is very interesting,
> Since you took good care and had great results with SysRPL, would you
> mind if i try to have a look at ASM side, which i'm currently
> learning ?
>
> I only own an HP48SX myself, but it is probably possible to create a
> code which would be compatible with both HP48S and your HP50
>
> Regards
Hello Yann,
Yes I would be very interested in seeing what might be possible with
ASM and look forward to seeing your progress.
Jacob