From: Detlef Mueller Subject: STOFIX Library v1.1 --> only intended for GX version L & M 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 any revision HP48 but is only useful in rev L & M 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 a port other 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 (-2 STOFI on a GX, -\|^ 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 multi-port card, use [pinit] Big description --------------- There's a *really* bad BUG which appears in ROM rev L & M HP48GX's. 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 access requests. If you've plugged in two cards, and store a library into, say, port 2 (with 2 STO - this may be a 32k, 128k, 256k, 512k 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 port 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... Bye, 8-Detlef