speedui fonts
rs1n
like the 6 level stack, but I prefer using my own fonts. Are the fonts
designed to be 6x4 (6 rows of pixels, 4 columns wide)?
Raymond Del Tondo
the SpeedUI 6x6 stack level display font is built-in into the engine,
internally double compressed,
and thus not customizable at the moment.
The other fonts used in the input forms, choose and
message boxes are either the HP-48 built-in fonts,
or taken from UFL if the UFL is installed.
There are plans for one of the next SpeedUI releases
to "outsource" the SpeedUI 6x6 stack font into an
enhanced version of the UFL, maybe as font 3 or 4.
That would allow to customize the look,
and also streamline some of the
inner workings of SpeedUI;-)
HTH
Raymond
"rs1n" <handuo...@gmail.com> schrieb im Newsbeitrag
news:b1a3a8c9-e374-4bba...@d4g2000vbm.googlegroups.com...
rs1n
I noticed that the commands such as xINEG, xI-, etc. were compiled to
have EQWR properties, among others. However, they do not seem to
behave as expected when used in the EQWR. Or is there something I'm
not understanding about these attributes?
On Oct 21, 11:50 am, "Raymond Del Tondo" <Ih8...@nowhere.com> wrote:
> Hi,
>
> the SpeedUI 6x6 stack level display font is built-in into the engine,
> internally double compressed,
> and thus not customizable at the moment.
>
> The other fonts used in the input forms, choose and
> message boxes are either the HP-48 built-in fonts,
> or taken from UFL if the UFL is installed.
>
> There are plans for one of the next SpeedUI releases
> to "outsource" the SpeedUI 6x6 stack font into an
> enhanced version of the UFL, maybe as font 3 or 4.
>
> That would allow to customize the look,
> and also streamline some of the
> inner workings of SpeedUI;-)
>
> HTH
>
> Raymond
>
> "rs1n" <handuongs...@gmail.com> schrieb im Newsbeitragnews:b1a3a8c9-e374-4bba...@d4g2000vbm.googlegroups.com...
Raymond Del Tondo
the props of the xI* keywords are not EQwriter specific,
but used for error handling and dispatching mainly.
When using algebraics, you should use the normal keywords,
without the "I" predicate.
HTH
Raymond
"rs1n" <handuo...@gmail.com> schrieb im Newsbeitrag
news:5b5abb84-d5f5-4e87...@p15g2000vbl.googlegroups.com...
rs1n
press (and hold) left-shift to type lower-case letters. Only the first
letter gets lower-case'd, and the remaining letters are still
capitalised even while left-shift is held down.
[alpha] [alpha] [leftshift (hold for next three keys)] [A] [B] [C]
S4.6 mode on produces
aBC
whereas the normal behavior should produce
abc
Raymond Del Tondo
Thanks for pointing out this bug.
"rs1n" <> schrieb im Newsbeitrag
news:a1f5a271-f6aa-4398...@d4g2000vbm.googlegroups.com...
rs1n
editing the following program (entered here exactly as is viewed on
the HP48, including linebreaks).
<< TIME '1-COS(X^2+Y^2
^2)/(X^2+Y^2)' -3.5
3.4 -3.5 3.4 15 15
PLOT3D TIME ROT
HMS-
>>
Place the cursor on the 'C' in the function COS and press the DEL->
key. The screen shows:
<< TIME '1-COS(X^2+Y^2
<< TIME '1-^2)/(X^2+Y^...
3.4 -3.5 3.4 15 15
PLOT3D TIME ROT
HMS-
>>
Basically, keep pressing <-DEL or DEL-> on the menu and you will see
that the screen does not properly update. I'm guessing there was a
MOVEUP routine that did not have a followup routine to blank out
artifact pixels.
Out of curiosity, is the fast editing routine a part of UI.LIB? Or is
it part of CF.LIB? UI.LIB seems based off of Java, but yet is smaller.
Best wishes,
Han
Raymond Del Tondo
thanks again for the bug report.
Actually the edit display row update bug
is in the todo list for a while,
however it's only a cosmetic thing,
but will be fixed, of course:-)
> Out of curiosity, is the fast editing routine a part of UI.LIB?
> Or is it part of CF.LIB?
>
Both. The display engine and decompiler resides in CF.LIB,
various new ML edit functions reside in UI.LIB
> UI.LIB seems based off of Java, but yet is smaller.
>
The fast stack display was not based on JAVA,
but on my own six level stack display routine,
which used a modification of the self-contained
standard frame POL for a 5-level stack display routine
from about 1991, which we used in the RPL48 package.
When I included the ML decompile routine from Will Laughlin,
I had to adjust various routines of my stack display
to match the output of the ML decompiler,
hence there are some similarities now.
The fast SpeedUI editor has nothing to do with the edit mode in JAVA,
the only commonly used routine is the ML decompiler from Will,
with some modifications from me.
Everything else was written new from scratch,
and that's why scrolling is that fast:-)
CF.LIB can be seen as base library,
a concentration of all functionalities which are
used in more than one SpeedUI component.
That's why CF.LIB is that big in size now;-)
In one of the next releases, there may be an option
for a stripped down CF.LIB , which doesn't
include the ML decompiler.
That'll save another 11 or 12K, but will of course
have some impact on the overall performance.
Best Wishes
Raymond
"rs1n" <handuo...@gmail.com> schrieb im Newsbeitrag
news:6d43bd00-70ea-49ee...@u13g2000vbb.googlegroups.com...
rs1n
> > Out of curiosity, is the fast editing routine a part of UI.LIB?
> > Or is it part of CF.LIB?
>
> Both. The display engine and decompiler resides in CF.LIB,
> various new ML edit functions reside in UI.LIB
>
I see. The ML edit is fantastic! SpeedUI continues to give the HP48
another breath of fresh air.
> > UI.LIB seems based off of Java, but yet is smaller.
>
> The fast stack display was not based on JAVA,
> but on my own six level stack display routine,
> which used a modification of the self-contained
> standard frame POL for a 5-level stack display routine
> from about 1991, which we used in the RPL48 package.
>
> When I included the ML decompile routine from Will Laughlin,
> I had to adjust various routines of my stack display
> to match the output of the ML decompiler,
> hence there are some similarities now.
>
Ahh, I see now. I actually still have RPL48 installed on an old
HP48SX. Was the POL you mentioned at all related to the SOL back when
folks were working on speeding up the HP48SX? Both were fantastic
packages. BTW, I REALLY love how nice the editor is with this latest
release of SpeedUI!
rs1n
When set to use small fonts for algebraic objects, the display of the
stack level of certain algebraics is inconsistent.
1. Compare 'X^2' vs 'X-1' with small fonts enabled. Clear the screen,
then switch to medium fonts, and re-enter the same two equations.
2. Leave 'X^2' and 'X-1' on the stack, and switch between small and
medium fonts. The cache does not update, but the stack level indicator
changes sizes as seen in 1.
rs1n
currently an error message up in the status area, pressing [up] to
enter the interactive stack leaves a bit of garbage left where the
clock should appear.
Example:
Stack has one object
1: 2
press [y^x] [up]
Raymond Del Tondo
About the bugs: 3 of the 4 have been fixed for SpeedUI v9.08 ,
I hope to get the last one fixed soon.
About the Alg mode:
That was one of the things which were not
part of my original stack interface design,
and I had no intention to include it.
However, at some point there were users who wanted this feature,
so I included it.
The cache update bug only occurs after changing the
alg font size. After changing the setting in the config dialog,
Java had an explicit WipeCache call for this. Since my config
dialogs are independent from the SpeedUI stack interface,
this wasn't the way to go.
Instead, I introduced kinda stack flag cache,
whose settings are checked at certain places.
This mechanism detects alg font size changes,
and clears the cache if necessary.
The edit mode line shift bug was caused
by a missing ML RTN line...
The review mode trash status line area was
caused by a missing display update instruction.
These have been fixed so far.
One of the next releases will have the
path display with UFL font support.
Raymond
"rs1n" <handuo...@gmail.com> schrieb im Newsbeitrag
news:9c4abca6-73cd-4244...@i12g2000prg.googlegroups.com...
Raymond Del Tondo
An updated SpeedUI archive will be available at the usual places soon:-)
Raymond
"Raymond Del Tondo" <Ih8...@nowhere.com> schrieb im Newsbeitrag
news:hcj0nt$aca$03$1...@news.t-online.com...
rs1n
the next release!
On Nov 6, 7:33 pm, "Raymond Del Tondo" <Ih8...@nowhere.com> wrote:
> Did I mention that I found and fixed the 4th bug a few days ago?
>
> An updated SpeedUI archive will be available at the usual places soon:-)
>
> Raymond
>
> "Raymond Del Tondo" <Ih8...@nowhere.com> schrieb im Newsbeitragnews:hcj0nt$aca$03$1...@news.t-online.com...
>
>
>
> > Glad you like it:-)
>
> > About the bugs: 3 of the 4 have been fixed for SpeedUI v9.08 ,
> > I hope to get the last one fixed soon.- Hide quoted text -
>
> - Show quoted text -
Raymond Del Tondo
It fixes the four display update bugs,
and introduces one small optical change:
The empty space chars beneath the brackets
in the PATH status display have been omitted
to make room for up to two more chars.
The next major release "10" may have
switchable fonts for the stack display.
These will also be editable,
since they are located in an extended version of the UFL,
which will include my 6x7 stk font as FNT3,
and maybe (or optional) a 5x9 font for mimicing
the 4-level stack display within SpeedUI.
This is the plan, and I'm currently preparing some
things for it, but there's still some work to be done;-)
"rs1n" <> schrieb im Newsbeitrag
news:fe10e081-46ae-4236...@m16g2000yqc.googlegroups.com...
Chris
> SpeedUI 9.08 is a bugfix release only.
> It fixes the four display update bugs,
> and introduces one small optical change:
> The empty space chars beneath the brackets
> in the PATH status display have been omitted
> to make room for up to two more chars.
>
> The next major release "10" may have
> switchable fonts for the stack display.
>
> These will also be editable,
> since they are located in an extended version of the UFL,
> which will include my 6x7 stk font as FNT3,
> and maybe (or optional) a 5x9 font for mimicing
> the 4-level stack display within SpeedUI.
Sounds good. The big fonts do make for easier reading.
John H Meyers
> Sounds good. The big fonts do make for easier reading.
For a "really big shew," see:
http://www.hpcalc.org/details.php?id=2638
http://www.time.com/time/magazine/article/0,9171,972334,00.html
http://calstate.fullerton.edu/news/arts/2003/149_big_shew.html
http://www.google.com/search?q=ed+sullivan
[r->] [OFF]
Chris
> On Tue, 10 Nov 2009 04:09:13 -0600, Chris wrote:
> > Sounds good. The big fonts do make for easier reading.
>
> For a "really big shew," see:http://www.hpcalc.org/details.php?id=2638
LOL. That's great. I'm going to load it.
rs1n
level indicator that is of the wrong size -- is this a bug in the
AGROB routine? This bug appears to be still in EQSTK and Java as well.
I use EQSTK for my HP48SX (smaller size) and it annoys me that EQSTK
does not have a consistent font size for the stack level indicator.
On Nov 6, 6:33 pm, "Raymond Del Tondo" <Ih8...@nowhere.com> wrote:
> Did I mention that I found and fixed the 4th bug a few days ago?
>
> An updated SpeedUI archive will be available at the usual places soon:-)
>
> Raymond
>
> "Raymond Del Tondo" <Ih8...@nowhere.com> schrieb im Newsbeitragnews:hcj0nt$aca$03$1...@news.t-online.com...