50g - overclock

[Vtile]

Hello

I have been trying to search the small program I remember seen somewhere in the HPCalc.org which did allow to adjust the CPU speed of the 50g.

Can someone recall the name of it or do I remember incorrectly and there is no such.

PS. Were there also a program that converted userRPL to sysRPL?

[Zaphod]

This ?

https://www.hpcalc.org/details/6081

[Vtile]

That is the one, many thanks.

I wonder how I didn't manage to find it. :o

[Zaphod]

(05-19-2018 09:12 PM)Vtile Wrote:  That is the one, many thanks.

I wonder how I didn't manage to find it. :o

I used google

http://lmgtfy.com/?q=50g+overclock

[Vtile]

It seems I would need some extra help with these Cxx programs. How I need to install them as it seems that they are not working if I just copy them to HOME or FLASH (port 2)

I'm a bit confused with these, they are not libraries so I assume I do not attach them.

(05-19-2018 09:15 PM)Zaphod Wrote:  

(05-19-2018 09:12 PM)Vtile Wrote:  That is the one, many thanks.

I wonder how I didn't manage to find it. :o

I used google

http://lmgtfy.com/?q=50g+overclock

Hah. Yes my google fu were weak.

[Zaphod]

From the file cat.txt, included in the download:

Quote:HP49G+ Clockspeed Adjustment Tools - HP-CAT - V2.00


CAT is a suite of utilities for adjusting the frequency of the HP49g+'s processor.


Please note that Thomas Rast's excellant ARM launcher (launcher.bin) is needed to run any of these programs. Also these tools may have side effects, such as altering the speed of the realtime clock or preventing Calc-PC communication. A power cycle should always return the calculator to normal operation.


Included in this release:

TURBO - for executing commands at 203MHz

SLON/SLOFF - for executing commands at 12MHz

Cxx files - for running at various clockspeeds normally. These overclock memory.

Also included is C124s, a 'safe' overclock. It doesn't overclock memory and should work on any HP49G+. This pushes the CPU to 124MHz.

CFIX - This undoes the effects of TURBO or any of the Cxx files.


=====

1) Slow Mode Tools (SLON/SLOFF)

These enable/disable the Procesors 'Slow Mode'. This sets the clock speed to 12MHz instead of the usual 75MHz.

300! normally takes ~1.5 seconds. In slow mode, it takes about 10 seconds.

This might be useful for old games that run way too fast. While arcade
games wil probably run too slowly, and old greyscale games won't work
properly, some other puzzle games (sokoban etc?) may now be slow enough
to control sucessfully.

SLON will enable slow mode - SLOFF will return to normal 75MHz speed.

--

Usage:

make a program as follows

<<SLON *Target Program Here* SLOFF>>

Save this program and run it. The target program will now run much slower.

You will see the screen glitch for a moment - I will work on removing
this in future versions if anyone cares.

Please note that SLON and SLOFF are matched - do not combine them with the other commands.


========

2) Clock Adjustment Utilities (Cxx)

Several files names Cxx, such as C34 and C90 are included in this file. These adjust the main PLL frequency. C34 sets this to 33.75MHz, C90 sets it to 90MHz etc. Speeds greater then 75MHz overclock your calculator.

Note that the effect of the Cxx utilities lasts until the next power cycle. So you can run C90 once at bootup, and all tasks will execute faster until you turn the power off. Also note that these might run on a HP48gii to bring it up to the speed of a 49g+.

Also the screen appears to flicker abit when running at 33.75MHz. I will fix this if someone emails me and asks nicely.

These Cxx utilities generally overclock the memory bus as well as the CPU. Some calculators crash when running at higher then 90MHz.

A "Safe" option has been included.

'C124S'

overclocks the CPU to 124MHz, but also keeps the memory operating at the speed selected by HP. In theory this should work on any 49G+. Please let me know if it doesn't.

The command 'CFIX' will set the CPU back to 75MHz, and the LCD and memory speeds back to their default settings. You could create a program, <<C90 INTVX CFIX>> to set the CPU to 90MHz while running the INTVX command, and restore itself to 75MHz afterwards.


=======

3) Turbo Mode

If you like to live dangerously, 'TURBO' is for you :-)

Turbo slows down the memory bus, lowers the LCD refresh rate, and clocks the CPU at 203MHz(!). At these speeds, the keyboard reading routine in the OS no longer works correctly. 203MHz is not suitable for general use like the Cxx utilities. Instead you must use TURBO and CFIX in a program to accelerate a series of tasks.

Typical Usage:


Make a program like

<<TURBO _Some_Command_Here_ CFIX>>

and run it. This will run the target command at 203MHz, and restore the system back to 75MHz when done.

The 49G+ was designed for 75MHz operation - 203MHz is _way_ outside the specs. There's a chance TURBO will lock-up your calculator.

Try not to press any keys while TURBO is operating, due to misread keys being placed in the buffer. If your asm programs use TURBO, I suggest turning off the keyboard scanning.


