(48GX) SpeedUI 14.01 released:-)

[Raymond Del Tondo]

Hello all,

here's a new release of SpeedUI.

SpeedUI 14.01 fixes some bugs and adds some new features.
Some functionalities have been remodularized for more flexibility.

A Lite version of the SpeedUI stack replacement functionality has been added, which omitted some pretty print features, but has a noticably smaller memory footprint.

See RelNotes.txt , StartHere.pdf and MoreInfo.pdf for details.

All older versions of SpeedUI have to be uninstalled prior to installing SpeedUI version 14.01 .

For installation/uninstallation, please take a look into StartHere.pdf supplied with the latest SpeedUI archive.

The new version is available here:
http://www.hpmuseum.org/guest/deltondo/speedui.pdf (Walkthrough PDF)

http://www.hpmuseum.org/guest/deltondo/sui_1401.zip (SpeedUI zip archive)

and on http://www.hpcalc.org once the site will be updated.

For HP 48SX users:
Currently most SpeedUI components need a G model to run.
If there's sufficient positive feedback, maybe I could be convinced to start an SX backport of the SpeedUI core functionality, namely the enhanced stack interface with the high-speed editor.
This hypothetical SX version would be comparable to the lite version of the G series SpeedUI.
Any feedback please as PM or mail, since I don't check the software library very often.

Have fun:-)

Raymond

[Han]

I'd be interested in an SX backport.

[Massimo Gnerucci]

Thanks Ray!

[rprosperi]

(04-26-2014 02:54 AM)Raymond Del Tondo Wrote:  Hello all,

here's a new release of SpeedUI....

Raymond

Thanks Ray, I downloaded and hope to check this out soon. I'll send feedback once installed and all is set up. Glad the 48GX platform continues to improve 20+ years on...

[JDW]

From what I understand, SpeedUI works on any of the 48 series "with enough RAM," but how much RAM is required?

It also seems that SpeedUI can be installed along side the Meta Kernel, but only on the 48GX since the Meta Kernel requires a dedicated 128K RAM card.

Are there any conflicts when both SpeedUI and Meta Kernel are installed and running? And are there any functional overlaps between the two?

[JDW]

It's been over 1 month since my previous post but not a single person has replied. Are there no 48GX users out there who have even tried SpeedUI?

Also, whatever happened to its author, Raymond Del Tondo? Surely he must still be around seeing that his version 15.01 of SpeedUI came out less than 1 year ago in September 2015.

But as I wrote in my previous post, I am curious how you run all the libraries. Meta Kernel 2.3 fits on a single 128k card that is merged with system RAM. But take a look at the size of all the SpeedUI libraries here:

http://www.hpcalc.org/details/6369

Subtracting the *.text and *.pdf filesizes, we are left with about 180k of library data, which of course will not fit on a 128k card for the 48GX. Or is SpeedUI different than Meta Kernel in that SpeedUI can be used on something other than a 128k card merged with system RAM?

Thanks.

[matthiaspaul]

(08-13-2016 07:38 AM)JDW Wrote:  It's been over 1 month since my previous post but not a single person has replied. Are there no 48GX users out there who have even tried SpeedUI?

This might be down to the fact that this particular sub-forum somewhat oddly is default-sorted by "subject" in "ascending order", whereas the actual discussion sub-forums are sorted by "last post" in "descending order". So, most readers of the forum won't even see your post when visiting this sub-forum unless they change the sort order...

Greetings,

Matthias

PS. I can't answer your SpeedUI questions.

[rprosperi]

(08-13-2016 07:38 AM)JDW Wrote:  It's been over 1 month since my previous post but not a single person has replied. Are there no 48GX users out there who have even tried SpeedUI?

....

But as I wrote in my previous post, I am curious how you run all the libraries. Meta Kernel 2.3 fits on a single 128k card that is merged with system RAM. But take a look at the size of all the SpeedUI libraries here:

http://www.hpcalc.org/details/6369

Subtracting the *.text and *.pdf filesizes, we are left with about 180k of library data, which of course will not fit on a 128k card for the 48GX. Or is SpeedUI different than Meta Kernel in that SpeedUI can be used on something other than a 128k card merged with system RAM?

SpeedUI is modular and you can elect to install as many or few of it's components, depending on which UI items you wish to speed-up; e.g. you can replace the basic stack (multiple versions, one includes SysRPL view), Message box, Matrix editor, Library catalog, etc.

The components are libraries, so in general they can load wherever libraries can, but a few are limited to Port-1 as they can't work in covered ports. These limitations are noted.

