ROMCOPY DOCUMENTATION: ROMCOPY is an HP-71 LEX file that was made available to third-party software developers who wanted to create plug-in modules for the HP-71. ROMCOPY allowed software developers to emulate HP-71 roms, and to store the rom image on HP-IL mass storage to facilitate sending such images to HP, where such images were transformed into actual plug-in roms. This documentation discusses both the syntax of the ROMCOPY statement and the rom emulation procedure. Syntax of the ROMCOPY statement: To send a ROM or IRAM image to mass storage or to HP110/Portable Plus/PC computers running HPILLINK: ROMCOPY TO [] [;CHECKSUM=,.....] needed for 48K and 64K images [;CODESIZE=] [;ROMSIZE=] To get a ROM or IRAM image from mass storage or from HP110/Portable Plus/PC computers running HPILLINK: ROMCOPY [] TO [;ROMSIZE=] * [;CHECKSUM=,.....] * [;CODESIZE=] WARNING: THE CONTENTS OF THE DESTINATION IRAM WILL BE OVERWRITTEN, AND CANNOT BE RECOVERED. * While the CODESIZE and CHECKSUM options are accepted by ROMCOPY when copying a rom image into your HP-71, they are not used. Older versions of ROMCOPY / EPRMCOPY did not handle un-quoted strings reliably. Therefore, with older versions, it is a good idea to use quoted strings for both the port specifier and the filename/device specifier. ROMCOPY version 1E handles both unquoted strings and string expressions correctly. The CODESIZE option is supposed to specify the lenght (in bytes) of the file chain in the rom. The default is an integer multiple of the ROMSIZE parameter. Apparently, ROMSIZE was originally intended to specify the size of each ROM chip, which was originally 16K. CODESIZE would then be used to determine the number of rom chips required... Presently, CODESIZE does not seem to perform any useful function because ROMSIZE is used to specify the size of the ROM to be created or the size of the IRAM into which the rom image is being copied. If the file name is not specified, the file created or read by ROMCOPY will be called ROMIMAGE (default name). The port specifier is standard: :PORT(x), where x is the port # The device specifier is standard HPIL: :3 or :TAPE or :PCPORT The checksum is required to validate each 16K page of the ROM image. Each checksum value is the nibble offset from the start of the ROM module image. If the ROM image is 16K or less, then the offset is 6 (default). If the ROM image is 32K, the default , are 6,65534. If the ROM image is 48K, you must supply 3 values. See below for details If the ROM image is 64K, you must supply 4 values. See below for details In order for the checksums to be computed correctly, the nibble at the address specified by the offsets MUST be set to 0. Otherwise, you may not be able to read the rom image back into your HP-71. This helps make life somewhat difficult for people who try to make ROM images of commercial plug-in modules. (This requirement seems to apply to 48K and 64K rom images only). The ROMSIZE default is 16384 bytes for older versions. With version 1E, you do not have to specify ROMSIZE if the port in question is the now standard 32K. If you are using ROMSIZE with one of the 4K memories built into the HP-71, you MUST specify ROMSIZE=4096 whether ROMCOPYing a file into IRAM or creating a new rom image file. Similarily, if your IRAM is 64K, you must set ROMSIZE=65536. 64K IRAM are found in either the CMT EPROM BURNER or in the earliest versions of the HHP (Hand Held Products) card reader RAM units, which could only be accessed if you had a FORTH ROM in your HP-71, due to a bug in the HP-71 system code. Because of the high cost of burning masks for roms, ROMCOPY uses a checksum routine to verify the accuracy of the contents of the rom image. This checksum is not required by the HP-71 system, rather, it is required to verify the validity of the contents of the rom image file on mass storage. One of the major sources of problems with ROMCOPY is that, all too often, you will get the 'Verify Fail' error message when trying to load ROM files into your HP-71. There are several causes for this problem, one of which is trying to read ROM files created with early verisons of ROMCOPY LEX. Typically, the problem can be resolved by using ROMSIZE=32768 to specify the size of the destination IRAM. You should try to load the same file with the EPRMCPY LEX from CMT, or with older versions of ROMCOPY. If these approaches all fail, then try the RCOPYLEX file on SWAP11. RCOPYLEX is a version of ROMCOPY 1E where the eVerify error exit is bypassed - execution continues irreguardless of the results of the checksum computations. USE RCOPYLEX AT YOUR OWN RISK! BE SURE TO BACK-UP YOUR HP-71 BEFORE USING RCOPYLEX. CUSTOM PLUG-IN MODULE SIMULATION PROCEDURE: You can emulate a custom plug-in module by using IRAM, RAM that has been removed from main memory with the FREE PORT(x) instruction. Copy all of the files you want included into your custom module with the COPY statement, as follows: COPY [:] TO [name in ROM] :PORT(x) Once you have copied all the files you want into the IRAM, you can determine the size of your application by substracting the value of MEM(x) from the size of the IRAM, which can be easily determined with SHOWPORT. If the resulting codesize is greater than 32767, special checksum procedures are needed. See below. You generate a custom rom image by copying the contents of the IRAM to HP-IL mass storage, and then by copying the ROM image back into the IRAM. This insures that all BASIC line number references, sub-programs and user-defined functions are compiled. If the checksums are invalid, ROMCOPY will error out when you try to copy the ROM image back into IRAM. If the checksums are correct, then you must test your IRAM to make sure that the checksum bytes do not create conflicts. ROMCOPY will issue a 'Stmt Not Found' if there are unresolved line number references. You can identify the BASIC program that caused the problem with RENUMBER 1,1,1,1. (You must of course EDIT each program before you can RENUMBER it.) NOTE: You can compile your basic files in other ways, to include the following: 1) RENUMBER 1,1,1,1 each basic file 2) COPY the file (the program is decompiled if you edit or list the file). 3) RUN the file RESOURCE ALLOCATION & VER$: If your application requires new file types, special physical keycodes, LEX IDs, keyword token numbers, poll numbers, RESERVED RAM, system buffer numbers, GOSUB stack item types, system flags or message numbers, you must contact HP to obtain such resource allocations. It is strongly recommended that your custom module respond to the VER$ poll to indicate the presence and version of the software. It is recommended that you include both a VER$ poll handler and a copyright notice within the code of your application. SPECIAL CHECKSUM PROCEDURES: This section applies only to modules which are larger than 32767 bytes and/or to special cases which require that the checksum bytes be located at specific locations within the custom ROM. There is a checksum associated with each ROM chip in a ROM module. Each chip is 16384 bytes, and the checksum byte is set to the value needed to make the sum of each rom chip add up to 1, using wraparound carry. Each rom chip must contain one checksum byte. The HP-71 file structure in a custom ROM is a chain of files, starting at the nibble offset 8 from the start of the first chip. The files are consecutive with no space between files. See IDS volume I for a detailed explanation of HP-71 file structure. The first rom chip has unused space in the first 8 nibbles (4 bytes), at offset 6 from start of file. For applications that have more than 16384 bytes but less than 32767 bytes, the second checksum byte is placed in the last byte of the second rom chip. For applications that use more than 32767 bytes, there is no specific place for the checksum bytes that will work for all possible applications, although the bytes at offset 6 and the last byte of the ROM are usually available. The difficulty comes when you try to specify the checksum bytes for the rom chips that come between the first and last chips in the module. The following methods for reserving room for checksum bytes should be considered: KEEP IN MIND THAT THE CHECKSUM BYTES MUST BE ZERO BEFORE USING THE ROMCOPY UTILITY. - Add a DATA or TEXT file and put the checksum in the data portion of the file - If you do not care what the CATalog entries for one of the files looks like, put the checksum byte in the time or date creation field. - If there is a LEX file, reserve a byte within the file with CON(2) 0 or RTNSXM. These instructions could follow any GOTO, GOLONG, GOVLNG or other B.E.T. instruction. - In BASIC files, add comments with bytes to be used as checksum. HP suggests adding a line 1 ! Csum:# or 9999 ! Csum:# and gives the following addresses: HTD(ADDR$())+67 if the comment line is at the start of the file, and, if at the end of the file, HTD(ADDR$()+HTD(REV$(PEEK$(DTH$(HTD(ADDR$())+32),5)))+26 The value to supply to ROMCOPY is the
-. is defined as the address of the first file in the IRAM, - 8. Clear each checksum byte address with POKE DTH$(
),'00'. Note: finding the checksum byte address is difficult unless your application is written in assembly language. If you have trouble, store a unique, easy to identify ASCII string in the program or other type file, then use PEEK$ to locate the string in the IRAM. Good luck with ROMCOPY & RCOPYLEX!