*****************

A quick example timing - Last Stack Disabled, timed with TEVAL

800!

16.43 seconds normally

10.35 seconds at 119MHz (C119) *

12.3 seconds at 124MHz (C124S)

8.5 seconds at 203MHz ( << TURBO 800 ! CFIX>> )

* The memory is overclocked in this setting, and may not work on all 49G+'s.

*****************

If you fine these utilties useful for anything, please drop me an email at al.borowski@gmail.com. That way I know I'm not wasting my time programming them.

--

Disclaimer: These programs temporarily alter internal settings in your calculator. Even though I have tested them and I belive they are safe to use, I might be mistaken. Overclocking may damage your calculator in the long term. Run at your own risk.


cheers,

Al Borowski

al.borowski@gmail.com
12 July 2004

[Vtile]

I indeed did read that, but it doesn't give information if there is any installation requirements. The problem I'm facing is that the programs do not to seem to run properly if I do replicate the examples given as the only thing I end up with is like:

<< C124S.HP 1 1 + CFIX.HP >> EVAL

results:

"¤#"¤!! !" #"!"!#"
'launcher.bin'
2
"¤#"¤!! !" #"!"!#"
'launcher.bin'

... in stack. So I suppose I do miss some installation type of thing in this.

[Helix]

I have read that this tool does not work correctly on the 50G:
http://www.hpmuseum.org/forum/thread-118...l#pid14866

[Vtile]

(05-20-2018 12:38 AM)Helix Wrote:  I have read that this tool does not work correctly on the 50G:
http://www.hpmuseum.org/forum/thread-118...l#pid14866

That would explain the behavior, thank you for the link.

[TravisE]

Vtile: Make sure the program “launcher.bin” included with those tools is in the same directory when you run those programs. Your stack output suggests it's not being found.

I've played with these tools on the 50g and found that they sort of work, but not very well.

