this is the STOFIX library, version 1.1. It provides a workaround for the STO
and PINIT bug described below on ROM L & M HP48GX's. It's 1187 bytes in size,
its checksum is #81E5h and its Library ID is 1222.
STOFIX is designed to run in any port on ROM rev A-M '48s.
Installation
------------
* if you've a GX w/ two cards installed, remove the card from port 1 as
described in your manual if you want to store the library into another
port than 0 or 1
* download STOFIX.LIB into your '48
* recall it onto the stack and purge the variable containing the d/led
copy
* enter the port number where the library should be stored at, press STO
* warmstart your '48 by pressing ON-C or power cycle it
* reinstall the card in port 1 (if neccessary) as described in your manual
Commands
--------
STOFIX provides 3 new commands, you'll see them after entering the STOFIX
menu (<right>-2 STOFI on a GX, <left>-\|^ STOFI on a SX):
sto ( object1 object2 --> )
This command is a replacement for the build-in STO command, it does
exactly the same, except that it does stores directeced to a port > 1
in a correct manner.
pinit ( --> )
This command is a replacement for the PINIT command, it does exactly
the same, except it won't corrupt the memory of card 1.
SFHLP ( --> )
'StoFix HeLP' - shows three screens of help information.
Usage
-----
Use the STOFIX commands on a L or M HP48GX in case you have installed RAM
cards in ports 1 & 2 for doing the following tasks to avoid memory losts/
corruption:
* to store a library or backup into a port > 1, use sto
* to store other objects into a port > 1, use sto
* to initialize a mulit port card, use pinit
Big description
---------------
There's a *really* bad BUG which appears in ROM rev L & M HP48GX's. I've
only access to this machines, so I don't know if this bug also appears in
other G rev's too. I really hope this is fixed in rev P...
Objects are stored into ports 1-33 from low to high address, and each obj
sequence is terminated by 5 0-nibbles following immediately the last obj of
a port. This marker is used as end of obj sequence and to signal an intact
port.
Two cards will share the address space starting at address #C0000, port 1
will be active all the time, and ports 2-33 are memory mapped into this
address space temporarily on accesse requests.
If you've plugged in two cards, and store a library into eg. port 2 (with
2 STO - this may be a 32k, 128k or 1M card) the following actions takes
place:
a) port 2 is mapped to #C0000
b) the postion of the 00000 marker is determined
c) the library is added to the obj sequence in the port
d) a new 00000 marker is written
e) port 1 is mapped back to #C0000
Here the bug appears: in ROM rev L & M '48s steps d) and e) are swapped !
Consequences:
1) If you've a writeprotected card in port 1, only the 00000 marker wasn't
written - because there's a good chance that the remainder of the card
isn't filled with zeros, this will cause the 'Invallid Card Data'
message each time you turn on your '48. On a rev M just run PINIT in
this case. The rev L don't have the PINIT command, so you should remove
the card in port 1 before storing something into the card in port 2
(causing that port 2 is mapped to #C0000 permanently)
2) If you've a writable, FREEd, card in port 1, additional to the above
effect the 00000 marker is written into port 1 - depending on the fill
level of port 1 this will cause at least a modification of one object.
There may be a lot of different effects caused by this - and there's a
good chance to loose memory if you access the modified data (eg. by
executing a modified library command or by restoring a corrupt backup)
3) If you've a writable, MERGEd, card in port 1, additional to the effects
described in 1), the 00000 marker was written to the system RAM - again
this may cause various suspicious effects, the most likely is to loose
RAM later or earlier...
4) The PINIT command on a rev M '48 will trash your card 1 too. It
initializes ports 1-33 by storing a small object into it and then
immediately deleting the object - the storing operation is performed
by the STO kernel... If you've a multiport card in poert 2, and execute
PINIT, a bunch of 00000s may be scattered all over card 1...
How to 'see' the bug:
Get two empty RAM cards, a memory scanner and a library. Plug in the cards,
and determine the size of the library w/ DUP BYTES SWAP DROP 2 * R->B,
assuming the result is #1A51, use the memory scanner to examine the address
#C1A51 (this is port 1) and make shure that there're no 0's. Now store the
library into port 2 w/ 2 STO. Launch the scanner again and take a look at
#C1A51 - if you see 00000, you got it. For beeing shure you can additionaly
remove the card of port 1, and take a look at #C1A51 again (this time port
2) - assuming that there wheren't any 0's before storing the lib, you won't
see the 00000 sequence...