All of this is detailed in the docs, though I recommend reading them all through a couple times, as the flexibility of loading various modules can lead to many configurations, and can be a bit confusing on the first read.

After trying this, if questions remain, perhaps try to contact Ray via PM or email?

Also, I've not ever loaded it simultaneously with MK, so can't address that aspect. Good luck, I think you'll find SpeedUI pretty amazing.

[JDW]

Matthias & Bob,

Thank you for your replies.

Last night, I was reading the StartHere.pdf that comes with the latest 15.01 version of SpeedUI. Installation instructions are presented on page 2. Some libraries can be saved to port 0 (which I assumed includes merged memory) or port 1. Nothing is said about the other libraries, which implies they can be saved in any port, such as a 4MB card in slot 2.

Uninstallation looks rather complex though in that you need to know the "library number" of each library in order to uninstall them. And since those numbers are not given in that PDF I would assume those numbers change in accordance with whatever port you use to install them.

Understanding that SpeedUI is both Modular and Newer, Meta Kernel nevertheless appears to retain 2 key advantages: (1) it all fits on a 128k merged card in slot 1, and (2) one of the slowest and most painful features of the HP48 is the Equation Writer, which Meta Kernel replaces by SpeedUI does not.

I will send an email to Raymond, at his "magic48" email address listed at the back of his SpeedUI.pdf, alerting him to this thread for further discussion. Hopefully that email address is still valid.

[Raymond Del Tondo]

Hello James, hello all,

thank you for the hint:-)

Yes, the topic seemed to have floated away from the first page too fast, so I didn't see it.

Replying to your latest post first:
"Nothing is said about the other libraries, which implies they can be saved in any port, such as a 4MB card in slot 2."
Most of the libs should work from any of the available ports, but since access to covered ports is relatively slow, some of the speed gain of those SpeedUI libs stored in covered ports will be lost.

"Understanding that SpeedUI is both Modular and Newer, Meta Kernel nevertheless appears to retain 2 key advantages: (1) it all fits on a 128k merged card in slot 1, and (2) one of the slowest and most painful features of the HP48 is the Equation Writer, which Meta Kernel replaces by SpeedUI does not."
(1) SpeedUI is very modular, and the core libraries are available in "full" and "lite" versions. It's possible to squeeze a SpeedUI core into an HP 48G with 32K RAM. Try this with MK;-)
(2) SpeedUI supports the standalone version of RainEQ, so if RainEQ is installed, it will be used instead of the built-in EquationWriter.

Please note that SpeedUI focusses slightly different than MK. With SpeedUI, you'll have the option to replace all user interface stuff by faster versions, one, some, or all. This includes (but is not limited to) input forms and Choose boxes, which are used widely throughout the whole HP 48 UI. Afaik MK doesn't offer faster and system compliant input forms or Choose boxes.

I don't know if MK and SpeedUI can be installed at the same time.

As for SpeedUI library numbers: They shouldn't change in the near future.
However, maybe I should add the library numbers to the library info area in MoreInfo.pdf .

Target platform?
Currently SpeedUI needs an HP 48G/GX/G+ to run.

A (reduced) S/SX version is in the pipe, but since the weather was so nice lately (and still is) , much of my free time goes by riding around with my fastest GX 48:-)

[JDW]

Raymond,

Thank you for your helpful reply.

I agree it would be helpful to have the library numbers in your MoreInfo.pdf for uninstallation.

Unfortunately, RainEQ was last updated in 1998, and most comments about it I read are negative, saying it crashes and that the Meta Kernel EQW is faster. Have a read of the comments yourself here:

http://www.hpcalc.org/details/1409

https://groups.google.com/forum/?nomobil...bddt35G1Xo

"covered ports"?? You mean "any port from 1 to 32"? Or only ports used by a card in slot 2?

By the way, I spoke to a seller of FRAM cards on EBAY. I asked him about speed. He said FRAM cards care much faster than SRAM cards (which need a battery), but that the 48GX will limit FRAM card speed. Even so, he said FRAM cards will be 20-30% faster than SRAM cards in the GX. As such, would there still be a slowdown when using an FRAM card and those "covered ports"?

Thanks.

[Raymond Del Tondo]

I mainly added RainEQ support because it is available as a standalone and self-contained version.

Rewriting the built-in EQW or even creating a new (and fast) EQW would take ages, and the EQW is not my main interest;-)

(08-14-2016 07:54 AM)JDW Wrote:  "covered ports"?? You mean "any port from 1 to 32"? Or only ports used by a card in slot 2?

Covered ports on an HP 48G Series calc normally means any RAM card in physical port 2, which also means logical ports from 2 to 32.
A RAM card in port 1 is uncovered in most situations. RAM in port 0 can always be considered uncovered, unless the system uncovers the underlying ROM temporarily. However this is transparent to the user, so in normal situations, you'll never notice.

