How Overclock 50g Hp calculator?
asr...@gmail.com
But the operation with matrix is too slow in certain commands.
I remember a software located at hpcalc.org that overclock the 49g+
calculator, and i tried in my "old" 49g+ calculator with possitive
results.
But when i used in my "new" 50g, this software can`t run.
I heard about the FEM49 software that have a "Fast" routine that use a
overclock system to perform the analisys more quickly.
Someone of yours can tellme how to develope a routine for that??
Is possible to make a overclock in the 50g like the 49g+??
Thanx to all, and sorry my poor english :P
Andreas Möller
> I remember a software located at hpcalc.org that overclock the 49g+
> calculator, and i tried in my "old" 49g+ calculator with possitive
> results.
>
> But when i used in my "new" 50g, this software can`t run.
AFAIK there is no *difference* in this hardware section of the 49G+
and the 50G. I am most curious about this and would be very interested
in trying this out myself on a 49G+ and a 50G. Maybe you could make
the code/program availabe for that, so that others can trial and error
this.
For overclocking take a look at this posts of 'FEM48/49 v5.3 updated
to SR4':
http://groups.google.com/group/comp.sys.hp48/browse_frm/thread/2a723eb70baa8402
This code is based on Al Borowski´s overclocking code.
HTH,
Andreas
http://www.software49g.gmxhome.de
asr...@gmail.com
wrote:
> Hello,
>
> > I remember a software located at hpcalc.org that overclock the 49g+
> > calculator, and i tried in my "old" 49g+ calculator with possitive
> > results.
>
> > But when i used in my "new" 50g, this software can`t run.
>
> AFAIK there is no *difference* in this hardware section of the 49G+
> and the 50G. I am most curious about this and would be very interested
> in trying this out myself on a 49G+ and a 50G. Maybe you could make
> the code/program availabe for that, so that others can trial and error
> this.
>
> For overclocking take a look at this posts of 'FEM48/49 v5.3 updated
> This code is based on Al Borowski´s overclocking code.
>
> HTH,
> Andreashttp://www.software49g.gmxhome.de
Thanx a lot Andreas!
I use part of your code for error checking, but for clock i use de Al
Borowski apps with successfull results.
I drop down the time to run my app in a 40%, i confuse in something...
the processor take more time to run my app using a 203 mhz setting,
that using a 119 mhz.
for this, i use de 119mhz for performance, and i implemented your code
for error handling.
Thanx and sorry my english, see u in adictoshp.org, bye!
Andreas Möller
> I use part of your code for error checking, but for clock i use de Al
> Borowski apps with successfull results.
The code inside my post 'FEM48/49 v5.3 updated to SR4' is the one from
Al Borowski in *binary* format which sets the calculator to 203 MHz
and the one at the end (in binary format as well) sets it back to 75
MHz.
> I drop down the time to run my app in a 40%, i confuse in something...
> the processor take more time to run my app using a 203 mhz setting,
> that using a 119 mhz.
> for this, i use de 119mhz for performance, and i implemented your code
> for error handling.
This does not make sense. I suspect that something different is
happening here which is impossible to speculate about without seeing
the code. The same code (in RAM of the calc) run at 203MHz can not be
slower than running at 119 MHz ;-)
Best wishes,
Andreas
http://www.software49g.gmxhome.de
data...@gmail.com
> Hi to all, im developing a software in sysrpl for structural analisys.
>
> But the operation with matrix is too slow in certain commands.
Have you considered C? The following is a link to a C-based Sparse
Linear Solver that can be called from UserRPL:
http://sense.net/~egan/hpgcc/#Example:%20Sparse%20Linear%20Solver
Scroll down to the "Dense vs. Sparse" section for a comparison of the
50g's internal matrix solver vs. the one in C.
It's just an example and may or may not apply to you. But, the
argument is the same, you could write the time critical parts of your
code in C and save a lot of time. E.g. the setup and solve of a 99x99
matrix took the internal solver 90 seconds, whereas the same problem
in C was setup and solved in 7 seconds.
Claudio Lapilli
wrote:
It does make sense if you consider that:
* Al Borowski overclocking code was part of early experiments with the
ARM processor. The routine may not use the optimum values for the rest
of the hardware to work including screen, keyboard, memory, etc. (it
was reported that keyboard cannot be read at higher speeds, for
example).
* The increased processor speed doesn't mean you can increase the RAM
access speed. Memory access needs to run at the same speed (for which
proper wait cycles must be added, which has to be configured in the
overclocking routine).
I've made my own experiments with overclokcing for hpgcc 3.0 and once
you get everything properly setup to run at higher speeds, you'll see
a speed increase that varies according to your program.
For programs that are CPU intensive but don't use much memory, the
speed increase is almost linear.
Programs that are memory-intensive show little or no increase at all,
even when running at 192 MHz vs. 75 MHz. This is simply because the
memory is accessed at the same clock speed.
The case mentioned by the OP, where the program runs slower, is
probably because the memory speed is "underclocked", perhaps as a bug
or perhaps because there are limited clock division/memory wait states
possible configurations, and memory must use a slower speed than
normal.
Regards,
Claudio
mjc
I read all of Egan Ford's article and all I can say is WOW!
There is a lot of amazing stuff there. I did not realize all that the
50g could do.
If only HPGCC could be ported to the 50g:)
asr...@gmail.com
> > Have you considered C? The following is a link to a C-based Sparse
> > Linear Solver that can be called from UserRPL:
i thinking about programming in C, but i see that the result file size
is very big. But, you have the reason...this can be the solution where
the sysrpl is slow (matrix operations, etc).
Respect to the message writed by Claudio,...yeah :) you have the
reason too. This could be because some commands are CPU or Memory
based (principaly).
Is for that, that is necessary to experiments the best way to mannage
the system clock..are possible a tool to clock only the memory??
if the answer is yes, this be a great, because you can adapt the clock
of your cpu/memory depending on the aplication or command.
Claudio, i think that the FAST routine included in your structural
analisys software is great, you can re-considere the option to turn
off the LCD; not for speed gain, only for battery save, remember that
the clock increment the battery usage, and if you can disable the LCD
for this time, you are saving energy.
Consider this ;) ( please sorry the english, i aprove the english 1
this semester!! XD )
Sometimes, i think when are the final of the sys and the user rpl,
because i think that the calculator progress is stopped by HP..is for
that, that born HPGCC programming language ported to hp, for solve the
slow emulation of older saturn.
HP must be write a new ROM, for use the new Samsung prosessor fully :O
but for now..i think that the relation time/size/complexity is
balanced to sysrpl.
data...@gmail.com
> > > Have you considered C? The following is a link to a C-based Sparse
> > > Linear Solver that can be called from UserRPL:
>
> i thinking about programming in C, but i see that the result file size
> is very big.
True, but it is not an issue. All my examples are stored on the SD
card and run directly from the card. The most UserRPL can access is
just under 256KB, where as C can access ~ 400KB. So, the overhead to
load the C program from SD to RAM is not a factor. Most of my C
programs have ~320KB of RAM to use once the program starts.
More info here:
http://sense.net/~egan/hpgcc/#C%20Binaries%20Are%20Big,%20Too%20Big
The CG library created here takes very little space because the C
binaries are on SD:
http://sense.net/~egan/hpgcc/#Computational%20Graphics%20Library
CG.LIB is only 817 bytes, whereas CG.ZIP is 151KB. CG.ZIP lives on
the SD (MB/GB of storage vs KB).
Claudio Lapilli
> Claudio, i think that the FAST routine included in your structural
> analisys software is great, you can re-considere the option to turn
> off the LCD; not for speed gain, only for battery save, remember that
> the clock increment the battery usage, and if you can disable the LCD
> for this time, you are saving energy.
I think you are confusing me with somebody else. I never wrote any
structural analysis software, despite being a structural engineer.
Credit goes for whoever wrote the software you mentioned.
Regards,
Claudio
John H Meyers
> re-consider the option to turn off the LCD;
> not for speed gain, only for battery save...
Hopefully the amount of energy for driving the LCD
may be so minute as to be a negligible influence on battery life,
particularly if the only time "off" would be during
modest intervals during program running,
and while nothing was changing on the display.
It could actually be disconcerting to see one's display
turn off unexpectedly, so the chance of medical consequences
(and their huge cost) should also be factored into the equation :)
-[ ]-