Underclocking is okay (though SLON is a bit wonky and doesn't always seem to work properly), but if I try to use anything higher than about 90–100 MHz, my calculators actually start running slower, not faster. Also, changing the clock speed seems to make TICKS behave in a very jittery way (even worse than normal operation, where it occasionally glitches already).

On one of my 50g, the highest clock speeds “work”, but don't really run significantly faster. On the other 50g unit I have, they lock up the system altogether and I have to remove power to force a reboot.

From what I've heard (and according to the thread Helix linked to), HPGCC(3?) handles this much better, but I'm not familiar with it and have never delved into it. Has anyone ever considered using it to create modern wrappers allowing users to change the CPU speed on the 50g properly? Is that actually doable?

[pier4r]

HPGCC3 is an entire new firmware to let run C (arm) code without the ARMtoolbox on the standard firmware.

In HPGCC2 (one could keep the 2.15 firmware in that case) you can push up or down the clock but, for what I know, still within the C code.

Also while I don't like the one that says "oh why do you want to do this?", because if one wants to do something, there is always a reason, I personally wouldn't overclock the 50g while using userRPL as it wouldn't be much a gain compared to the risk. It is way better (also for personal learning and contributing to spot bugs) to install newRPL or to start to work with hpgcc / sysrpl (the first really fast but community based, the second with more documentation around plus still able to use the large RPL library, although slower than C).

If one installs newRPL, aside from certain topics (like CAS), one gets a rpl environment at least 5 times faster than the userRPL if I am not mistaken. That offsets whatever overclock.

[Vtile]

(05-21-2018 10:57 AM)pier4r Wrote:  HPGCC3 is an entire new firmware to let run C (arm) code without the ARMtoolbox on the standard firmware.

In HPGCC2 (one could keep the 2.15 firmware in that case) you can push up or down the clock but, for what I know, still within the C code.

Also while I don't like the one that says "oh why do you want to do this?", because if one wants to do something, there is always a reason, I personally wouldn't overclock the 50g while using userRPL as it wouldn't be much a gain compared to the risk. It is way better (also for personal learning and contributing to spot bugs) to install newRPL or to start to work with hpgcc / sysrpl (the first really fast but community based, the second with more documentation around plus still able to use the large RPL library, although slower than C).

If one installs newRPL, aside from certain topics (like CAS), one gets a rpl environment at least 5 times faster than the userRPL if I am not mistaken. That offsets whatever overclock.

I know that the newRPL provides much more speed with almost drop in support for a userRPL (thanks to Claudios magnificent work), but this one is used for a work so I do want to have full feature set including the CAS.

I only were interesting to get more speed for a few iterative calculution snippets I have build (conditional for loops).. Reading further both these comments provided kindly here and elsewhere and Alistair Borowskis original short documentation it seems pretty obvious that this is a wrong approach.

While I have written a few lines of code in C, I don't seem to like it (in general), maybe I try the 'almost' obsolete HP Pascal Studio which doesn't have such a vision test and parenthesis joggling going on (try to type parenthesis with FI-keyboard and you soon hate your life.).

[brickviking]

(05-20-2018 09:14 PM)TravisE Wrote:  Vtile: Make sure the program “launcher.bin” included with those tools is in the same directory when you run those programs. Your stack output suggests it's not being found.

And I suspect I just found out why not. I copied my files onto a SD card (VFAT filesystem) and then onto the calculator. When doing this, the case was NOT preserved by the calculator filer, it seems to show all my files on the SD card as uppercase. Weirdly enough, renames do stick if I copy the files to main memory or to Port 2, and the case is then preserved. As TravisE suggested, make sure that LAUNCHER.BIN (if that's what you had) gets renamed to launcher.bin. Once you've done that, the rest of the programs (C124S etc) should start working as indicated.

Just to pick nits, all your *.HP files should actually be *.hp, as that's what they are in the zip file.

I've had freezes using TURBO too, so I may work using C124S on a vaguely regular basis. I would like to have seen a version of this that used a slider to select a single target speed from multiple speeds, and perhaps a "command to run" textbox, a "run this once" checkbox (which if empty, would simply set the speed on "Apply") and a pair of Apply/Cancel buttons.

So. Varlist would be like this:

Slider: SLOW, C34,48,75 (CFIX),90,101,113,119,124S,TURBO
Once []: 0: set speed, run $Command if set, then exit, 1: set speed, run $command (if set), then reset speed, then exit.
Command: string of command to run.
Button1: Apply
Button2: Cancel

Any better suggestions than this? Or am I simply chasing rabbits? If you came from the South Island of New Zealand, you'd know this is a fruitless exercise, as there's far too many of them.

(Post 229)

[Vtile]

(05-22-2018 04:37 AM)brickviking Wrote:  

(05-20-2018 09:14 PM)TravisE Wrote:  Vtile: Make sure the program “launcher.bin” included with those tools is in the same directory when you run those programs. Your stack output suggests it's not being found.

And I suspect I just found out why not. I copied my files onto a SD card (VFAT filesystem) and then onto the calculator. When doing this, the case was NOT preserved by the calculator filer, it seems to show all my files on the SD card as uppercase. Weirdly enough, renames do stick if I copy the files to main memory or to Port 2, and the case is then preserved. As TravisE suggested, make sure that LAUNCHER.BIN (if that's what you had) gets renamed to launcher.bin. Once you've done that, the rest of the programs (C124S etc) should start working as indicated.

Just to pick nits, all your *.HP files should actually be *.hp, as that's what they are in the zip file.

I've had freezes using TURBO too, so I may work using C124S on a vaguely regular basis. I would like to have seen a version of this that used a slider to select a single target speed from multiple speeds, and perhaps a "command to run" textbox, a "run this once" checkbox (which if empty, would simply set the speed on "Apply") and a pair of Apply/Cancel buttons.

So. Varlist would be like this:

Slider: SLOW, C34,48,75 (CFIX),90,101,113,119,124S,TURBO
Once []: 0: set speed, run $Command if set, then exit, 1: set speed, run $command (if set), then reset speed, then exit.
Command: string of command to run.
Button1: Apply
Button2: Cancel

Any better suggestions than this? Or am I simply chasing rabbits? If you came from the South Island of New Zealand, you'd know this is a fruitless exercise, as there's far too many of them.

(Post 229)

Oh, nice find.

I can confirm that renaming the LAUNCHER.BIN to launcher.bin will remove all the errors I did report previously in this thread. C113, C119 results a crash/hang and C124S doesn't provide much speed benefit (if at all) for userRPL loop structure. C101 does corrupt at least momentarily something on the system as the softmenu and function keys doesn't match.. So not optimal outside of some obscure use case unfortunately.

[Claudio L.]

(05-26-2018 10:06 AM)Vtile Wrote:  C113, C119 results a crash/hang and C124S doesn't provide much speed benefit (if at all) for userRPL loop structure. C101 does corrupt at least momentarily something on the system as the softmenu and function keys doesn't match.. So not optimal outside of some obscure use case unfortunately.

The programs by Al Borowski were very early experiments with overclocking. The memory and other hardware clocks were going out of range sometimes and that causes instability in the form of random crashes, not exactly what you want when you need to run a long calculation.
HPGCC3 has a much more advanced clocking function (also inherited by newRPL) where you can choose any clock you want, and it programs all other hardware clocks and memory wait states accordingly so it can work at 192 MHz reliably and with a real speed benefit. The bad news is the 50g OS isn't necessarily ready to operate at any clock different from the stock 75 MHz, so even if you use a C program in hpgcc3 to change the clock, some things are expected to simply not work properly. For example, USB and SD card are immediately broken in turbo mode, even though their clocks are programmed correctly. But in some drivers the OS uses fixed loops for small delays, if you make those loops run twice as fast, they don't wait long enough for the hardware to respond and causes all kinds of errors.
If it had been so easy to make the 50g go faster, newRPL wouldn't exist, but the only real solution was to start from scratch.