NOTE: This file was originallly included with ARUNZ09S. It is now pretty much obsolete but may still contain some useful information--H.G. Special instructions for version 0.9S and later (be sure to see revised notes at the beginning of the source code, ARUNZ.Z80): Generating a Type-4 Version of ARUNZ ==================================== CODEND does not work properly in a PRL file and thus cannot be used by the type-4 version of ARUNZ to determine the address at which to start allocating buffers. To get around this problem, the ARUNZ code tests to see if it is a type-4 program, and, if so, it uses the value of CODESIZE below as the amount of memory to assume for all code and data segments, including those in linked library modules. It adds this value to the starting address of the program to determine the address at which to start allocating buffer space. The proper value to use for CODESIZE can be determined from the message put out by the linker when it links the main code with the libraries. The value is the total data size, not the size of the code segment alone. If the value set in the equate below is not correct (or, more exactly, if it is too small), then the proper value can easily be patched in following the ASCII string 'SIZE' in the third record (second page) of the final type-4 COM file. It is also necessary to patch the 'load address word' in the type-4 program header of the ARUNZ code (not in the type-4 loader code). In type-3 programs this value is used by the command processor to determine the address at which to load the code. For type-4 programs, this value is used by the loader (invoked by the command processor) to calculate the address at which to start loading the binary image in high memory. The location where this value is stored can be found in any of the following equivalent ways: at offset 000Ah in the actual program header, at offset 10Ah in the type-4 COM file, or just before the 'SIZE' marker string mentioned above. The linker sets the load address word to 0100h for a PRL file. This is fine if the program does not allocate any buffers above the data segment. The type-4 loader will automatically use the larger of this value or the actual size of the program. ARUNZ needs memory above its own code. The value thus has to be the total amount of memory required to run ARUNZ, including its code segments, data segments, and all run-time buffers. Since the size of the type-4 loader is included in the calculation, an extra 100h has to be added as well. For reasons not yet clear to me, the value calculated this way is not always large enough. If it is too small, the program will produce an error message, but one can save some trouble by 'padding' the value a little. During assembly of ARUNZ, a report will be made to the screen of the total buffer requirements for the case of a standard MCL buffer. This value should be added to CODESIZE+100h and then rounded up to the next page boundary. The resulting value should be patched in right BEFORE the ASCII string 'SIZE' in the configuration area at the beginning of the program. The assembler will perform this calculation and report the result. This value can be used PROVIDED THAT THE CORRECT VALUE OF CODESIZE HAD BEEN PLACED IN THE SOURCE CODE. For example, in my formation of version 0.9S, the assembler reported a buffer requirement of 780h, and the linker (when making a standard type-1 COM file) reported that addresses 0100 to 16A2 were used. This means that CODESIZE should have a value of: CODESIZE = ( 16A2h + 1 ) - 0100h = 15A3h The value to put in the header before the 'SIZE' marker would be 15A3h + 780h + 100h = 1E23h rounded up to 1F00h I believe that this computation will be correct. ARUNZ does test for adequate memory and will report a TPA overflow if you have not used a large enough number here. For versions of ARUNZ set up for an extended MCL allocation (see below), the value must be increased further. Making a Version for Extended Multiple Command Line Buffers =========================================================== Version 0.9S introduces a new, experimental option. The Z34 command processor is already able to handle arbitrarily long multiple command line buffers. The ENV can only accommodate the description of MCLs with lengths up to 255 bytes, and this value has limited all Z-System utilities to date. Version 0.9S of ARUNZ has a patch point to allow the code to work with an MCL of any size. You would create such an MCL by allocating buffers in such a way that the memory immediately following the MCL as defined in the ENV is not used. Suppose, for example, that the MCL starts at DD00h and that no other buffer has an address in the range DD00h-DEFFh. This would allow for an MCL buffer area of 512 or 200h bytes. In this case, manual entry of command lines would still be limited to the length specified in the ENV, but command lines generated by ARUNZ would be limited to the full size of the MCL. Here are the steps you would follow to allow ARUNZ to process either very long script expansions or alias invocations with long commands pending in the MCL after the alias. The first step is to patch the word location after the identifier string 'MCLSIZE' in the code. Put here the number of command characters that the MCL can hold. This figure is 5 bytes less than the total size of the buffer allocated. In the example above the value would be 1FBh, and you would patch in bytes of FB and 01. This step alone is enough for the type-1 and type-3 versions of the code. For the type-4 version of the code, you have to change the load-address value. It should be increased from the standard value by the amount that the MCL length exceeds 100h. You can get the exact value by trial and error, since the program will report a TPA overflow if the value is too small, but it may be easiest simply to pad the value a little. I verified that this code works by setting up an NZCOM system with a 512-byte MCL buffer. I did this the quick-and-dirty way to save time. I configured NZCOM to have a 4-record user buffer. Then I edited the NZCOM.ZCM file to set the MCL address to that of the user buffer instead. This wasted the buffer space formerly taken up by the MCL, but it was the quickest thing to do. Once this system was running, I was able to process very long scripts and scripts with very long commands following them on the command line.