(48GX) SpeedUI 14.01 released:-)

[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