jhawk@panix.uucp (John Hawkinson) (06/24/91)
Someone posted a new HACKIT library last week, and I was wondering if they could post the docs? (I never had the original.) Thanks in advance. -- -- John Hawkinson jhawk@panix.com
frechett@spot.Colorado.EDU (-=Runaway Daemon=-) (06/24/91)
In article <1991Jun24.032210.18224@panix.uucp> jhawk@panix.uucp (John Hawkinson) writes: >Someone posted a new HACKIT library last week, and I was wondering if >they could post the docs? (I never had the original.) Thanks in advance. > >-- >-- >John Hawkinson >jhawk@panix.com Normally, I would have just sent a copy off to this person but I can't mail to that address successfully. So here it is.. I just sent through my archives and Globbed together the various Hackits posted before into one with all the Docs and the LIB itself so here it is. ian -=Runaway Daemon=- DESC: Excellent set of hacking routines.. with Docs This is an enhanced version of the HACKIT thing. It includes several new features which further facilitate hacking in the 48, and are as follows: o Multifunctional PEEK will now allow the normally hidden 32k of ROM to be peeked. When flag 14 is clear the 32k of memory between #70000h and #7FFFFh is RAM. When the flag is set this is shifted to #F0000h through #FFFFFh, and #70000h through #7FFFFh becomes what was previously covered by RAM; this configuration is identical to that of the built in memory scanner. o Bank switching capabilities have also been incorporated in the SEEK scheme, functioning exactly as described in the PEEK routine. o DIR-> is a new addition to the OUT-> command; it allows a directory in level 1 to be decomposed on the stack in to its constituent parts. Due to this change, it's not necessary to include the RCLDR scheme in the library as it was added to the original HACKIT post only after all first attempts to produce a successful DIR-> had failed. o Flags -28 and -29 have now been combined into one flag, 15. This flag affects the way in which the ->ASCI, and ASCI-> routines handle code objects. Currently a ->STR, and STR-> scheme is being conceived that will provide a superior editing scheme for queer objects. At the risk of being reiterative, I'm including an improved version of the documentation which appeared in the original posting of this library. It should be a bit more articulate, and contain examples for those whose time is allowing. Much work still remains to be done regarding the completely bullet proof hacking library, but since all the fun seems to be in getting there, hopefully it will take a long time. A final word of caution; do *not* attempt to implement a bank shift using either PEEK, or SEEK, if this library is stored in port 0, or anywhere in the address space being displaced. This means both of the 32k banks that are affected by setting flag 14 are off limits, as far as this feature is concerned, for the storing of this library. Should there be any question about this, or anything else, feel free to call, or write, and I shall be glad to provide any answers of which I might be capable :-). Rick Grevelle (409) 774-1169 ftg0673@tamsun.tamu.edu HACKIT ============================================================================== HACKIT is a library of utilities designed to facilitate hacking in the HP48SX. The fourteen programs it contains were conceived for two fundamental purposes: o Exploration, documentation, and accessing of the machine code, and RPL operating system contained in the 48's vast ROM. o Construction, and manipulation of the various object types not supported by the 48's editor, user language commands, functions, or operations. ->ASCI This is a generalized binary-to-ascii conversion scheme that returns a string of hexadecimal characters which are the equivalent internal representation of the argument. When USER FLAG 15 is set both the prolog and the length of code objects are truncated meaning that the result string contains in-line machine code only. When this flag is clear, which is the default, truncation does not occur. All other object types are unaffected by the flag setting. ASCI-> Reversing the result of the previous routine is made possible with this scheme, which converts ascii-to-binary, taking as its argument a string of hexadecimal characters. When USER FLAG 15 is set all strings are treated as in-line machine code, whereby a code object would be the result. When flag 15 is clear one of two things happens depending on the string argument itself, and is explained in the following summary. IMPORTANT POINTS o The above routines were intended to provide a means for *toggling* stack objects back between their internal string representation and immediately executable form, which means ROM objects must be dealt with differently. An important attribute associated with these two schemes is their ability to differentiate between ROM and RAM objects. o When an argument taken by the ->ASCI routine is a ROM object, a character string representing the five nibble address where that object is located in ROM is returned. Strings containing only five characters that are used as arguments for ASCI-> are treated as pointers; solitary prologs are not permitted though (i.e. "D9D20", "C2A20", "11920"). Future versions should be more than capable of dealing with such complexities as this. o Spaces and newline carriage returns are allowed in strings that are to be converted by ASCI->. This helps to alleviate some of the confusion when looking at long strings of hexadecimal characters in that spaces can now be used to separate groups of characters, and newline carriage returns to segment the string into several lines when editing. o Any object encoded using ->ASC can be unencoded using ASCI->. There's no longer a need for these silly schemes to delete newline carriage returns, or calculate a new checksum to tack onto an ->ASC encoded object that has been altered in order to get ASC-> to work. ->ASC, and ASC-> were written to provide a safe means of transferring data, and not for hacking. It is therefore not recommended to use these two schemes in place of ->ASC, and ACS->. o ASCI-> performs equally well on strings of odd number lengths because the RPL segments of the program correctly utilize the block allocate routine at #61C1Ch. But because of its very nature, it's still quite possible to suffer a memory loss from abusing this routine; so be careful. Example: Construct the DUP command from it ASCII string representation. _________________________ _________________________ |{HOME} | |{HOME} | |-----------------------| |-----------------------| |4: | |4: | |3: | :3: | |2: | |2: | |1: "78BF1"| |1: DUP| |### ### ### ### ### ###| |### ### ### ### ### ###| ------------------------- ------------------------- 1) Enter the string "78DF1". 2) Implement ASCI-> to obtain the command DUP. SCRC Calculates the checksum of a string of hexadecimal characters as if they were in immediately executable form. So objects which have been converted to their internal hexadecimal character string form (ASCII) using ->ASCI will have the same checksum when SCRC is used on the ASCII string, as they would have had in their binary form using the BYTES command. This allows queer objects such as libraries and backups that contain checksums which do not include the complete data structure to be altered, or even constructed from scratch, in the 48. So for an example a trivial backup object will be built utilizing SCRC, ->ASCI, and the ASCI-> routines. Example: Build a backup object named "Hex" containing the hexadecimal integer, # 123456789ABCDEF0h. o Construct the backup object's appropriate name. _________________________ _________________________ |{HOME} | |{HOME} | |-----------------------| |-----------------------| |4: | |4: | |3: | |3: | |2: | |2: | |1: 'Hex'| |1: "84E2030845687"| |### ### ### ### ### ###| |### ### ### ### ### ###| ------------------------- ------------------------- 1) Enter the name 'Hex'. 2) Implement ->ASCI on the name. _________________________ _________________________ |{HOME} | |{HOME} | |-----------------------| |-----------------------| |4: | |4: | |3: | |3: | |2: | |2: | |1: "30845687"| |1: "3084568730"| |### ### ### ### ### ###| |### ### ### ### ### ###| ------------------------- ------------------------- 3) Edit the string to delete 4) Concatenate "30" by using the first five characters. the plus (+) key. o Prepare the backup object's contents for concatenation. _________________________ _________________________ |{HOME} | |{HOME} | |-----------------------| |-----------------------| |4: | |4: | |3: | |3: | |2: "3084568730"| |2: "3084568730"| |1: # 123456789ABCDEF0h| |1: "E4A20510000FEDCBA..| |### ### ### ### ### ###| |### ### ### ### ### ###| ------------------------- ------------------------- 1) Enter the integer data. 2) Implement ->ASCI once again. o Make final preparations for checksumming. _________________________ _________________________ |{HOME} | |{HOME} | |-----------------------| |-----------------------| |4: | |4: | |3: | |3: | |2: | |2: "3084568730E3A2051..| |1: "3084568730E4A2051..| |1: "33000"| |### ### ### ### ### ###| |### ### ### ### ### ###| ------------------------- ------------------------- 1) Concatenate the previous 2) DUP the result string, and two result strings using use SIZE to obtain its size. the plus (+) key again. Add 15 to the size, convert the result to a hexadecimal number, and enter backwards as a five character string. _________________________ _________________________ |{HOME} | |{HOME} | |-----------------------| |-----------------------| |4: | |4: | |3: | |3: | |2: | |2: "330003084568730E4..| |1: "330003084568730E4..| |1: "119200"| |### ### ### ### ### ###| |### ### ### ### ### ###| ------------------------- ------------------------- 3) Perform a SWAP, and using 4) Append the string "119200" the plus (+) key, prepend to the end of the string, the length onto the front DUP the result, and using of the string. SCRC calculate the object's proper checksum. o Make final preparations for coverting the string. _________________________ _________________________ |{HOME} | |{HOME} | |-----------------------| |-----------------------| |4: | |4: | |3: | |3: | |2: "330003084568730E4..| |2: "26B20"| |1: "0B41"| |1: "330003084568730E4..| |### ### ### ### ### ###| |### ### ### ### ### ###| ------------------------- ------------------------- 1) Enter the four hexadecimal 2) Enter the prolog for the characters of the checksum backup object backwards, backwards in a string, and and perform another SWAP. append this to the string for which the checksum was calculated. _________________________ _________________________ |{HOME} | |{HOME} | |-----------------------| |-----------------------| |4: | |4: | |3: | |3: | |2: | |2: | |1: "26B20330003084568..| |1: Backup Hex| |### ### ### ### ### ###| |### ### ### ### ### ###| ------------------------- ------------------------- 3) Prepend the prolog using 4) Convert the string using the plus (+) key one last ASCI-> to its binary form. time. SEEK Appearing first in his Processor Notes, SEEK is in fact a modified version of Alonzo Gariepy's FIND routine. SEEK was specifically modified to run in the 48; it's one third the size of the original version for the 28, and should run a bit quicker too. Alonzo's predominately register, rather than memory oriented algorithm remains unchanged. Recall the overall increase in speed was only about 10% over that of the brute force approach, which he attributed to an increased time spent in the looping structures. Because it demonstrates several programming features specific to the 48, I've taken the liberty of renaming the routine. The way to use this program is to specify a memory pattern and a place to start looking. A memory pattern can be sequence of up to fifteen nibbles, and a one nibble length (one minus the number of nibbles in the pattern). An application for SEEK could be to locate the occurrences of the instruction 808C in memory. To do this enter # C8083h in level two, and a starting place such as # 0h. All that remains to be done is to implement SEEK, and to continue doing so to find any subsequent instances. This is because the result returned will be a binary integer which is the address one higher than where the pattern exist in memory. IMPORTANT POINTS o Bank shifting capabilities have been incorporated into SEEK, allowing the normally hidden 32k bank of ROM to be searched. With USER FLAG 14 clear, the 32 kilobytes of memory between #70000h, and #7FFFFh, is RAM. Setting flag 14 shifts the RAM to #F0000h through #FFFFFh, and reconfigures what was previously hidden ROM in its place. o This version does not stop until it finds an instance, or scans the entire address space. So even though the routine is fast, due to the size of the 48's address space, matching certain patterns could take several seconds. Example: Determine the first occurrence of the ARRAY prolog, # 029E8h, in the normally hidden 32k bank of ROM. (flag 14 set) _________________________ _________________________ |{HOME} | |{HOME} | |-----------------------| |-----------------------| |4: | |4: | |3: | |3: | |2: # 29E84h| |2: # 29E84h| |1: # 70000h| |1: # 72001h| |### ### ### ### ### ###| |### ### ### ### ### ###| ------------------------- ------------------------- 1) Enter the bit pattern with 2) The result returned is the the number of nibbles minus one higher than where the one, and the address where actual pattern was found. to begin searching. PEEK Speed is still an essential attribute of this dual functioning PEEK. Only the variable length version will slow slightly when large result strings hundreds of characters long are returned. The routine is smart enough to know which of the PEEKs to implement based on the arguments it's given. When string results are preferred, level two should contain a binary integer that's the address to be peeked, while level one should be a real number representing the length of the result string. The bank shifting features as described in SEEK scheme are also available in this version of PEEK; an example follows. Example: Using PEEK and ASCI->, recover the message array from the hidden ROM found in the previous example. (flag 14 set) _________________________ _________________________ |{HOME} | |{HOME} | |-----------------------| |-----------------------| |4: | |4: | |3: # 29E84h| |3: | |2: # 72000h| |2: # 29E84h| |1: 641| |1: Array of String| |### ### ### ### ### ###| |### ### ### ### ### ###| ------------------------- ------------------------- 1) Subtract one from the above 2) Now implement ASCI-> on the result, enter the number of result to obtain the ARRAY. nibbles to be returned, and implement PEEK. POKE Complimenting PEEK is this dual functioning variable length POKE scheme which will accept either a string of hexadecimal characters, or a binary integer for the level two argument that represents the data to be poked. Level one should be a binary integer that is the address to poke. It is important to note that when the level two argument is a binary integer, the wordsize of that specific integer will be used to determine the number of nibbles to poke, and isn't in any way dependent upon the current wordsize returned by RCWS. OUT-> Multifunctioning OUT-> encompasses several of the object types on which OBJ-> will not work. In addition, and analogous to the LIST-> command, ALG-> and PRG-> are intended to function on algebraics, and programs. ARR-> functions identically to ARRY->, but works on all the various array types such as the array of string, algebraic, list, etc. DIR-> decomposes a directory that is in level one into its constituent parts. XLIB-> has also been included; it decomposes visible, and hidden XLIBs into their library and command numbers. Example: Decompose the Array of String obtained in previous example into its constituent parts. _________________________ _________________________ |{HOME} | |{HOME} | |-----------------------| |-----------------------| |4: | |4: "Try To Recover Me..| |3: | |3: "Replace RAM, Pres..| |2: # 29E84h| |2: "No Mem To Config ..| |1: Array of String| |1: { 16 }| |### ### ### ### ### ###| |### ### ### ### ### ###| ------------------------- ------------------------- 1) Using the array obtained 2) Recompose the array again in the previous example, by using the ->ARR routine. implementing OUT-> will The result will look like reveal the strings. that of frame 1). ->ALG Be careful with this one; the stack arguments must be in strict RPN order. As before, ->ALG is analogous to ->LIST, only the result is an algebraic, rather than a list. ->ARR This is my version of ->ARRY; it will build an array of any kind providing all stack arguments are of the same type. (i.e. strings, reals, algebraics, etc.) It functions identically to ->ARRY, except that real and complex numbers can't be mixed. Level one can be either a real number, a list containing a real, or a list containing two reals that is the size the resulting array is to be. ->DIR Builds a directory from the stack on the stack. Level one must contain a real which is the total number of variables that the directory is to contain, level two a global name, and level three the contents of that global name. Because the entire process utilizes dynamic RAM, it is relatively fast for moderately sized directories, but slows substantially on very large ones. Using both the DIR-> feature found in the OUT-> command along with this routine, a directory on the stack can be effectively toggled between its constituent parts, and its composite form. ->PRG Functions identically to ->LIST, only the result is a program, and not a list. ->XLIB Builds an XLIB from two stack arguments. Level two can be either a real number or a binary integer that's the number of the library to which the XLIB belongs. Level one must be the same argument type as level two and should be the command number of the desired XLIB. ADDR Returns the address where the following stack arguments are located in memory: any ROM object, any XLIB belonging to a library stored in a port, any TAGGED that's either a BACKUP object or a LIBRARY stored a port. One final attribute associated with ADDR that merits mentioning, regards those XLIBs that belong to the three intrinsic ROM libraries with a link table. This routine can just as easily locate these address, as it can those in port memory. Even if the memory location happens to be that of the hidden ROM, ADDR will determine its address. RCLIB This multifunctional routine is to a library what RCL is to a directory. RCLIB will recall a library as a fully operational directory. All that is necessary to do is to put either the library's name or (real) number in level one. Again this is slowed greatly on very large libraries. RCLIB will work on any library including ROM (i.e. 2, 240, 1792). Finally, the contents of any library's XLIB can be recalled to the stack; simply put the appropriate XLIB in level one, and the result will be comparable to using RCL on variable stored in a directory. New version posted here.. ---- HackitIII Date: 20 Jun 91 23:30:05 GMT A New Version of HP48 HACKIT: ASCI-> Accepts Strings With Comments This is being posted for Rick Grevelle. Below is a new version of the HACKIT library with a significant step forward. Now, when preparing strings of hex nibbles for use with ASCI-> (to build the various types of HP48 ob- jects), one may include comments in a manner similar to those in regular HP48 program objects. Strings of nibbles containing not only spaces and carriage returns but also embedded comments which fall between a leading "@" symbol and a line-terminating carriage return are now handled like strings containing only nibble characters 0 through F. For example, a simple RPL object to contain the ROM number 1 can be represented by the the string "D9D209C2A2B2130". (The string "9C2A2" by itself would also suffice, but we are including the "begin RPL" and "end marker" addresses here to simply embellish the example.) Passing "D9D209C2A2B2130" as an argument to ASCI-> will yield a 1. In addition, this version of ASCI-> will also accept a string like the following: "D9D20 @ Begin RPL 9C2A2 @ 1 B2130 @ End Marker" This means that system RPL code developed on PC screens may be commented, with the source code available directly for HACKIT. It also means that HACKIT can accept input virtually identical to the output of Voyager (if the "@" signs are added to each commented line). Now, HP's PDL becomes a valid development platform for system RPL code. Below is the HACKIT code in ASC-> format. Jake Schwartz %%HP: T(1)A(D)F(.); "04B20B941060841434B4944560EB44100000000D61000E010E4A20E510000000 0000000000640003C00000000000000000000000000000000000000000000000 000000000003C000403534253420040355454B430040055454B44004005F4B45 450040F45545D860040D814C47470040D814252580040D844942590040D80525 74A004014444425C0050D8143534940005014353494D810050D885C49424B005 02534C49424D00C3000230008C0000C0008B0000B0008A0000A0008900009000 88000550005800005000E4A2037000570001D100CE20042400B15006E6005080 07F8001290092B0043C00A4C00C9C00B8E0082F00C3F0078F003EF00F3010B90 10FD010702108EB4000D9D205AA81D9D20580408773508316CB916D9D20D9F81 61DC138E51FEF30D9D200CA30E0F06B2130B213032230A2170D9D20AD2A18DA1 6D9D20FD55035040C1C1612040CCD20720008F146608FB9760CCD81431301691 746E50B2130D9D208813020950FD5502C230F6E30C1C1632230CCD20C50008F1 46608FB9760CCD8143130169174143131AE015B03103A6A31939EA903170A6A1 48161170CD56D8D34150B2130B9F06B2130B2130B21308EB4100D9D20ECE81D0 040D9D20FD55044E52592309FF302A170261628DF063223039150E9016226502 C2304EC308C170D0040E623079E60CCD20500002265008316C1C16322308A816 852305804087735A2170D9D20881307104038D30A217068F0166F60881306165 07104038D30A217068F0130040C9B26AD2A1B3A1675660B213029E20EB4510B9 F06B2130B21308EB4200D9D20ECE81D0040D9D2088130636508A81644230CCD2 06E0008F146608FB9760D8143131179D0100CDD014B31A0962E6310296256311 49EE913103B6A4D631909E6466510B6A31509E64530AA0A7650D230F0EF2D733 1801D0CF480CA68FF118F61087C20100171CD508238FF2245142164808C8F2D7 608DB8F01101FC1180EF6121FE0EF21110EFE013223063650FBD81ED2A2EF9A2 B2130B21308EB4300D9D20FDE81ECD46D9D2030A50B704087735DA916CCD20C0 0008446010CCD20DA0008548F146608FB97601478643210810134FFFFF8FD7FB 01182430F2011113416A1567AF51801564130152780DF91052160BF4B4651F80 CF0D40E910BDBF41605FE132E4100864908F741C0248FF2245142164808CB213 0B21308EB4400D9D20ECE81D5040D9D2030A50B704087735DA916CCD20710008 F146608FB97606920CCD20860008548F146608FB9760D680D489750844864811 002034FFFFF8FD7FB01101301527100864908F741C02F8FF2245142164808CB2 1309FF30D9D202BF814CD46D9D20AEC81FD5502C2308A816A2116F6E30C1C163 3F0630A50B704087735DA916CCD20C00008446010CCD20990008548FD5F30068 FB9760147864D21021080710934FFFFF8FD7FB0119061182430F201121341690 7135D8CDAE015B03103A6A31939EA903170A6A148161170CD56D864908F741C0 8D34150B2130B2130B21308EB4500D9D2008A81D9D202BF818AB46D9D2030A50 32230FD55044E52592309FF302A170261628DF063223039150E9016226502C23 04EC308C170D0040E62305D5502265008316C1C16322308A81668F0129E20EB4 510B4826B2130ECD46D9D2030A50B2130FEF302BC81B21302C23061650CCD201 30008FD5F30068FB9760147134169131078FC07608D3415044230B21308EB460 0D9D20ECE8171040D9D20BCB73122702C230D1730C0726433709A53092591B21 3012040379C1F3040379C194040379C158040D9D20CCC80FBD8132230FBD8132 230B213003B46D9D20FEF30083162A170E34240D971EE170D9D20881303E2808 DF06FED308DF068DF06B21305E17044230FBD81B2130B21308EB4700D9D2043C 81D9D208A8162AC81D6450B2130B21308EB4800D9D205AA81D9D202BF819FF30 DEE3212040D9D209BC2603FD16B436B2130FEF302BC81B2130AD3911E1363533 69B191C41302C230FED3038D30A21702CC81CCD20F71008F146608FB97601001 438FC1830DB10A3441000CBC7C7C3174147137143135104118CE45506143130D 814211C8A2018F2D7608D7BC818F91030184136E9C35908D066501740757B8FC 455011B5F013706DB10B84A8F8DA604ED136109135348E92014517411B134184 13614517411C14517411A145D71B97507142130142130174CF4F08F878301455 DE118D707CF43313418414213606D81308F91030184D9136E91648FC07605AC8 F2D760118C3DAC6C6C2133CA1311191458D94150B21308EB4900D9D20ECE819F F30D9D20AEC818A816D9D2041E8091870B2130F6E30C41302C23038D30A21702 CC81FEF3032230BD3708131605391A2170E3424D9D209AF168DA1667E7075660 B2130122703F21653026A21702BC819EB504B2563915051B503223012270FED3 0300405A3705D550D0040C1C162C23056316FED30954506AE42B2130B21308EB 4A00D9D2043C8154450B21308EB4B00D9D20FDE8199040D9D20AEC8132230AEC 813223005E70B2130ECD46D9D201D3F405E70B2130B21308EB4C00D9D205AA81 AD2A139916CCD20220008FB9760143248FC2245142164808C8A12639916CCD20 3B0008FB9760143130167D01523D8182D015231B9D707146AB7162A3F4B61469 32D09B2E516759E16214613416C1428A844136CA130E5D4C4C4C01641468BE72 136CA1301468AA71CA248FC2245142164808C8F2D7608DB10506222639916D9D 20881307CE50D9D20C435645DB05F290D9D208535645DB09FF304635645DB030 0402FF40B21302BAA0B9F06E9016B9F0655C26A21702FF40B2130B9F062A170E 34248813028BA08DA16D9D20CAF064F912C121679B308E8160CA30A2116CC950 18A30B2130A00508C170B21302BC81B21308EB4D00D9D205AA812BF819FF30D9 D20AEC81881309C080A2170650115B826A21706501129E20EB4410B2130B2040 D9D20F4180A2170650118813029E20EB4410B213058040D9D2099E70B3A16610 50B2130B2130D9D20119208850090770B2130D9D2088130F128039916B9F06CC C804E761322304E7614525639150493262B1614932651B50B2130D9D20FA4508 81303C37052330AD2A1A2170D9D2029E20EB43108A126CB91629E20EB4F00B21 309427043370D6450B2130D9D20FA450881303C37052330AD2A1A2170D9D2029 E20EB43108A126CB91629E20EB4F00B2130942704337095450B2130D9D20FA45 0881303C37052330AD2A1A2170D9D2029E20EB43108A126CB91629E20EB4F00B 2130942704337054450B2130D9D207E1263991629E20EB4210112263991629E2 0EB41102D1263991629E20EB4010B2130D9D205D550D0040C1C16CAF06FEF300 83162A170E342405E70D9D2088130F1280399169EB5088130CCC804E76132230 4E7614525639150493262B16149326B21304B2563915051B503223099E70EE17 0D9D20AD2A18DA16D9D209AF168DA1667E7075660B213029E20EB4310EF116FE D30F6E30D2E300831635316E9330FED30CA130B21305E17062726F6E30FED309 54506AE42B2130CCD20980008F146608FB9760CCD81431301691741431311791 4B31149EED13103B6A4B331909E62315006910B6A31509E6E130AA0A15001601 71CD5AB8D341508F2D7608DB8F0199A7340C"