ftg0673@tamsun.tamu.edu (Rick Grevelle) (04/06/91)
HACKIT is a library of utilities designed to facilitate hacking in the HP48SX. While a few of these routines actually have origins that can be traced back to the HP28S, the majority of them are relatively new. Prototypes to several of the routines have been extensively beta tested, and consequently is reflected in the material appearing here. A majority of these routines were written in SYSTEM RPL type fashion utilizing almost exclusively prefixed machine code to accomplish their intended results. Very little preexisting SYSTEM RPL has been utilized, and there are a few cases in which an existing prefixed machine routine could have been used in place of user written machine code, but was not. There are multiple reasons for having done this, however the primary concern was usually to minimize execution times rather than reduce memory consumption. There are a few individuals whose contributions and generousities have greatly affected this material, and who deserve to be recognized for their part. I'd first like to thank Jake Schwartz for all of his ideas and countless hours of collaboration. Equally important, thanks to Jan Brittenson for his technical support and detailed explanations of the 48's machine code. Thanks to Robert Ellis for his hardware expertise and patience. Also Jim Cloos for furnishing his CRC algorithm. Last, Alonzo Gariepy, for without his help, none of these programs would have ever been possible in the first place. Rick Grevelle HACKIT ============================================================================== Both of the machine routine algorithms found in these first two programs were originally used in similar schemes written for the 28S. Neither algorithm is mine, and were in fact used by HP in the 28. More recently they were utilized in the encoding schemes ->ASC, and ASC-> written by Wickes, who very well may have conceived them, considering the fact that he already has a great deal of code to his credit ->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 the SYSTEM FLAG -28 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 SYSTEM FLAG -29 is set, strings are treated as in-line machine code, whereby a code object would be the result. When flag -29 is clear one of two things happens depending on the string argument itself, and is explained in the following summary. IMPORTANT POINTS i) 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. ii) 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. iii) 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. iv) 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 on the of an ->ASC encoded object that has been altered in order to get ASC-> to work. ->ASC, and ASC-> were an effort to provide a safe means of transferring data, and not for hacking. v) 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. SCRC Calculates the checksum on a string of hexadecimal characters as if they were in immediately executable form. So that an object converted to its ASCII form using ->ASCI will have the same checksum when SCRC is used on the ASCII string as it would of had before it was converted using the BYTES command. As in the ASCI-> program, spaces and newline carriage characters are ignored. 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. 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 to determine the number of nibbles to poke, and is in no way dependent upon the current wordsize returned by RCWS. OUT-> Multifunctioning OUT-> encompasses several of the objects on which OBJ-> will not work. ALG->, and PRG-> are analogous to LIST->, only they are intended to function on algebraics and programs rather than lists; OUT-> functions on all three of these. XLIB-> has also been included here; it decomposes visible and hidden XLIBs into their library and command numbers. ARR-> was also included here; it functions identically to ARRY->, but will work on an array of any type including strings, algebraics, lists, etc. ->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. ->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. ->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. RCLDR Recalls the current directory to the stack in exploded format, after which the ->DIR scheme could be used to pack the stack results back up into a directory. 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. O / \/ /\ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ O \ %%HP: T(1)A(D)F(.); "04B201611060841434B4944560EB40EF0000000E5F00C00008EB4E00D9D20119 20EB40090770B21308EB4F00D9D2088130F128039916B9F06CCC804E76132230 4E7614525639150493262B1614932651B50B21308EB4010D9D20FA450881303C 37052330AD2A1A2170D9D2029E20EB43108A126CB91629E20EB4F00B21309427 043370D6450B21308EB4110D9D20FA450881303C37052330AD2A1A2170D9D202 9E20EB43108A126CB91629E20EB4F00B2130942704337095450B21308EB4210D 9D20FA450881303C37052330AD2A1A2170D9D2029E20EB43108A126CB91629E2 0EB4F00B2130942704337054450B21308EB4310D9D207E1263991629E20EB421 0112263991629E20EB41102D1263991629E20EB4010B21308EB4410D9D205D55 0D0040C1C16CAF06FEF30083162A170E342405E70D9D2088130F1280399169EB 5088130CCC804E761322304E7614525639150493262B16149326B21304B25639 15051B503223099E70EE170D9D20AD2A18DA16D9D209AF168DA1667E7075660B 213029E20EB4310EF116FED30F6E30D2E300831635316E9330FED30CA130B213 05E17062726F6E30FED30954506AE42B2130CCD20CC0008F146608FB9760D814 7C2134168174147C4C21C413717706D2305D7CD14B31A0962A43102962143114 9EED13103B6A4A531909E61515006910B6A31509E6D330AA0A1500180E71C1CD 56A183DB14418434CCD20144071361448D341508F2D7608DB8F018EB4D00D9D2 05AA812BF819FF30D9D20AEC81881309C080A2170650115B826A21706501129E 20EB4410B2130B2040D9D20F4180A2170650118813029E20EB4410B213058040 D9D2099E70B3A1661050B2130B21308EB4C00D9D20E1A81D9D20FEF30A5D8012 681DA916FBD812A170E3424881303E28059230FED30EF116A36812FA308C170F BD81B2130B21308EB4B00D9D20FDE8199040D9D20AEC8132230AEC813223005E 70B2130ECD46D9D201D3F405E70B2130B21308EB4A00D9D2043C8154450B2130 8EB4900D9D20ECE819FF30D9D20AEC818A816D9D2041E8091870B2130F6E30C4 1302C23038D30A21702CC81FEF3032230BD3708131605391A2170D9D209AF168 DA1667E7075660B2130122703F21653026A21702BC819EB504B2563915051B50 3223012270FED30300405A3705D550D0040C1C162C23056316FED30954506AE4 2B2130B21308EB4800D9D205AA81D9D202BF819FF30DEE3212040D9D209BC260 3FD16B436B2130FEF302BC81B2130AD3911E136353369B191C41302C230FED30 38D30A21702CC81CCD20F71008F146608FB97601001438FC1830DB10A3441000 CBC7C7C3174147137143135104118CE45506143130D814211C8A2018F2D7608D 7BC818F91030184136E9C35908D066501740757B8FC455011B5F013706DB10B8 4A8F8DA604ED136109135348E92014517411B13418413614517411C14517411A 145D71B97507142130142130174CF4F08F878301455DE118D707CF4331341841 4213606D81308F91030184D9136E91648FC07605AC8F2D760118C3DAC6C6C213 3CA1311191458D94150B21308EB4700D9D2043C81D6450B21308EB4600D9D20E CE8171040D9D20BCB73122702C230D1730C0726433709A53092591B213012040 379C1F3040379C194040379C158040D9D20CCC80FBD8132230FBD8132230B213 0B21308EB4500D9D2008A81D9D202BF818AB46D9D2030A50322305D550226500 8316C1C16322308A81668F0129E20EB4510B4826B2130ECD46D9D2030A50B213 0FEF302BC81B21302C23061650CCD20130008FD5F30068FB9760147134169131 078FC07608D3415044230B21308EB4400D9D20ECE81D5040D9D2075660CCD20A 4000132100147134164146818FA580D0164D2156113615211341501201101321 42164808CB21309FF30D9D202BF814CD46D9D20AEC81FD5502C230F6E30C1C16 5923030A5059230CCD20A50008FD5F30068FB976014713416913107CED5AE015 B03103A6A31939EA903170A6A148161170CD56D8D34150B2130B2130B21308EB 4300D9D20FDE81ECD46D9D2030A50CCD20570008F146608FB976014713416A15 67AF51801564130152780DF91052160BF4B4651F80CF0D40E910BDBF41605FE1 32E4248FC2245142164808CB2130B21308EB4200D9D20ECE81D0040D9D208813 0636508A81644230CCD206E0008F146608FB9760D8143131179D0100CDD014B3 1A0962E631029625631149EE913103B6A4D631909E6466510B6A31509E64530A A0A7650D230F0EF2D7331801D0CF480CA68FF118F61087C20100171CD508238F F2245142164808C8F2D7608DB8F01101FC1180EF6121FE0EF21110EFE0132230 63650FBD81ED2A2EF9A2B2130B21308EB4100D9D20ECE81D0040D9D205D55022 65008316C1C16322308A816852301114048735A2170D9D20881307104038D30A 217068F0166F6088130616507104038D30A217068F0130040C9B26AD2A1B3A16 75660B213029E20EB4510B9F06B2130B21308EB4000D9D205AA81D9D20701404 873508316CB916D9D20D9F8161DC138E51FEF30D9D200CA30E0F06B2130B2130 32230A2170D9D20AD2A18DA16D9D20FD55035040C1C1612040CCD20720008F14 6608FB9760CCD81431301691746E50B2130D9D208813020950FD5502C230F6E3 0C1C1632230CCD20C50008F146608FB9760CCD8143130169174143131AE015B0 3103A6A31939EA903170A6A148161170CD56D8D34150B2130B9F06B2130B2130 B2130E4A2037000C9EFF1DDFFF8CFF6EBFFEBAFF5E9FFD49FFD29FFB17FFB06F FBE5FFF85FFA15FFC64FF360FFE70FF0D0FF331FF691FF9F1FF442FFC63FFE4A 2006100000000000000000640006B00000000000000000000000000000000000 000000000000000000000005C000403534253420040355454B430040055454B4 4004005F4B45450040F45545D860040D814C47470040D814252580040D844942 590040D8052574A0050D8143534940005014353494D810050D885C49424B0050 2534C44425C00502534C49424D00B400014000AC0002C000AB0002B000AA0002 A000A900029000A800046000A500005000582C57AF"
akcs.burhan@hpcvbbs.UUCP (burhan h. afandi) (05/17/91)
could somebody please tell me how to convert this string of hex numbers to binary, and once in binary form how to run it on my hp-48. i was told to use asc-> program written by wicks to convert it to binary, but i cant find this program anywhere. could someone please help me. thanks Burhan H. Afandi