(08-14-2016 07:54 AM)JDW Wrote:  By the way, I spoke to a seller of FRAM cards on EBAY. I asked him about speed. He said FRAM cards care much faster than SRAM cards (which need a battery), but that the 48GX will limit FRAM card speed. Even so, he said FRAM cards will be 20-30% faster than SRAM cards in the GX. As such, would there still be a slowdown when using an FRAM card and those "covered ports"?

AFAIK the limiting factor is the HP 48 hardware, so there should be nearly no performance difference between SRAM and FRAM from the HP 48 side.
But I'm not an expert on hardware, so topics on that level could be better answered by Christoph Giesselink.

[JDW]

(08-14-2016 11:02 PM)Raymond Del Tondo Wrote:  Covered ports on an HP 48G Series calc normally means any RAM card in physical port 2, which also means logical ports from 2 to 32.

Raymond, today I was reading page 5 of the ALG48.pdf contained in the ALG48 archive. It says it "uses a special technique to avoid the usual slowdown associated with running a library from a covered port." But that the downside is that it "cannot be run from a covered port if the RAM card in Card Slot 1 is merged with user memory."

So I guess the reason you did not use that same "special technique" in SpeedUI is for the same reason?

[Christoph Giesselink]

(08-14-2016 07:54 AM)JDW Wrote:  By the way, I spoke to a seller of FRAM cards on EBAY. I asked him about speed. He said FRAM cards care much faster than SRAM cards (which need a battery), but that the 48GX will limit FRAM card speed. Even so, he said FRAM cards will be 20-30% faster than SRAM cards in the GX.

I don't know why the seller talk about FRAM is much faster. Much faster than what?

I agree FRAM is much faster than any Flash or EEprom chip, but not comparing to SRAM.

Let's have a look, a normal SRAM 128Kx8 chip is available with access times of 70ns, 55ns, 45ns and 35ns. Decades ago, such a SRAM chip had access times of 70ns or 100ns.

Actual Cypress FRAM chips 128Kx8 as replacement for SRAM chip have a random access time of tRC = 90ns (Cypress FM28V100 Data Sheet) for the 3.3V type. I haven't found a 5V type so I don't how they could be a replacement for a 5V SRAM?

So comparing the random access times between SRAM and FRAM they are mostly identical.

The Saturn CPU core is slow down by many factors. First by the memory interface translating the 8bit parallel access to the multiplexed 4 bit Saturn bus protocol and finally by the Unified Memory Architecture sharing the RAM memory between CPU and Display driver.

So I wouldn't expect any noticeable speed difference.

[JDW]

Thank you for your detailed reply, Christoph!

Here is an exact quote from the EBAY seller regarding his FRAM cards for the 48GX:

FRAM cards are much faster then older SRAM cards, but the gating factor is
not performance of the card, but performance of HP48GX reads and writes.
FRAM card maxes out performance capabilities of HP48GX, so in real terms it
will only be slightly faster then older SRAMs. My guess is about 20-30%
improvement

So he says "older SRAM" cards, which per your reply today would put them in the 70ns or 100ns category. And since those HP branded "older" cards are still sold on EBAY even to this day, it perhaps is a reasonable thing for him to have told me. But you are right, if comparing a "modern" SRAM card to an FRAM card, the speed difference should be negligible.

But since the 48GX was built back in the mid-1990s, system RAM on the calc's PCB would be old tech RAM. So wouldn't that mean that a modern tech SRAM card or an FRAM card would be at least as fast or faster than that buit-in 128k of System RAM? Or is even merged memory on a card in Slot 1 slowed down to be slower than system RAM, regardless of how fast that card may be?

Thanks.

[matthiaspaul]

(08-16-2016 11:50 PM)JDW Wrote:  Here is an exact quote from the EBAY seller regarding his FRAM cards for the 48GX:

FRAM cards are much faster then older SRAM cards, but the gating factor is
not performance of the card, but performance of HP48GX reads and writes.
FRAM card maxes out performance capabilities of HP48GX,

This is correct up to this point.

Quote:so in real terms it will only be slightly faster then older SRAMs. My guess is about 20-30% improvement

This part of the seller's statement is incorrect per the explanation given here:

http://www.hpmuseum.org/forum/thread-656...l#pid59836

The gain will be exactly 0% unless there would be some means (for example by extra card pins) to communicate back the speed of the (card) memory to the processor (and for the processor to have some means to change its timing accordingly). I am not aware of such means in the HP48.

