SIMH Enhancements ================= COMPLETED ENHANCEMENTS ---------------------- The following enhancements have been completed with patches prepared but have not been submitted for approval: PENDING ENHANCEMENTS -------------------- These enhancements have plans of implementation devised, but no patches have been prepared: xxx. ENHANCEMENT: Add the internal paper tape reader to the TTY implementation. VERSION: 3.11-2 OBSERVATION: The current TTY implementation doesn't really model any existing supported Teletype, as it does not provide the paper tape reader. If the PTR is added, then it would model the HP 2754A when the paper tape punch is attached, or the HP 2752A when the punch is detached. An alternate would be to have a SET TTY 2752/2754 switch, but it is not clear what happens when the punch and/or reader is not attached. The reader may simply return DELs (377 octal) if the tape is missing. RESOLUTION: Modify the TTY device (hp2100_stddev.c) to add the paper tape reader. STATUS: Not started. xxx. ENHANCEMENT: Change the DS and DA devices to use the HP disc library. VERSION: 3.9-0 OBSERVATION: The disc library (hp_disclib) currently used by these simulators was heavily revised for use with the HP 3000 simulator. The DS and DA simulators should use the revised library to simplify the simulator code, for commonality with the 3000 simulator, and for better diagnostic test coverage of the library itself. RESOLUTION: Modify the DS (hp2100_ds.c) and DA (hp2100_di_da.c) devices to use the new disc library. STATUS: Not started. xxx. ENHANCEMENT: Change the MS device to use the HP tape library. VERSION: 3.9-0 OBSERVATION: The tape functions of the HP 7970B/E device simulator were abstracted and extended into a new tape library (hp_tapelib) used by the HP 3000 simulator. The MS simulator should use the new library to simplify the simulator code, for commonality with the 3000 simulator, and for better diagnostic test coverage of the library itself. RESOLUTION: Modify the MS (hp2100_ms.c) device to use the new tape library. STATUS: Not started. xxx. ENHANCEMENT: Add a simulation of the 7974 1/2" tape drive and the 12821A Disc Interface. VERSION: 3.8-1 OBSERVATION: The HP 7974A HP-IB tape drive replaced the older 7970B/E drives on later RTE-6/VM systems. It was interfaced via the 12821A HP-IB Disc Interface card; this card was also used to interface Amigo and CS/80 disc drives. NOTE that the 7974A was less common than CS/80 disc drives, and now we don't need to do the 7974A to get it into HPDrive, so the CS/80 implementation now takes priority. RESOLUTION: Add a simulation of the 12821A Disc Interface (hp2100_di.c). Add the MA device to simulate the 7974A. Alter "hp2100_sys.c" and "hp2100_defs.h" to add the device structure and default select code assignment. Add the 7974 boot loader extension instruction to the current DS/1000 microcode stub (hp2100_cpu0.c). STATUS: DI patches created 2010-11-04. MA not done yet. xxx. ENHANCEMENT: Add the 12992C boot loader ROM to the BACI simulation. VERSION: 3.8-1 OBSERVATION: The HP 264x terminals provided optional minicartridge (DC-100) drives that could be used to load absolute binary programs into the CPU. While none of the HP terminal emulators (QCTerm, Reflection) offer minicartridge support, it would not be that difficult to write such an emulator. Adding boot loader ROM support is simple and would be helpful to debug such an emulator. RESOLUTION: Add the 12992C boot loader ROM code and a "baci_boot" routine to the BACI simulation (hp2100_baci.c). STATUS: Not started. CHARACTERIZED ENHANCEMENTS -------------------------- These enhancements have been characterized by observation but are lacking an implementation: -- The tape library needs a way to permit writing erase gaps without reporting tape runaway. On the 2100, the 3030 and 7900 drives support gaps but have no way to handle runaway. As a result, they have two options, neither particularly good. They can set tape density so they can call "sim_tape_wrgap", but then they have to bracket all tape read and spacing calls with "do" loops that repeat if MTSE_RUNAWAY occurs. Or they can omit the density setting and call "sim_tape_errecf", but then they have to pass a record size calculated to provide the correct gap size at the unstated density. The former is awkward and imposes more overhead, while the latter requires knowledge of the physical implementation of erase gaps in the library. Note that "sim_tape_erase" cannot be used, as it does not fix up overlaid records as the other erase gap routines do. A better approach would be to separate density from runaway. One option is to modify "sim_tape_set_dens" to accept a new MT_RUNAWAY flag that would be included with the "val" parameter to enable runaway detection. For calls that set the density programmatically, the flag would be ORed with the desired MT_DENS constant. For calls that parse the command line, the flag would be passed as the parameter value. The flag would be stored in the unit's "dynflags" field by expanding the density reservation by one bit (density currently needs three bits; it would remain three bits, with a fourth dedicated to enabling runaway detection). -- It would be nice if the tape library supported capacities based on the reel size in feet, as well as in megabytes. Currently, the 7970 tape simulators for the 2100 and 3000 support tape-length capacities. But this depends on local knowledge that EOT is triggered by setting "uptr->capac" non-zero. It would be better if this was abstracted by the tape library. One option is to modify "sim_tape_set_capac" to parse a byte count if the "val" parameter is zero and a reel size in feet at the nominal density if "val" is non-zero. If the density has not been set, the latter would return a format error (MTSE_FMT). "val" could be set > 0 to permit any reel size or set < 0 to restrict sizes to 0, 600, 1200, and 2400 feet. -- Add key remapping for BS and DEL to the MUX, MPT, and TTY devices. Various HP OSes use differing keys for character-delete and line-delete. It's hard to remember these, especially when switching among them. It would be nicer if the characters sent for BS and DEL were remapped to the characters used by the specific OS. Perhaps SET TTY DELKEY=nnn and BSKEY=nnn. This could be an HP system module function, so that MTAB entries and a remapping call would be all that is necessary. Note that SET CONSOLE DEL=nnn does the opposite: it sends a DEL when character "nnn" is typed. I want "nnn" sent when DEL is typed. Note also that BACI and MPX are used only on RTE, which does not need the remapping. OS Backspace Delete ------ --------- ------ 2000A '_' ESC 2000C '_' ESC 2000E '_' CTRL+X 2000F '_' CTRL+X Access BS CTRL+X DOS CTRL+A DEL DOS-M CTRL+A DEL DOSIII CTRL+A DEL Diags (none) DEL RTE CTRL+A DEL RTE-II BS DEL -- Provide full 32-bit user flags fields for units and devices, and provide a simple way to access them via the modifier user interface for SET/SHOW. Currently, device and unit user flags share the same fields as system flags, so that expanding the latter reduces the space for the former. In some cases, e.g., with tape drives that use additional system flags, the remaining user space is tight, and adding additional system flags may collide with user flags, resulting in compilation errors. Providing a separate, user-only flags field is straightforward for devices, as there is no user interface provided. But providing a separate field for units means that "regular" MTAB entries will no longer work. In addition, user device flags are difficult to use, because "extended" MTAB entries must set and display flags with explicit validation and display routines, even though these functions could be handled automatically if unit flags were employed. This leads to using unit flags for convenience in places where the flags are properly properties of the devices. Moreover, in places where the distinction between the device and unit 0 is required, the action of a regular MTAB entry must be replicated by user-supplied functions for an extended entry that specifies the "valid for units only" option. A third type of MTAB entry is proposed. Such an entry would (a) have regular MTAB semantics, (b) act on device or unit flags as specified, and (c) access a new "user flags" field of the device or unit structure. The implementation appends a new MTAB field that defaults to zero for existing simulators, which would then operate on the existing flags fields with the usual regular or extended semantics to provide complete backward-compatibility. Setting the field to MTAB_XDV or MTAB_XUN causes the SET/SHOW routines to apply regular semantics to the device flags or user flags fields, respectively. Including a new MTAB_USER changes the target to the new user_flags fields in the device or unit structure. If both MTAB_XDV and MTAB_XUN are present, the flags are manipulated in whichever structure was specified in the command. New construction macros might be helpful to simplify initialization and to insulate some of the underlying fields. -- Allow spaces in filenames. Currently, spaces are accepted in some contexts and not in others. For example, ATTACH, SAVE, and RESTORE will accept filenames with spaces, while LOAD, SET CONSOLE LOG, and SET CONSOLE DEBUG will not. DO will accept a filename with spaces if it is quoted, whereas the others that accept spaces interpret the quotes as part of the filename. This inconsistent behavior is due to the method of obtaining the filename. The ones that reject call "get_glyph_nc", which terminates on spaces, while those that accept pass the remainder of the command line to "fopen". Filenames should be handled consistently by using a common parser that accepts quoted strings as single glyphs and otherwise uses spaces as terminators. This parser can be a hook if the current behavior must be maintained. -- A simulator that uses a calibrated timer as a time-of-day clock never calibrates if a series of GO UNTIL / REPLY commands are executed. At each string breakpoint, the calibration process, which takes one second, is restarted. Version 4.0 works around this by checking the length of (wall-clock) time the simulator has been stopped and skipping the reset if it is short enough. This permits the timer to retain calibration for short pauses. -- ASSERT and EXAMINE/DEPOSIT. Existing syntax: EXAMINE ASSERT Definitions: ::= | ::= | ::= | | | ::= "-" | "-" ::= | ::= a device or unit name ::= "@" ::= | ::= ::= ::= "=" | "==" | "!" | "!=" | ">=" | ">" | "<=" | "<" ::= "&" | "|" | "^" ::= | ::= ::= |
::= a register name
::= a memory address An enhancement would be to allow a for the in the specification. The symbol would be looked up using "parse_sym". Because the result may be multi-valued, i.e., up to "sim_emax" words long, the for the must also be multi-valued. We would allow a comma-separated numeric list, whose values would be applied one-to-one with the "sim_eval" values. The would have to be quoted if it was not a number. -- Temporary breakpoint syntax currently uses -T. This might be undesirable, as it removes a breakpoint type switch from the set available to VM. An alternate would be to use the "count" parameter but specified with a null value, e.g.: BREAK 34000[] Such a breakpoint would be functionally equivalent to: BREAK 34000; NOBREAK Implementation could be done in one of several ways: 1. Add a "one_time" field to the "sim_brktab" structure. 2. Set the "cnt" field to -1 (normal breakpoint counts set the value to 0 for persistent or +n for a count). 3. Insert a NOBREAK command as the first (or only) action. Note that the command will be echoed to the console (suppress in some way?). The only tricky part is handling breakpoint actions. Action strings are stored in memory allocated from the heap and referenced by the "act" pointer. Pending actions associated with a tripped breakpoint are handled by setting a global pointer "sim_brk_act" to the action string within "sim_brk_test" and then returning to the command execution loop, which copies command text from that pointer to "cbuf" in "sim_brk_getact". Action strings are deallocated when the associated breakpoint is cleared. If a one-time breakpoint is tripped, we can clear it in "sim_brk_test" only if we save the action string first. We can do this by saving the pointer to the string ("bp->act") in a new global variable ("sim_brk_actbuf") and setting the pointer in the breakpoint to NULL before calling "sim_brk_clr". When "sim_brk_getact" determines that the action string has been exhausted, it would call "sim_brk_clract", which would free the memory containing the string. Note that a null count value is currently accepted by SCP; it is equivalent to not specifying the count or to specifying a zero value, i.e., it creates a persistent breakpoint. We would redefine this action. -- Add a REALTIME/FASTTIME option to the 12920A multiplexer. The RTE default logical driver outputs DEL characters after each input line. Specifically, after pressing RETURN, the driver outputs CR DEL LF. The DELs print and space, overwriting the first character on the line and positioning at column 2 of the next line. The DELs may be suppressed if mode UC or 7P is used, although PCHAR must be set to allow ESC, DC1, and ENQ through. Also, logical driver LDV05 does ENQ/ACK handshakes with the terminal, and this is a very slow operation with QCTerm. A FASTTIME option that always suppressed DELs and did local ENQ/ACK processing would be helpful. -- [local] Change command table to interchange BOOT and BREAK command aliases (e.g., BOOT would become "BO", and BREAK would become "B"), as BOOT is used once, whereas BREAK may be used many times. -- [local] Add a CLEAR ("CL") command as an alias for NOBREAK. ("B" for break and "CL" for clear are GDB usages.) -- Provide a way to rewind an attached mag tape (now must detach and reattach). SET MSCn REWIND perhaps? Does "deposit msc0 pos[0] 0" work? set bot status? maybe "deposit" followed by "reset"? UNCHARACTERIZED ENHANCEMENTS ---------------------------- These enhancements have not been characterized as to practicability, implementation, or degree of difficulty: -- Align register (state) printouts. Loop through register names and determine the longest name, then pad others to same length. Currently uses tabs, which often yields ragged output. -- SHOW | should sense output line length and word-wrap as needed. Currently, some long descriptions and attached units with long filenames wrap the line at column 80. Would be nicer to wrap at words with appropriate indents. (Any host-independent way to determine terminal screen width? Sim setting?) -- EXAMINE STATE with arrayed registers stored in the unit structure produces confusing results, e.g., examining unit 1 shows the position for unit 0 (because it's displayed as POS[0], regardless of the unit selected). Would be better if it displayed POS[1] or just POS and showed the value for the selected unit. Examining the device would show the array, i.e., POS[0]. Perhaps add a REG_PER_UNIT flag to arrayed registers that should be displayed with the default index corresponding to the unit number. If the register depth did not equal the number of units, then display would be as a two-dimensional array if the depth was a multiple of the number of units (e.g., as for a per-unit buffer), and as a one-dimensional "long" array (i.e., longer than the number of units would suggest). This would handle per-unit arrayed registers, as well as per-unit buffers. NOTE: There is no device/unit display! Registers belong to the device, not to the units. Examining DPC1 (e.g.) returns the same set of register values as examining DPC3. -- Create a simulation of the 12732A floppy disc drive for RTE-M. RTE-M works only with the floppy or with cartridge tapes of the 264x-series terminals via a 12966A BACI card. Interface is via two 12566 microcircuit cards (control and data channels). Description of controller command set is in Appendix A of the 12732 diagnostic manual. The service manual has only the schematics. (The controller is actually in the floppy itself.) -- Move ms_timing (real/fast) and ms_ctype (13181/13183) from registers to device flags? -- Enhance 7900/7905 to allow separate mounting of fixed/removable platters (drive would only be ready when both are mounted). Existing "combined" platter images could be attached if existent, but not for creation. -- Add support for 7900/7905 S/P/D bits on a per-track basis. Would require 51 bytes per platter for 7900 if packed; could add at end of platter file, read and cache on attach, write on detach. -- Add CRCC/LRCC generation to 7970 simulator to get diagnostic to pass test 23 and others skipped via S register bit 7). This would likely be used only for the diagnostic, but it would allow the full diagnostic to pass cleanly. -- Simulate parity error interrupt for MP diag, RTE PE processing. SET CPU PARITYERROR, perhaps. Need a HLT PE/INT-IGNORE switch for the CPU. Note how PE diagnostic forces PE (jumper on card forces even parity, instead of odd, so only memory reads of words containing ? will fail). -- Add a console mapper for BACKSPACE. On some systems (e.g., RTE), it's the BS character. On others (e.g., DOS), it's CNTL+A. Still others (e.g., SIO) have no backspace (set to DEL?). SET CONSOLE BSP=n perhaps. -- Provide vm hook for breakpoint switch validation. -- Provide vm hook for ex/dep address print width (15 vs. 20). -- Change BOOT to use own S register unless "-s" supplied to use just SC. Provide proper M/T/OVFL return. -- Provide symbolic display for DMSSR, DMSVR. Print options (DMSSR): DMSSR: 160000 (MENIAK, UMPIAK, MEN, SMP, PRTOFF, MAPUP, FENCE=0000) or DMSSR: 160000 (MEMI=ENA MAPI=USR MEM=ENA MAP=SYS PROT=DIS MAP=UP FENCE=0000) DMSVR: 000000 (NORDV, NOWRV, NOBPV, NOPRV, MEBDIS MEMDIS SYSMAP MAPADR=00) or DMSVR: 000000 (RDV=NO WRV=NO BPV=NO PRV=NO MEB=DIS MEM=DIS MAP=SYS MAPADR=00) Bit 15 = 0: MDIINT - MEMI=DIS MEI=0 Bit 15 = 1: MENINT MEMINT MEMI=ENA MEI=1 Bit 14 = 0: SYSINT SMPINT MAPI=SYS MAI=0 Bit 14 = 1: USRINT UMPINT MAPI=USR MAI=1 Bit 13 = 0: MEN - MEM=DIS MEM=0 Bit 13 = 1: MDI MEM MEM=ENA MEM=1 Bit 12 = 0: SMP SYS MAP=SYS MAP=0 Bit 12 = 1: UMP USR MAP=USR MAP=1 Bit 11 = 0: PRTOFF - PROT=DIS PRO=0 Bit 11 = 1: PRTON PROT PROT=ENA PRO=1 Bit 10 = 0: MAPUP MAPHI BMAP=UP BMP=0 Bit 10 = 1: MAPDN MAPLOW BMAP=DN BMP=1 CLOSED ENHANCEMENTS ------------------- These enhancments turned out to be not required, due to acceptable workarounds, or not practicable: 1. ENHANCEMENT: Add a "-n" startup switch to suppress automatic execution of the initialization file. VERSION: 3.2-1 OBSERVATION: If a file with a base name matching the simulator executable and an extension matching ".ini" exists, it is automatically executed when the simulator starts. This is generally useful. However, if one does not want the initialization file executed for a particular run, e.g., for certain testing, there is no way to prevent this other than by renaming either the executable file or the initialization file. RESOLUTION: Not needed; specify "nul" as the command file to inhibit initialization, as any file specified on the command line is executed INSTEAD of the default initialization file. STATUS: Closed. ——————————————————————————————————————————————————————————————————————————————— xxx. ENHANCEMENT: VERSION: 3.11-2 OBSERVATION: RESOLUTION: STATUS: Not started. --------- maybe: - cptr = parse_filename (cptr, gbuf); default: cptr = get_glyph_nc (cptr, gbuf, 0) enhanced: store filename in gbuf, return updated pointer - cptr = parse_filename (cptr, NULL); default: return cptr enhanced: store filename in internal buffer, return pointer to buffer Filename parsing Bob, Periodically, I run into problems when specifying filenames or pathnames containing spaces, as they are handled inconsistently by SCP. Ideally, spaces would be unambiguous command parameter separators, but sometimes one doesn't have a choice, e.g., Windows' use of "Program Files" as a directory name. Given this, there should be a way of specifying such file and directory names when needed. (I am aware of Windows's support for alternate "8.3" filenames, such as PROGRA~1, but it is unreliable because [a] that support can be turned off in the registry and so may not be available, [b] for files having the same first six characters, the numerical assignment depends on the creation order, which is not obvious to the user, and [c] it does not apply to Linux systems.) Currently, spaces are accepted in some contexts and not in others. For example, ATTACH, SAVE, and RESTORE will accept path or filenames with spaces, while LOAD, SET CONSOLE LOG, and SET CONSOLE DEBUG will not. DO will accept a filename with spaces if it is quoted, whereas the others that accept spaces interpret the quotes as part of the filename. I find it troublesome, for instance, that the TTY punch file (via ATTACH) can be located in the "Documents and Settings" subdirectory, but the TTY print file (via SET CONSOLE LOG) cannot. This inconsistent behavior is due to the method of obtaining the filename. The ones that reject spaces call "get_glyph_nc", which terminates on spaces, while those that accept spaces either handle quotes specially (the DO command), or simply pass the remainder of the command line to "fopen". I would like to suggest that filenames be handled by calling a common parser from each location that currently processes a filename. The routine could handle filenames identically to the way they are handled now, except that a quoted filename containing spaces would be acceptable. Or the routine could provide uniform handling, terminating all non-quoted names at the first space, if you'd prefer that all commands handle filenames the same way. The routine could also be structured as a hook if you think VM-specific handling would be desirable. It is rare that I have to deal with pathnames containing spaces, but I've run into it enough to want to provide for it. Would you want me to proceed with a trial implementation of a filename parser? ----- I suggest that filenames should be handled by calling a common parser, potentially via a VM-settable hook, from each location that currently parses a filename. The parser could behave in one of three ways: 1. Accept a quoted filename containing spaces or an unquoted filename that ends at the first space. 2. Accept a quoted filename containing spaces or an unquoted filename that ends at the first space or at the end the line, depending on how it is handled currently. 3. Ignores quotes and accept a filename that ends at the first space or at the end the line, depending on how it is handled currently. Behavior 3 would yield the same behavior as currently exists, i.e., ATTACH et. al. would accept filenames with spaces and LOAD et. al. would not, with a leading quote considered to be part of the filename. Behavior 2 would keep the same behavior as 3 for unquoted names but would accept a quoted name containing spaces. The user would see no change, except for filenames that began with a leading quote; these would need to be enclosed in single quotes (apostrophes) to be accepted. For behavior 1, the user would see no change for filenames without spaces but would have to supply enclosing quotes for filenames containing spaces for commands that currently accept them unquoted (ATTACH, SAVE, et. al.). With behavior 1, all commands would parse filenames uniformly. I prefer behavior 1, but you would rather have behaviors 2 or 3, the routine can be implemented as a hook that points to a local routine but which I could override for the HP simulators. It is rare that I have to deal with pathnames containing spaces, but I've run into it enough to want to provide for it. Would you want me to proceed with a trial implementation of a filename parser?