rename to remove leading character: cmd /v for %i in ("&*.*") do set name="%i"& ren "%i" !name:~2,-1! correct listing files from ASMB: for %i in (*.lst) do sed -r -e "/^1 /n;/(^ )|(^[^ ])/s/^(.+)$/ \1/" %i > %~ni.txt process: - gen tsb system large enough (21MX, 7920) - create Z101, Z102 - load Z101, Z102 - write BASIC program to copy all source (listing) files to device (CAT to get list of files, edit into DATA statements) (or use SYSTEM and CAT command to obtain list of files) - run program to output all sources files to MT image - load MT into RTE-IVB source files (:ST,8,&nnnnn,AS) - assemble all files (:RU,ASMB,&nnnnn,6,-) - examine listing for errors - correct source file errors (no ASMB statement, END w/seq number) - dump source files to tape (:RU,SAVER) - modify ASMB for RAM, EQU, =L semantics - dump ASMB, XREF relocatables to tape (:RU,SAVER) - load ASMB, XREF into RTE-6/VM (:RU,READR) - read sources into RTE-6/VM (:RU,READR) - link ASMB, XREF (:RU,LOADR) - assemble all files (:RU,ASMB,&nnnnn,6,-) - run XREF in sections for TSB (:RU,XREF,&TSB,6,1,LH) - dump absolute binaries to paper tape (:DU,!-----,4,BA) - dump relocatable binaries to two paper tapes (:DU,%-----,4,BA) - dump absolute files from MCP tape to paper tape (:DU,8,4,BA / :CN,8,FF) - copy MCP file 2 and 3 to separate mag tapes (:CN,8,FF / :DU,8,9 / :DU,8,9) - edit mag tapes to replace ID records with tape mark + gap (Codewright) - copy 2 relocatable mag tapes to paper tapes (:DU,8,4,BR) - load DCODE source from paper tape into DOS-III (:ST,S,5,&DCOD) - load RBMSA source from paper tape into DOS-III (:ST,S,5,&RBMS) - modify DCODE to get parameters from run command - modify RBMSA to clear H/C bit on external MRG instructions - compile and load DCODE (:PR,ALGOL / :PR,LOADR) - assemble and load RBMSA (:PR,ASMB / :PR,LOADR) - create batch files for DCODE and RBMSA runs - copy batch files to mag tapes (:ST,S,8,nnnnn) - run DCODE on two absolute paper tapes MCP/reconstructions (:BA,8) - run RBMSA on four relocatable paper tapes MCP/reconstructions (:BA,8) - compare output listings - iterate until listings identical HP 2000 Access Source Reconstruction ==================================== J. David Bryan 2019-11-08 Hewlett-Packard provided the source code for the HP 2000 Access Time-Shared BASIC operating system on magnetic tape. The "HP 2000 Computer System Sources and Listings Documentation" manual (HP part number 22687-90020) describes the format of the distribution tapes. These are: - 22703-10001 Listings on 1/2-inch tape at 800 bpi NRZI - 22703-11001 Listings on 1/2-inch tape at 1600 bpi PE - 22703-10002 Sources on 1/2-inch tape at 800 bpi NRZI - 22703-11002 Sources on 1/2-inch tape at 1600 bpi PE Each tape is a "selective dump" of a 2000 Access user account: Z101 for the source files, and Z102 for the listing files. The files are BASIC data files containing strings, with one source or listing line per string. The file names are given in the above manual. With the source tape, one could, presumably, recreate the binary files that were distributed for installation on a new Access system. The "Master Control Program" installation tapes are: - 22687-11001 MCP tape for the 21MX or 21MX-E on 1/2-inch tape at 1600 bpi PE - 22687-11002 MCP tape for the 2100 on 1/2-inch tape at 1600 bpi PE With the SIMH/HP 2100 simulator, one could then explore the operation of the Access system and, if desired, modify it experimentally. The goal, then, is to obtain a set of source files that could be assembled into the identical files present on the MCP distribution tape. The final Access revision is date code 1812. The source tapes presumably reflected this. Unfortunately, this is not the case. In attempting to reconstruct the source files that would assemble to the binaries distributed on the MCP revision 1812 tapes, several obstacles were encountered. The first problem is that the Access system provided no assembler. So assembly of the sources would have to be performed on another system. Given that Access used both floating-point and special I/O Processor microcode, this meant using the RTE (Real-Time Executive, another HP operating system) assembler, which supported both of these requirements. A means of transporting the sources to an RTE system in a format acceptable to the RTE assembler was needed. The next problem is that there is no simple way of dumping the sources to a transport medium (e.g., paper tape or magnetic tape). To the Access system, the source files were simply BASIC data files containing strings. These strings would have to be read and "printed" to a tape punch or magnetic tape drive. A simple BASIC program ("LISTER") is provided with the listings tape to copy a specified listing file to a given device. No comparable program is provided for the source files. Moreover, the listing files contain carriage-control characters in column one of each line, whereas the source files do not. So a modified version of LISTER was used to print each source file to a simulated paper tape punch. The resulting set of paper tapes was then loaded into individual FMGR files on an RTE-IVB system. The files were named with the RTE convention by changing the leading "S" of each filename on the source tape to "&" (ampersand). The choice of RTE system was made by selecting the latest system that still used the historic assembler ("ASMB"). The later and more capable RTE-6/VM system did not support ASMB, replacing with a new macro assembler ("MACRO"). While MACRO could operate in an ASMB-compatible mode, it produced a different relocatable format (called the "new relocatable" format) that was incompatible with the Access IOP system generator program. Immediately, a new problem arose. The 80-some source files were written in three different assembly dialects, reflecting the three different assemblers used. Based on comments in the documentation manual and identifying marks in the corresponding listing files, their identities are: - HP 24158A assembler running DOS-III - HP 32223A cross-assembler for the HP 3000 running MPE - HP 22594A cross-assembler for the IBM 360 running OS/360 The DOS assembler was used for nine of the fourteen absolute assembly programs. The IBM cross-assembler was used for one absolute program -- the main program for the System Processor ("&TSB"). The 3000 cross-assembler was used for the remaining absolute, as well as all of the relocatable assembly programs. Some of the source files lacked the assembler directive (e.g., "ASMB,R,L") that is required as the first line of each file; these had to be added. Some files had the proper directive but preceded them by cross-assembler directives that had to be removed. Most files had sequence numbers in columns 72-80 that normally would not be a problem (they would be seen as comments), except in one case: a (sequence) number following the END pseudo-op is seen as a transfer address, which causes an assembly error. Again, these had to be removed (and, in fact, it was easier to remove all of the sequence numbers, as they serve no purpose in the assembly). The "&TSB" program required additional work. This source file contained 880 header-line pairs embedded within that had to be removed. More significantly, all quotation marks had been stripped, and lines were broken where the quotes had been. For example, the line: CBFLG EQU B20M "BREAK" COMMAND GIVEN ...was rendered as: CBFLG EQU B20M REAK COMMAND GIVEN At each occurrence of a quotation mark, the mark and the following character were deleted, and a line break was inserted. So in the example above, the leading quote and the B (of BREAK) were deleted, as was the trailing quote and the space before the word COMMAND. In most cases, these lines could be rejoined and reconstructed by inspection. However, some cases were not obvious. For these, inspection of corresponding sections of the 2000F source code was used to infer the missing characters. Once all of this editing was complete, the files were assembled. Some files assembled cleanly, but most reported multiple errors. These were categorized as follows: - OV (numeric operand overflow). These occurred on every RAM pseudo-op. - M (illegal operand). These occurred on some uses of the =L expression literal and the EQU pseudo-op. - SO (symbol table overflow). This occurred on the &TSB file. The RAM pseudo-op is used to generate the firmware extension instructions used by the I/O Processor. According to page 4-24 of the "RTE-IV Assembler Reference Manual" (92067-90003, October 1980), the operand to RAM "must evaluate to an absolute expression in the range 0 to 377 octal." This is because RAM adds its operand to the octal constant 105000, producing a machine instruction in the range 105000-105377. Unfortunately, the IOP microcode instructions fall into the range 101400-101437 and 105400-105763. So a use such as: RAM SAVE ...where SAVE is equated to 474 octal causes an assembler overflow error. Page 2-6 of the assembler manual says that the operand to an =L literal is "an expression which, when evaluated, will result in an absolute value." The illegal operand error has many causes, but one of them is "a negative operand is used with an opcode other than ABS, DEX, DEC, OCT, and BYT." The errors occurred on uses that produced negative results, such as: AND =L177777B-HLDTA ...where HLDTA is equated to 20B (the B suffix indicates an octal constant) or: LDA =LDFLAG-STCC ...where label DFLAG occurs at a lower address than label STCC. The EQU references were also negative, such as: BIT15 EQU 100000B Changing the 60 or so files that had assembly errors to correct the above uses would have been prohibitively difficult. Moreover, the resulting sources would not result in binaries identical to those on the MCP tape. So instead the source of the RTE assembler was modified to permit the semantics employed by the cross-assemblers. The symbol table overflow was a more difficult issue. The RTE assembler constructs its symbol table in the free memory available in the partition in which the assembler is loaded. In RTE-IVB, the largest possible partition is 29 1K-word pages in size. This was insufficient for the symbol table needed by the TSB program which, at some 46000+ lines, is by far the largest source program. This is undoubtedly the same reason this one program was cross-assembled on an IBM 360 instead of on the HP 3000. As RTE-IVB does not offer virtual memory, the TSB program could not be assembled on the RTE-IVB system. The RTE-6/VM assembler, MACRO, uses virtual memory, so symbol table space is not a problem. And indeed, the TSB program did assemble successfully using MACRO in its ASMB-compatible mode. However, the MACRO listing does not handle line numbers > 32767 correctly; it prints the line numbers as negative values (without the minus signs), so the line numbers decrease rather than increase. Also, MACRO outputs absolute records up to 256 words in size, whereas ASMB records are limited to 120 words. This may or may not cause a problem when loading the binary into a system but was cause for concern. RTE-6/VM supports normal (i.e., non-virtual-memory) programs up to 32 pages in size. As a trial, ASMB was linked and run on an RTE-6/VM system in a 32-page partition, and indeed it did have enough space to assemble the TSB program. So the decision was made to use RTE-6/VM to assemble all of the Access sources using a modified ASMB that follows the cross-assembler semantics for RAM, =L, and EQU. Almost all of the sources specify the "C" option in the assembler control statement that causes a symbol cross-reference table to be appended to the end of the assembler listing. This requires the "XREF" program from the RTE-IVB assembler package, and this program was linked as well on RTE-6/VM for a 32-page partition. However, even with the larger memory area available, a "TABLE OVERFLOW" error occurred when processing the TSB source file. XREF offers a method of processing symbols in batches to overcome this error. When invoked by the assembler, it processes all symbols, sorts them alphabetically, and then appends them to the assembler listing, starting with the page number following the last assembler page. By invoking XREF manually, subranges of the symbol set may be specified, which limits the memory required. For the TSB source file, three subranges were needed, as show in the invocation below (the invocation parameters are given on page I-2 of the assembler manual): :RU,XREF,&TSB::TS,-,1,-1031 /XREF: ENTER LIMITS OR ?] H /XREF: ENTER LIMITS OR ?]IR /XREF: ENTER LIMITS OR ?]S_ /XREF: ENTER LIMITS OR ?]/E /XREF: $END <*****> The limits are the first and last leading character of each subrange, and the "-1031" parameter indicates that the assembly listing ended with page number 1031 and so XREF should start with the next page. This method produced a full cross-reference. However, XREF only reports line numbers up to 32767. As the TSB program is some 46000 lines long, some line number references appear as "#####" to indicate numeric overflow. Once all of the sources assembled correctly, a check was needed to ensure that the resulting binaries matched those on the MCP tape. An examination of the tape revealed that 16 files were present. Each file except the first is preceded by an ID number. File 13 has ID number 26000, but there is no corresponding source file that produces a binary with that number! However, the omission was easily resolved: file SC79XX may be conditionally assembled either as ID 25000 or ID 26000. The assembler directive in the file specifies assembly as 25000. So SC79XX was copied to a new source file, "SC79X3", with a directive that specifies assembly as ID 26000. Tape files 1, 2, and 5-15 each consisted of single absolute programs, while files 2 and 3 each consisted of multiple relocatable programs forming the IOP module set. All programs are preceded and optionally followed by absolute records that are used as file and group ID markers. These present no special problem for the absolute programs, as they are created by inclusions in the corresponding sources. However, they are not part of the relocatable programs and must be excluded from any comparisons. Another problem arose here. It has been observed in previous reconstruction attempts that the various HP assemblers produce differing (but equivalent) binaries for the same source input. Consider, for example, a file containing one absolute record of 20 words loading at address 100, and another file containing two absolute records of 10 words loading at addresses 100 and 110. The files would not compare, even though the CPU memory images from loading the two files would be identical. Similar problems exist with relocatable records. Therefore, comparing the newly assembled binary files with those on the MCP tape would not necessarily work. To work around this, inverse assemblies were performed on the new object files, and the resulting listing were compared with inverse assemblies of the corresponding MCP tape files. If the listings were identical, then the source files would be correct. Work on reconstructing the HP 2000A sources showed that the "DOS-M ABSOLUTE OBJECT DECODER" (22415-80001 Revision B) is the only convenient inverse assembler for absolute binaries. This program runs under the DOS-III operating system, so the "DOS-M RELOCATABLE REVERSE ASSEMBLER" (22438-80001 Revision A) was selected to handle the relocatable files. The 13 absolute files were copied from the MCP tape to a single paper tape image using the RTE file manager. Then the corresponding absolute binary files produced by assembling the corresponding sources were copied to a second paper tape image. These images were fed as input to the DOS-III absolute inverse assembler (program "DCODE"), and the resulting listings were compared. The following discrepancies were noted: - C2883 : The source file is version 1705 while the MCP file is version 1624. The only difference is the constant declaration following label ".38" -- it is ".36 DEC 36" in 1705 and ".40 DEC 40" in 1624, but in both cases the constant is not used (not referenced). - C7900 : This file has the same issue as C2883 (they are in fact copies of each other, with C2883 specifying the "Z" assembler option and C7900 specifying the "N" option). - C79X3 : This source file does not exist, although the MCP file does. It was created by copying C79XX and specifying the "Z" assembler option instead of the "N" option. A few other minor changes brought it into compliance with the MCP version; these may be revealed by comparing the two source files. - MCPRG : The source file is version 1705 while the MCP file is version 1812. The only difference is the date code -- "PATDC EQU 1705" in 1705 and "PATDC EQU 1812" in 1812. relocatables using RBMSA: - D274E : One entry in the EBCD conversion table was updated. It is marked with an "[1812]" comment. - D50CD : The anticipated read length for a write/read call is increased from 1043 to 1199 bytes. The change is marked with an "[1812]" comment. - LTC : The original NAM record has a comment, which was ignored by the assembler used for the MCP tape. The RTE assembler includes NAM comments in the relocatable file, so the comment was removed. - RPC : A timer-running check was added for Revision 1812. - SYNIH : A parameter string length check was added, and a timeout bit check was corrected. The changes are marked with an "[1812]" comment.