In theory, there could be some gate-protected in-band-communication to communicate chip performance parameters back to the processor (like the trick used for software-programmable write-protection in the FRAM chip linked above, but this is something specific to the chip, and not following a standard). I'm not aware of the usage of any such in-band-communication in conjunction with parallel asynchronous SRAMs at all, but even if such may exist somewhere today, I'm quite sure it didn't in the early to mid 1990s when the HP48 series was designed.

Greetings,

Matthias

[JDW]

Matthias,

Understood. Thank you for pointing that out. I don't doubt you.

But as was the case in our 50g SD Card discussion, an actual in-calc test shows us how the theoretical compares to the experimental.

Surely, there must be at least one person among us who has purchased an FRAM card? Assuming they also have an SRAM card (with battery) of the same size, they could performance-test both and post the data for us. A set of 128k cards may be best for that, since they can be used in either Slot on the 48GX.

But at the end of the day, so long as whatever card used isn't slower than internal RAM, that's all that matters.

[Raymond Del Tondo]

(08-16-2016 06:03 AM)JDW Wrote:  

(08-14-2016 11:02 PM)Raymond Del Tondo Wrote:  Covered ports on an HP 48G Series calc normally means any RAM card in physical port 2, which also means logical ports from 2 to 32.

Raymond, today I was reading page 5 of the ALG48.pdf contained in the ALG48 archive. It says it "uses a special technique to avoid the usual slowdown associated with running a library from a covered port." But that the downside is that it "cannot be run from a covered port if the RAM card in Card Slot 1 is merged with user memory."

So I guess the reason you did not use that same "special technique" in SpeedUI is for the same reason?

I don't know which "special technique" is used in Alg48, but from the description and limitations Alg48 seems to temporarily remap the covered port containing Alg48 into an uncovered area. This is a possible config as long as the code doesn't call system routines which move RAM/ROM configuration themselves.

There are different ways to access covered data. The HP way via access pointers is relatively slow but flexible.

Filer48 (of which the source is available) shows how it can be made much faster.

The code behind the SpeedUI QSM mechanism uses access pointers to retrieve the QSM data.
Accessing port data/files is not the main topic of SpeedUI, and since that limitation has been resolved by Filer48, there was no need to hassle with it;-)

[Han]

(08-14-2016 07:54 AM)JDW Wrote:  Raymond,

Thank you for your helpful reply.

I agree it would be helpful to have the library numbers in your MoreInfo.pdf for uninstallation.

Unfortunately, RainEQ was last updated in 1998, and most comments about it I read are negative, saying it crashes and that the Meta Kernel EQW is faster. Have a read of the comments yourself here:

http://www.hpcalc.org/details/1409

https://groups.google.com/forum/?nomobil...bddt35G1Xo

"covered ports"?? You mean "any port from 1 to 32"? Or only ports used by a card in slot 2?

By the way, I spoke to a seller of FRAM cards on EBAY. I asked him about speed. He said FRAM cards care much faster than SRAM cards (which need a battery), but that the 48GX will limit FRAM card speed. Even so, he said FRAM cards will be 20-30% faster than SRAM cards in the GX. As such, would there still be a slowdown when using an FRAM card and those "covered ports"?

Thanks.

In general, a covered port is ANY port whose memory location is literally covered by other devices that have been configured (mapped to) either the same or overlapping memory blocks. The memory devices include: ROM, RAM, I/O RAM, card slots 1 & 2, etc. Since the entire address space is only 20 bits wide (#0h through #FFFFFh), these devices must therefore share certain blocks of the address space, with some devices having higher priority than others. The address space for RAM is normally configured at #80000h and the card slots at #C0000h, for example. The ROM, however, takes up the entire address space. When you read data from #80000h you are actually reading the RAM (under normal conditions) and not the ROM because the RAM has higher priority. So this is where we get the notion of covered memory.

When accessing data or running code from covered memory, devices of higher priority are reconfigured to different memory addresses temporarily so that data access will read from the previously covered devices (programs are then copied into RAM, and then run from there after the devices are reconfigured back to the prior addresses). This copying process, and any associated memory management (e.g. garbage collection) is the reason for the slower performance of code running from covered ports.

One way to get around this is to simply unconfigure the higher-priority devices -- which works fine if you know what you're doing. Since the interrupt system checks to make sure that devices are ok, it can be quite dangerous when such code is not properly vetted.

Hope that helps.

EDIT: additional reading

HP48SX design: http://www.hpl.hp.com/hpjournal/pdfs/Iss...991-06.pdf
HP48GX design: http://www.hpcalc.org/hp48/docs/misc/hpj-48gx.zip