diff --git a/0readmeAsynchIO.txt b/0readmeAsynchIO.txt index f4113403..e1969d4b 100644 --- a/0readmeAsynchIO.txt +++ b/0readmeAsynchIO.txt @@ -3,36 +3,36 @@ SIM_ASYNCH_IO Theory of operation. Features. - - Optional Use. Build with or without SIM_ASYNCH_IO defined and + - Optional Use. Build with or without SIM_ASYNCH_IO defined and simulators will still build and perform correctly when run. - Additionmally, a simulator built with SIM_ASYNCH_IO defined can - dynamically disable and reenable asynchronous operation with + Additionally, a simulator built with SIM_ASYNCH_IO defined can + dynamically disable and reenable asynchronous operation with the scp commands SET NOASYNCH and SET ASYNCH respectively. - - Consistent Save/Restore state. The state of a simulator saved + - Consistent Save/Restore state. The state of a simulator saved on a simulator with (or without) Asynch support can be restored - on any simulator of the same version with or without Asynch + on any simulator of the same version with or without Asynch support. - - Optimal behavior/performance with simulator running with or + - Optimal behavior/performance with simulator running with or without CPU idling enabled. - - Consistent minimum instruction scheduling delays when operating - with or without SIM_ASYNCH_IO. When SIM_ASYNCH_IO is emabled, - any operation which would have been scheduled to occurr in 'n' - instructions will still occur (from the simulated computer's + - Consistent minimum instruction scheduling delays when operating + with or without SIM_ASYNCH_IO. When SIM_ASYNCH_IO is enabled, + any operation which would have been scheduled to occur in 'n' + instructions will still occur (from the simulated computer's point of view) at least 'n' instructions after it was initiated. - + Benefits. - - Allows a simulator to execute simulated instructions concurrently + - Allows a simulator to execute simulated instructions concurrently with I/O operations which may take numerous milliseconds to perform. - - Allows a simulated device to potentially avoid polling for the - arrival of data. Polling consumes host processor CPU cycles which - may better be spent executing simulated instructions or letting - other host processes run. Measurements made of available + - Allows a simulated device to potentially avoid polling for the + arrival of data. Polling consumes host processor CPU cycles which + may better be spent executing simulated instructions or letting + other host processes run. Measurements made of available instruction execution easily demonstrate the benefits of parallel - instruction and I/O activities. A VAX simulator with a process - running a disk intensive application in one process was able to - run (in another process) 11 times the number of Dhrystone operations + instruction and I/O activities. A VAX simulator with a process + running a disk intensive application in one process was able to + run (in another process) 11 times the number of Dhrystone operations with Asynch I/O enabled vs not enabled. - - Allows simulator clock ticks to track wall clock was precisely as + - Allows simulator clock ticks to track wall clock was precisely as possible under varying I/O load and activities. SimH Libraries which provide Asynch I/O support: @@ -44,7 +44,7 @@ SimH Libraries which provide Asynch I/O support: Requirements to use: The Simulator's instruction loop needs to be modified to include a single -line which checks for asynchronouzly arrived events. The vax_cpu.c +line which checks for asynchronously arrived events. The vax_cpu.c module added the following line indicated by >>>: /* Main instruction loop */ @@ -60,20 +60,20 @@ module added the following line indicated by >>>: SET_IRQL; /* update interrupts */ } -A global variable (sim_asynch_latency) is used to indicate the "interrupt +A global variable (sim_asynch_latency) is used to indicate the "interrupt dispatch latency". This variable is the number of nanoseconds between checks for completed asynchronous I/O. The default value is 4000 (4 usec) which corresponds reasonably with simulated hardware. This variable controls the computation of sim_asynch_inst_latency which is the number of simulated instructions in the sim_asynch_latency interval. We are trying to avoid -checking for completed asynchronous I/O after every instruction since the +checking for completed asynchronous I/O after every instruction since the actual checking every instruction can slow down execution. Periodic checks -provide a balance which allows response similar to real hardware while also -providing minimal impact on actual instruction execution. Meanwhile, if -maximal response is desired, then the value of sim_asynch_latency can be +provide a balance which allows response similar to real hardware while also +providing minimal impact on actual instruction execution. Meanwhile, if +maximal response is desired, then the value of sim_asynch_latency can be set sufficiently low to assure that sim_asynch_inst_latency computes to 1. -The sim_asynch_inst_latency is dynamically updated once per second in the -sim_rtcn_calb routine where clock to instruction execution is dynamically +The sim_asynch_inst_latency is dynamically updated once per second in the +sim_rtcn_calb routine where clock to instruction execution is dynamically determined. A simulator would usually add register definitions to enable viewing and setting of these variables via scp: @@ -91,60 +91,60 @@ Naming conventions: All of the routines implemented in sim_disk and sim_tape have been kept in place. All routines which perform I/O have a variant routine available with a "_a" appended to the the routine name with the addition of a single -parameter which indicates the asynch completion callback routine. For +parameter which indicates the asynch completion callback routine. For example there now exists the routines: t_stat sim_tape_rdrecf (UNIT *uptr, uint8 *buf, t_mtrlnt *bc, t_mtrlnt max); t_stat sim_tape_rdrecf_a (UNIT *uptr, uint8 *buf, t_mtrlnt *bc, t_mtrlnt max, TAPE_PCALLBACK callback); The Purpose of the callback function is to record the I/O completion status -and then to schedule the activation of the unit. +and then to schedule the activation of the unit. Considerations: Avoiding multiple concurrent users of the unit structure. While asynch -I/O is pending on a Unit, the unit should not otherwise be on the event +I/O is pending on a Unit, the unit should not otherwise be on the event queue. The I/O completion will cause the Unit to be scheduled to run immediately to actually dispatch control flow to the callback routine. -The callback routine is always called in the same thread which is -executing instructions. Since all simulator device data structures are -only referenced from this thread there are no host multi-processor cache +The callback routine is always called in the same thread which is +executing instructions. Since all simulator device data structures are +only referenced from this thread there are no host multi-processor cache coherency issues to be concerned about. Arguments to the callback routine: UNIT *, and IO Status Requirements of the Callback routine. The callback routine must save the I/O completion status in a place -which the next invocation of the unit service routine will reference +which the next invocation of the unit service routine will reference and act on it. This allows device code to return error conditions -back to scp in a consistent way without regard to how the callback +back to scp in a consistent way without regard to how the callback routine (and the actual I/O) may have been executed. When the callback routine is called, it will already be on the simulator event queue with -an event time which was specified when the unit was attached or via a +an event time which was specified when the unit was attached or via a call to sim_disk_set_async. If no value has been specified then it -will have been scheduled with a delay time of 0. If a different event -firing time is desired, then the callback completion routine should +will have been scheduled with a delay time of 0. If a different event +firing time is desired, then the callback completion routine should call sim_activate_abs to schedule the event at the appropriate time. Required change in device coding. Devices which wish to leverage the benefits of asynch I/O must rearrange the code which implements the unit service routine. This rearrangement usually entails breaking the activities into two phases. The first phase -(I'll call the top half) involves performing whatever is needed to -initiate a call to perform an I/O operation with a callback argument. +(I'll call the top half) involves performing whatever is needed to +initiate a call to perform an I/O operation with a callback argument. Control is then immediately returned to the scp event dispatcher. -The callback routine needs to be coded to stash away the io completion +The callback routine needs to be coded to stash away the io completion status and some indicator that an I/O has completed. The top/bottom half separation of the unit service routine would be coded to examine the I/O completion indicator and invoke the bottom half -code upon completion. The bottom half code should clear the I/O -completion indicator and then perform any activities which normally +code upon completion. The bottom half code should clear the I/O +completion indicator and then perform any activities which normally need to occur after the I/O completes. Care should be taken while performing these top/bottom half activities to return to the scp event -dispatcher with either SCPE_OK or an appropriate error code when needed. -The need to return error indications to the scp event dispatcher is why -the bottom half activities can't simply be performed in the -callback routine (the callback routine does not return a status). -Care should also be taken to realize that local variables in the -unit service routine will not directly survive between the separate +dispatcher with either SCPE_OK or an appropriate error code when needed. +The need to return error indications to the scp event dispatcher is why +the bottom half activities can't simply be performed in the +callback routine (the callback routine does not return a status). +Care should also be taken to realize that local variables in the +unit service routine will not directly survive between the separate top and bottom half calls to the unit service routine. If any such information must be referenced in both the top and bottom half code paths then it must either be recomputed prior to the top/bottom half check @@ -162,65 +162,65 @@ more realistic delays to perform I/O operations. The pdp11_tq.c module has been refactored to leverage the asynch I/O features of the sim_tape library. The impact to this code to adopt the asynch I/O paradigm was very significant. This was due to the two facts: -1) there are many different operations which can be requested of tape -devices and 2) some of the tmscp operations required many separate +1) there are many different operations which can be requested of tape +devices and 2) some of the tmscp operations required many separate operations on the physical device layer to perform a single tmscp request. -This issue was addressed by adding additional routines to the physical +This issue was addressed by adding additional routines to the physical device layer (in sim_tape.c) which combined these multiple operations. -This approach will dovetail well with a potential future addition of +This approach will dovetail well with a potential future addition of operations on physical tapes as yet another supported tape format. -Programming Console and Multiplexer devices to leverage Asynch I/O to +Programming Console and Multiplexer devices to leverage Asynch I/O to minimize 'unproductive' polling. There are two goals for asynchronous Multiplexer I/O: 1) Minimize polling -to only happen when data is available, not arbitrarily on every clock tick, -and 2) to have polling actually happen as soon as data may be available. -In most cases no effort is required to add Asynch I/O support to a -multiplexer device emulation. If a device emulation takes the normal +to only happen when data is available, not arbitrarily on every clock tick, +and 2) to have polling actually happen as soon as data may be available. +In most cases no effort is required to add Asynch I/O support to a +multiplexer device emulation. If a device emulation takes the normal model of polling for arriving data on every simulated clock tick, then if -Asynch I/O is enabled, the device will operate asynchronously and behave -well. There is one restriction in this model. Specifically, the device -emulation logic can't expect that there will be a particular number (clock -tick rate maybe) of invocations of a unit service routine to perform polls -in any interval of time (this is what we're trying to change, right?). -Therefore presumptions about measuring time by counting polls is not -valid. If a device needs to manage time related activities, then the -device should create a separate unit which is dedicated to the timing -activities and which explicitly schedules a different unit service routine -for those activities as needed. Such scheduled polling should only be -enabled when actual timing is required. +Asynch I/O is enabled, the device will operate asynchronously and behave +well. There is one restriction in this model. Specifically, the device +emulation logic can't expect that there will be a particular number (clock +tick rate maybe) of invocations of a unit service routine to perform polls +in any interval of time (this is what we're trying to change, right?). +Therefore presumptions about measuring time by counting polls is not +valid. If a device needs to manage time related activities, then the +device should create a separate unit which is dedicated to the timing +activities and which explicitly schedules a different unit service routine +for those activities as needed. Such scheduled polling should only be +enabled when actual timing is required. A device which is unprepared to operate asynchronously can specifically -disable multiplexer Asynch I/O for that device by explicitly defining -NO_ASYNCH_MUX at compile time. This can be defined at the top of a -particular device emulation which isn't capable of asynch operation, or +disable multiplexer Asynch I/O for that device by explicitly defining +NO_ASYNCH_MUX at compile time. This can be defined at the top of a +particular device emulation which isn't capable of asynch operation, or it can be defined globally on the compile command line for the simulator. -Alternatively, if a specific Multiplexer device doesn't function correctly -under the multiplexer asynchronous environment and it will never be -revised to operate correctly, it may statically set the TMUF_NOASYNCH bit +Alternatively, if a specific Multiplexer device doesn't function correctly +under the multiplexer asynchronous environment and it will never be +revised to operate correctly, it may statically set the TMUF_NOASYNCH bit in its unit flags field. -Some devices will need a small amount of extra coding to leverage the -Multiplexer Asynch I/O capabilties. Devices which require extra coding +Some devices will need a small amount of extra coding to leverage the +Multiplexer Asynch I/O capabilities. Devices which require extra coding have one or more of the following characteristics: -- they poll for input data on a different unit (or units) than the unit +- they poll for input data on a different unit (or units) than the unit which was provided when tmxr_attach was called. - they poll for connections on a different unit than the unit which was provided when tmxr_attach was called. -The extra coding required for proper operation is to call -tmxr_set_line_unit() to associate the appropriate input polling unit to +The extra coding required for proper operation is to call +tmxr_set_line_unit() to associate the appropriate input polling unit to the respective multiplexer line (ONLY if input polling is done by a unit -different than the unit specified when the MUX was attached). If output +different than the unit specified when the MUX was attached). If output polling is done on a different unit, then tmxr_set_line_output_unit() should be called to describe that fact. -Console I/O can operate asynchronously if the simulator notifies the -tmxr/console subsystem which device unit is used by the simulator to poll -for console input and output units. This is done by including sim_tmxr.h -in the source module which contains the console input device definition -and calling tmxr_set_console_units(). tmxr_set_console_units would usually +Console I/O can operate asynchronously if the simulator notifies the +tmxr/console subsystem which device unit is used by the simulator to poll +for console input and output units. This is done by including sim_tmxr.h +in the source module which contains the console input device definition +and calling tmxr_set_console_units(). tmxr_set_console_units would usually be called in a device reset routine. sim_tmxr consumers: @@ -241,68 +241,68 @@ sim_tmxr consumers: - PDP-18b TT1 devices = 2, units = 1/16, lines = 16, flagbits = 0, Untested Asynch - SDS MUX devices = 2, units = 1/32, lines = 32, flagbits = 0, Untested Asynch - sim_console Good Asynch - -Program Clock Devices to leverage Asynsh I/O -simh's concept of time is calibrated by counting the number of -instructions which the simulator can execute in a given amount of wall -clock time. Once this is determined, the appropriate value is continually -recalibrated and used throughout a simulator to schedule device time -related delays as needed. Historically, this was fine until modern +Program Clock Devices to leverage Asynch I/O + +simh's concept of time is calibrated by counting the number of +instructions which the simulator can execute in a given amount of wall +clock time. Once this is determined, the appropriate value is continually +recalibrated and used throughout a simulator to schedule device time +related delays as needed. Historically, this was fine until modern processors started having dynamically variable processor clock rates. -On such host systems, the simulator's concept of time passing can vary +On such host systems, the simulator's concept of time passing can vary drastically. This dynamic adjustment of the host system's execution rate -may cause dramatic drifting of the simulated operating system's concept -of time. Once all devices are disconnected from the calibrated clock's -instruction count, the only concern for time in the simulated system is -that it's clock tick be as accurate as possible. This has worked well -in the past, however each simulator was burdened with providing code -which facilitated managing the concept of the relationship between the -number of instructions executed and the passage of wall clock time. -To accomodate the needs of activities or events which should be measured -against wall clock time (vs specific number of instructions executed), -the simulator framework has been extended to specifically provide event -scheduling based on elapsed wall time. A new API can be used by devices -to schedule unit event delivery after the passage of a specific amount -of wall clock time. The api sim_activate_after() provides this -capability. This capability is not limited to being available ONLY when -compiling with SIM_SYNCH_IO defined. When SIM_ASYNCH_IO is defined, this -facility is implemented by a thread which drives the delivery of these -events from the host system's clock ticks (interpolated as needed to -accomodate hosts with relatively large clock ticks). When SIM_ASYNCH_IO -is not defined, this facility is implemented using the traditional simh +may cause dramatic drifting of the simulated operating system's concept +of time. Once all devices are disconnected from the calibrated clock's +instruction count, the only concern for time in the simulated system is +that it's clock tick be as accurate as possible. This has worked well +in the past, however each simulator was burdened with providing code +which facilitated managing the concept of the relationship between the +number of instructions executed and the passage of wall clock time. +To accomodate the needs of activities or events which should be measured +against wall clock time (vs specific number of instructions executed), +the simulator framework has been extended to specifically provide event +scheduling based on elapsed wall time. A new API can be used by devices +to schedule unit event delivery after the passage of a specific amount +of wall clock time. The api sim_activate_after() provides this +capability. This capability is not limited to being available ONLY when +compiling with SIM_SYNCH_IO defined. When SIM_ASYNCH_IO is defined, this +facility is implemented by a thread which drives the delivery of these +events from the host system's clock ticks (interpolated as needed to +accomodate hosts with relatively large clock ticks). When SIM_ASYNCH_IO +is not defined, this facility is implemented using the traditional simh calibrated clock approach. This new approach has been measured to provide -clocks which drift far less than the drift realized in prior simh versions. -Using the released simh v3.9-0 vax simulator with idling enabled, the clock -drifted some 4 minutes in 35 minutes time (approximately 10%). The same OS -disk also running with idling enabled booted for 4 hours had less that 5 +clocks which drift far less than the drift realized in prior simh versions. +Using the released simh v3.9-0 vax simulator with idling enabled, the clock +drifted some 4 minutes in 35 minutes time (approximately 10%). The same OS +disk also running with idling enabled booted for 4 hours had less that 5 seconds of clock drift (approximately 0.03%). Co-Scheduling Clock and Multiplexer (or other devices) Many simulator devices have needs to periodically executed with timing on the order of the simulated system's clock ticks. There are numerous reasons for -this type of execution. Meanwhile, many of these events aren't particular +this type of execution. Meanwhile, many of these events aren't particular about exactly when they execute as long as they execute frequently enough. Frequently executing events has the potential to interfere with a simulator's attempts to idle when the simulated system isn't actually doing useful work. Interactions with attempts to 'co-schedule' multiplexer polling with clock -ticks can cause strange simulator behaviors. These strange behaviors only +ticks can cause strange simulator behaviors. These strange behaviors only happen under a combination of conditions: 1) a multiplexer device is defined in the simulator configuration, 2) the multiplexor device is NOT attached, and thus is not being managed by the asynchronous multiplexer support - 3) the multiplexer device schedules polling (co-scheduled) when not + 3) the multiplexer device schedules polling (co-scheduled) when not attached (such polling will never produce any input, so this is probably a bug). -In prior simh versions support for clock co-scheduling was implmented +In prior simh versions support for clock co-scheduling was implemented separately by each simulator, and usually was expressed by code of the form: sim_activate (uptr, clk_cosched (tmxr_poll)); -As a part of asynchronous timer support, the simulator framework has been +As a part of asynchronous timer support, the simulator framework has been extended to generically provide clock co-scheduling support. The use of this -new capability requires an initial call (usually in the clock device reset -routing) of the form: +new capability requires an initial call (usually in the clock device reset +routing) of the form: sim_register_clock_unit (&clk_unit); Once the clock unit has been registered, co-scheduling is achieved by replacing the earlier sim_activate with the following: @@ -311,8 +311,8 @@ the earlier sim_activate with the following: Run time requirements to use SIM_ASYNCH_IO. The Posix threads API (pthreads) is required for asynchronous execution. Most *nix platforms have these APIs available and on these platforms -simh is typically built with these available since on these platforms, -pthreads is required for simh networking support. Windows can also +simh is typically built with these available since on these platforms, +pthreads is required for simh networking support. Windows can also utilize the pthreads APIs if the compile and run time support for the win32Pthreads package has been installed on the build system. diff --git a/0readme_ethernet.txt b/0readme_ethernet.txt index c4d08308..62357a7c 100644 --- a/0readme_ethernet.txt +++ b/0readme_ethernet.txt @@ -3,7 +3,7 @@ This file contains information about the SIMH Ethernet package. ------------------------------------------------------------------------------- The XQ emulator is a host-independent software emulation of Digital's -DELQA-T (M7516-YM), DELQA (M7516) and DEQNA (M7504) Q-bus Ethernet cards +DELQA-T (M7516-YM), DELQA (M7516) and DEQNA (M7504) Q-bus Ethernet cards for the SIMH emulator. The XU emulator is a host-independent software emulation of Digital's DEUNA @@ -25,29 +25,29 @@ most of the undesirable traffic. You will only see "excessive" traffic if you are on a direct or hub(repeater) segment. On Windows using the WinPcap interface, the simulated computer can "talk" to -the host computer on the same interface. On other platforms with libpcap -(*nix), the simulated computer can not "talk" to the host computer via the +the host computer on the same interface. On other platforms with libpcap +(*nix), the simulated computer can not "talk" to the host computer via the selected interface, since simulator transmitted packets are not received -by the host's network stack. The workaround for this is to use a second NIC -in the host and connect them both into the same network; then the host and +by the host's network stack. The workaround for this is to use a second NIC +in the host and connect them both into the same network; then the host and the simulator can communicate over the physical LAN. -Integrated Universal TUN/TAP support provides another solution for the above +Integrated Universal TUN/TAP support provides another solution for the above dual-NIC problem for systems that support Universal TUN/TAP. Since the TUN/TAP -interface is a pseudo network interface, the host can create a TAP device for -the simulator and then bridge or route packets between the TAP device and the -real network interface. Note that the TAP device and any bridging or routing -must be established before running the simulator; SIMH does not create, +interface is a pseudo network interface, the host can create a TAP device for +the simulator and then bridge or route packets between the TAP device and the +real network interface. Note that the TAP device and any bridging or routing +must be established before running the simulator; SIMH does not create, bridge, or route TAP devices for you. Integrated Universal TUN/TAP support can be used for host<->simulator network traffic (on the platforms where it is available) by using the SIMH command: "attach xq tap:tapN" (i.e. attach xq tap:tap0). Platforms that this has been -tested on include: Linux, FreeBSD, OpenBSD, NetBSD and OSX. Each of these -platforms has some way to create a tap pseudo device (and possibly then to +tested on include: Linux, FreeBSD, OpenBSD, NetBSD and OSX. Each of these +platforms has some way to create a tap pseudo device (and possibly then to bridge it with a physical network interface). -The following steps were performed to get a working SIMH vax simulator +The following steps were performed to get a working SIMH vax simulator sharing a physical NIC and allowing Host<->SIMH vax communications: Linux (Ubuntu 10.04): @@ -79,7 +79,7 @@ Linux (Ubuntu 10.04): /sbin/ifconfig tap0 0.0.0.0 # Run simulator and "attach xq tap:tap0" - + Linux (Fedora Core 18, 20, CentOS, RedHat, etc.): yum install gcc @@ -90,7 +90,7 @@ Linux (Centos 6.x): yum install gcc yum install libpcap-devel yum install uml_utilities - + OpenBSD (OpenBSD 4.6) /sbin/ifconfig tun0 create @@ -103,10 +103,10 @@ OpenBSD (OpenBSD 4.6) /sbin/brconfig bridge0 up # Run simulator and "attach xq tap:tun0" - + FreeBSD (FreeBSD 11.3) - /sbin/sysctl net.link.tap.up_on_open=1 + /sbin/sysctl net.link.tap.up_on_open=1 /sbin/ifconfig tap0 create /sbin/ifconfig tap0 up @@ -131,38 +131,38 @@ NetBSD (NetBSD 5.0.2) OSX (Snow Leopard) OSX Does NOT have native support for tun/tap interfaces. It also does not have native support for bridging. - - Mattias Nissler has created tun/tap functionality available at http://tuntaposx,sourceforge.net/ - + + Mattias Nissler has created tun/tap functionality available at http://tuntaposx.sourceforge.net/ + We'll punt on bridging for the sake of this example and move on to use a basic tap based internal network so a host and guest can communicate directly. - - Download the install package from: + + Download the install package from: http://sourceforge.net/projects/tuntaposx/files/tuntap/20111101/tuntap_20111101.tar.gz - + Expand the tarball to a directory. Invoke the package installer tuntap_20111101.pkg Click through the various prompts accepting things and eventually installing the package. - + # Build and Run simulator and: sim> attach xq tap:tap0 sim> ! ifconfig tap0 192.168.6.1 netmask 255.255.255.0 - Simulated system uses IP address 192.168.6.2 and host uses 192.168.6.1 + Simulated system uses IP address 192.168.6.2 and host uses 192.168.6.1 and things work. You must run as root for this to work. - + ------------------------------------------------------------------------------- -An alternative to direct pcap and tun/tap networking on *nix environments is +An alternative to direct pcap and tun/tap networking on *nix environments is VDE (Virtual Distributed Ethernet). -Note 1: Using vde based networking is likely more flexible, but it isn't - nearly as efficient. Host OS overhead will always be higher when - vde networking is used as compared to native pcap and/or tun/tap +Note 1: Using vde based networking is likely more flexible, but it isn't + nearly as efficient. Host OS overhead will always be higher when + vde networking is used as compared to native pcap and/or tun/tap networking. -Note 2: Root access will likely be needed to configure or start the vde +Note 2: Root access will likely be needed to configure or start the vde environment prior to starting a simulator which may use it. -Note 3: Simulators running using VDE networking can run without root +Note 3: Simulators running using VDE networking can run without root privilege. Linux (Ubuntu 11.10): @@ -172,44 +172,44 @@ Linux (Ubuntu 11.10): vde_switch -s /tmp/switch1 -tap tap0 -m 666 ifconfig tap0 192.168.6.1 netmask 255.255.255.0 up - + # Build and Run simulator and: sim> attach xq vde:/tmp/switch1 #simulator uses IP address 192.168.6.2 OSX: - The macports package manager (http://www.macports.org) can be used to + The macports package manager (http://www.macports.org) can be used to install the net/vde2 package. ------------------------------------------------------------------------------- -Another alternative to direct pcap and tun/tap networking on all environments is +Another alternative to direct pcap and tun/tap networking on all environments is NAT (SLiRP) networking. NAT networking is limited to only IP network protocols so DECnet, LAT and Clusting can't work on a NAT connected interface, but this may be the easiest solution for many folks. sim> attach xq nat: - -The simulator can use static IP addresses of 10.0.2.4 thru 10.0.2.14 with a + +The simulator can use static IP addresses of 10.0.2.4 thru 10.0.2.14 with a netmask of 255.255.255.0 and a gateway of 10.0.2.2 and a nameserver of 10.0.2.3. -If the simulated machine uses DHCP it will get the address 10.0.2.15. Various -NAT based parameters can be configured on the attach command. HELP XQ ATTACH -will provide useful information. Host to simulator connectivitiy can be -achieved for a simulator which gets its IP address via DHCP with the following +If the simulated machine uses DHCP it will get the address 10.0.2.15. Various +NAT based parameters can be configured on the attach command. HELP XQ ATTACH +will provide useful information. Host to simulator connectivity can be +achieved for a simulator which gets its IP address via DHCP with the following command: sim> attach xq nat:tcp=2323:10.0.2.15:23,tcp=2121:10.0.2.15:21 - -The host computer can telnet to localhost:2323 to reach the simulator via + +The host computer can telnet to localhost:2323 to reach the simulator via telnet, etc. -Additionally NAT based networking is useful to allow host systems with WiFi +Additionally NAT based networking is useful to allow host systems with WiFi networking to a) reach the simulated system and b) allow the simulated system to reach out to the Internet. -Note: As mentioned above, NAT networking is specifically capable of providing - TCP/IP connectivity. Only expect TCP and UDP traffic to pass through - the interface. Do not expect ICMP traffic (ping mostly) to traverse - the NAT boundary. This restriction is a conseqence of host platform - and network limitations regarding direct user mode code generating ICMP +Note: As mentioned above, NAT networking is specifically capable of providing + TCP/IP connectivity. Only expect TCP and UDP traffic to pass through + the interface. Do not expect ICMP traffic (ping mostly) to traverse + the NAT boundary. This restriction is a consequence of host platform + and network limitations regarding direct user mode code generating ICMP packets. @@ -217,34 +217,34 @@ Note: As mentioned above, NAT networking is specifically capable of providing Windows notes: 1. The Npcap package available from https://nmap.org/npcap is the preferred - interface for Windows 7 onward since the original WinPCAP 4.1.3 package + interface for Windows 7 onward since the original WinPCAP 4.1.3 package from https://www.winpcap.org/install/bin/WinPcap_4_1_3.exe is no longer - developed or supported. These packages for windows simulate the libpcap - package that is freely available for un*x systems. + developed or supported. These packages for windows simulate the libpcap + package that is freely available for un*x systems. 2. You must *install* the npcap or WinPCAP runtime package. - 3. The first time the npcap/WinPCAP driver is used, it will be dynamically - loaded, and the user must be an Administrator on the machine to do so. - If you need to run as an unprivileged user, you must set the "npf" driver - to autostart. - Current Npcap and WinPcap installers provide an option to configure this + 3. The first time the npcap/WinPCAP driver is used, it will be dynamically + loaded, and the user must be an Administrator on the machine to do so. + If you need to run as an unprivileged user, you must set the "npf" driver + to autostart. + Current Npcap and WinPcap installers provide an option to configure this at installation time, so if that choice is made, then there is no need for administrator privileged to run simulators with network support. Building on Windows: - You should be able to build with any of the free compiler environments - available on the Windows platform. If you want to use the Visual C++ - Express 2008 or 2010 interactive development environments, read the file + You should be able to build with any of the free compiler environments + available on the Windows platform. If you want to use the Visual C++ + Express 2008 or 2010 interactive development environments, read the file ".\Visual Studio Projects\0ReadMe_Projects.txt" for details about the required dependencies. Alternatively, you can build simh with networking - support using the MinGW GCC compiler environment (32 bit) or the cygwin - environment. Each of these Visual C++, MinGW and cygwin build environments - require Npcap or WinPcap and Posix threading packages being available. - These should be located in a directory structure parallel to the current + support using the MinGW GCC compiler environment (32 bit) or the cygwin + environment. Each of these Visual C++, MinGW and cygwin build environments + require Npcap or WinPcap and Posix threading packages being available. + These should be located in a directory structure parallel to the current simulator source directory. - + For Example, the directory structure should look like: .../simh/simh-master/VAX/vax_cpu.c @@ -261,16 +261,16 @@ Building on Windows: There are Windows batch files provided to initiate compiles using the MinGW - compiler tool chain. These batch files are located in the same directory - as this file and are called: build_mingw.bat, build_mingw_ether.bat, and - build_mingw_noasync.bat. These batch files each presume that the MinGW + compiler tool chain. These batch files are located in the same directory + as this file and are called: build_mingw.bat, build_mingw_ether.bat, and + build_mingw_noasync.bat. These batch files each presume that the MinGW toolchain is either in the current path or, if not that it is located at C:\MinGW\bin. These batch files merely invoke the MinGW make (GNU make) - passing some specific arguments along with the optional arguments the batch + passing some specific arguments along with the optional arguments the batch file is invoked with. - - The current windows network built binaries will run on any system without - regard to whether or not Npcap or WinPcap is installed, and will provide + + The current windows network built binaries will run on any system without + regard to whether or not Npcap or WinPcap is installed, and will provide Network functionality when Npcap or WinPcap is available. ------------------------------------------------------------------------------- @@ -282,19 +282,19 @@ Linux, {Free|Net|Open}BSD, OS/X, and Un*x notes: Sim_Ether has been reworked to be more universal; because of this, you will need to get a version of libpcap that is 0.9 or greater. All current Linux distributions provide a libpcap-dev package which has the needed version -of libpcap and the required components to build applications using it. -If you are running an older Linux OS, you can download and build the required -library from www.tcpdump.org - see the comments at the top of Sim_ether.c -for details. +of libpcap and the required components to build applications using it. +If you are running an older Linux OS, you can download and build the required +library from www.tcpdump.org - see the comments at the top of Sim_ether.c +for details. ----- WARNING ----- WARNING ----- WARNING ----- WARNING ----- WARNING ----- 1. For all platforms, you must run SIMH(scp) with sufficient privilege to allow the Ethernet card can be set into promiscuous mode and to write - packets through the driver. - a) For Windows systems this means having administrator privileges to - start the "npf" driver. The current WinPcap installer offers an - option to autostart the "npf" driver when the system boots. + packets through the driver. + a) For Windows systems this means having administrator privileges to + start the "npf" driver. The current WinPcap installer offers an + option to autostart the "npf" driver when the system boots. Starting the "npf" driver at boot time means that simulators do not need to run with administrator privileges. b) For more recent Linux systems, The concepts leveraging "Filesystem @@ -303,76 +303,76 @@ for details. http://packetlife.net/blog/2010/mar/19/sniffing-wireshark-non-root-user/ describes how to do this for wireshark. The exact same capabilities are needed by SIMH for network support. Use that article as a guide. - c) For Unix/Unix-like systems which use bpf devices (NetBSD, - OpenBSD, FreeBSD and OS/X) it is possible to set permissions on - the bpf devices to allow read and write access to users other - than root (For example: chmod 666 /dev/bpf*). Doing this, has + c) For Unix/Unix-like systems which use bpf devices (NetBSD, + OpenBSD, FreeBSD and OS/X) it is possible to set permissions on + the bpf devices to allow read and write access to users other + than root (For example: chmod 666 /dev/bpf*). Doing this, has its own security issues. d) For other platforms this will likely mean running as root. - Additional alternative methods for avoiding the 'run as root' requirement + Additional alternative methods for avoiding the 'run as root' requirement will be welcomed. 2. If you want to use TAP devices, and any surrounding system network/bridge - setup must be done before running SIMH. However, once that is done + setup must be done before running SIMH. However, once that is done (possibly at system boot time), using the TAP devices can be done without root privileges. Building on Linux, {Free|Net|Open}BSD, OS/X, Solaris, other *nix: - 1. Get/make/install the libpcap-dev package (or libpcap-devel) for your + 1. Get/make/install the libpcap-dev package (or libpcap-devel) for your operating system. Sources: All : http://www.tcpdump.org/ Older versions of libpcap can be found, for various systems, at: - Linux : - Debian Based distributions: + Linux : + Debian Based distributions: # apt-get install libpcap-dev RedHat/Fedora Based distributions: # yum install libpcap-devel - - OS/X : The libpcap components are installed as part of the Xcode - developer package. Instructions to install Xcode on various - OSX versions are available at: + + OS/X : The libpcap components are installed as part of the Xcode + developer package. Instructions to install Xcode on various + OSX versions are available at: https://guide.macports.org/chunked/installing.xcode.html Be sure to install the command line tools which are installed - with the command "xcode-select --install" in more recent + with the command "xcode-select --install" in more recent versions of the Apple developer support. - + HP-UX : ftp://hpux.connect.org.uk/hpux/Networking/Admin/ NOTE: The repositories for older versions of these platforms don't contain a version of libpcap greater than 0.8.1. - However, most(all) recent releases of *nix environments - ship with sufficiently recent versions of libpcap either - automatically installed or available for installation as - part of the distribution. - The OS provided libpcap-dev components will be prefereable + However, most(all) recent releases of *nix environments + ship with sufficiently recent versions of libpcap either + automatically installed or available for installation as + part of the distribution. + The OS provided libpcap-dev components will be preferable to a package built from www.tcpdump.org sources. This is - due to the fact that various OS supplied packages will - depend on the OS supplied libpcap. The improper build or - install of the www.tcpdump.org source package can conflict - with the OS provided one and break the OS provided + due to the fact that various OS supplied packages will + depend on the OS supplied libpcap. The improper build or + install of the www.tcpdump.org source package can conflict + with the OS provided one and break the OS provided applications (i.e. tcpdump and/or wireshark) as well as not working correctly for use by simh. 2. If you install the vendor supplied libpcap-dev package then the simh - makefile will automatically use the vendor supplied library without any - additional arguments. If you have downloaded and built libpcap from + makefile will automatically use the vendor supplied library without any + additional arguments. If you have downloaded and built libpcap from www.tcpdump.org, then the existing makefile will detect that this is the case and try to use that. 3. The makefile defaults to building simulators with network support which dynamically load the libpcap library. This means that the same simulator - binaries will run on any system whether or not libpcap is installed. If - you want to force direct libpcap linking during a build you do so by - typing 'make USE_NETWORK=1'. You must build with gcc to do this. There + binaries will run on any system whether or not libpcap is installed. If + you want to force direct libpcap linking during a build you do so by + typing 'make USE_NETWORK=1'. You must build with gcc to do this. There is no observable benefit to statically linking against libpcap. Support - for statically linking libpcap ia deprecated on all platforms except + for statically linking libpcap is deprecated on all platforms except Linux and OS X where it has already been removed. - - 4. Some platforms (HP-UX in particular) may not have vendor supplied libpcap + + 4. Some platforms (HP-UX in particular) may not have vendor supplied libpcap components available and installed with the operating system. The packages - which are available for this platform install include and library files in - user specified locations. When building on these platforms the library + which are available for this platform install include and library files in + user specified locations. When building on these platforms the library path must be specified on the make command line. This can be done with: 'make LPATH=/usr/lib:/usr/local/lib' @@ -380,7 +380,7 @@ Building on Linux, {Free|Net|Open}BSD, OS/X, Solaris, other *nix: ------------------------------------------------------------------------------- -OpenVMS Alpha and OpenVMS Integrety (IA64) notes: +OpenVMS Alpha and OpenVMS Integrity (IA64) notes: 1. Ethernet support will only work on Alpha VMS 7.3-1 or later, which is when required VCI promiscuous mode support was added. Hobbyists can get the required version of VMS from the OpenVMS Alpha Hobbyist Kit 3.0. @@ -413,13 +413,13 @@ OpenVMS Alpha and OpenVMS Integrety (IA64) notes: adapter prior trying to connect with SIMH, or the host may crash. The execlet is not written to create an I/O structure for the device. -Building on OpenVMS Alpha and OpenVMS Integrety (IA64): +Building on OpenVMS Alpha and OpenVMS Integrity (IA64): The current descrip.mms file will build simulators capable of using - Ethernet support with them automatically. These currently are: VAX, + Ethernet support with them automatically. These currently are: VAX, VAX780, and PDP11. The descrip.mms driven builds will also build the pcap library and build and install the VCI execlet. - - 1. Fetch the VMS-PCAP zip file from: + + 1. Fetch the VMS-PCAP zip file from: http://simh.trailing-edge.com/sources/vms-pcap.zip 2. Unzip it into the base of the SIMH distribution directory. 3. Build the simulator(s) with MMS or MMK: @@ -441,7 +441,7 @@ Other testers have reported that RSX with DECNET and the NetBSD operating systems also work. RSTS/E v10.1 has preliminary support - RSTS/E boots and enables the XH (XQ) device - DECNET and LAT software have not been tested. -The XU module has been tested by a third party for basic packet functionality +The XU module has been tested by a third party for basic packet functionality under a modified RSX11M environment. I am unable to test it in-house until someone can arrange to send me a disk image containing a stock RSTS/E or RSX11M+ system image that also contains DECNET, LAT, and/or TCP/IP software. @@ -486,9 +486,9 @@ Dave =============================================================================== Change Log =============================================================================== - + 01-Mar-12 AGN Added support for building using Cygwin on Windows - 01-Mar-12 MP Made host NIC address detection more robust on *nix platforms + 01-Mar-12 MP Made host NIC address detection more robust on *nix platforms and mad it work when compiling under Cygwin 29-Feb-12 MP Fixed MAC Address Conflict detection support 28-Feb-12 MP Fixed overrun bug in eth_devices which caused SEGFAULTs @@ -498,95 +498,95 @@ Dave 17-Nov-11 MP Added dynamic loading of libpcap on *nix platforms 30-Oct-11 MP Added support for vde (Virtual Distributed Ethernet) networking 29-Oct-11 MP Added support for integrated Tap networking interfaces on OSX - 17-Aug-11 RMS Fix from Sergey Oboguev relating to XU and XQ Auto Config and + 17-Aug-11 RMS Fix from Sergey Oboguev relating to XU and XQ Auto Config and vector assignments 12-Aug-11 MP Cleaned up payload length determination - Fixed race condition detecting reflections when threaded + Fixed race condition detecting reflections when threaded reading and writing is enabled 07-Jul-11 MB VMS Pcap (from Mike Burke) - Fixed Alpha issues - - Added OpenVMS Integrety support + - Added OpenVMS Integrity support 20-Apr-11 MP Fixed save/restore behavior 12-Jan-11 DTH Added SHOW XU FILTERS modifier 11-Jan-11 DTH Corrected DEUNA/DELUA SELFTEST command, enabling use by VMS 3.7, VMS 4.7, and Ultrix 1.1 - 09-Jan-11 MP Fixed missing crc data when USE_READER_THREAD is defined and + 09-Jan-11 MP Fixed missing crc data when USE_READER_THREAD is defined and crc's are needed (only the pdp11_xu) - 16-Dec-10 MP added priority boost for read and write threads when + 16-Dec-10 MP added priority boost for read and write threads when USE_READER_THREAD does I/O in separate threads. This helps - throughput since it allows these I/O bound threads to preempt - the main thread (which is executing simulated instructions). + throughput since it allows these I/O bound threads to preempt + the main thread (which is executing simulated instructions). 09-Dec-10 MP allowed more flexible parsing of MAC address strings 09-Dec-10 MP Added support to determine if network address conflicts exist 07-Dec-10 MP Reworked DECnet self detection to the more general approach of loopback self when any Physical Address is being set. 06-Dec-10 MP Added loopback processing support to pdp11_xu.c 06-Dec-10 MP Fixed loopback processing to correctly handle forward packets. - 04-Dec-10 MP Changed eth_write to do nonblocking writes when + 04-Dec-10 MP Changed eth_write to do nonblocking writes when USE_READER_THREAD is defined. 30-Nov-10 MP Fixed the fact that no broadcast packets were received by the DEUNA - 29-Nov-10 MP Fixed interrupt dispatch issue which caused delivered packets + 29-Nov-10 MP Fixed interrupt dispatch issue which caused delivered packets (in and out) to sometimes not interrupt the CPU after processing. 17-Jun-10 MP Fixed bug in the AUTODIN II hash filtering. - 14-Jun-10 MP Added support for integrated Tap networking interfaces on BSD + 14-Jun-10 MP Added support for integrated Tap networking interfaces on BSD platforms. - 13-Jun-10 MP Added support for integrated Tap networking interfaces on Linux + 13-Jun-10 MP Added support for integrated Tap networking interfaces on Linux platforms. 31-May-10 MP Added support for more TOE (TCP Offload Engine) features for IPv4 network traffic from the host and/or from hosts on the LAN. These new TOE features are: LSO (Large Send Offload) and Jumbo packet fragmentation support. These features allow a simulated network - device to support traffic when a host leverages a NIC's Large - Send Offload capabilities to fragment and/or segment outgoing - network traffic. Additionally a simulated network device can + device to support traffic when a host leverages a NIC's Large + Send Offload capabilities to fragment and/or segment outgoing + network traffic. Additionally a simulated network device can reasonably exist on a LAN which is configured to use Jumbo frames. - 21-May-10 MP Added functionality to fix up IP header checksums to accommodate + 21-May-10 MP Added functionality to fix up IP header checksums to accommodate packets from a host with a NIC which has TOE (TCP Offload Engine) enabled which is expected to implement the checksum computations in hardware. Since we catch packets before they arrive at the NIC the expected checksum insertions haven't been performed yet. - This processing is only done for packets sent from the host to - the guest we're supporting. In general this will be a relatively + This processing is only done for packets sent from the host to + the guest we're supporting. In general this will be a relatively small number of packets so it is done for all IP frame packets - coming from the host to the guest. In order to make the + coming from the host to the guest. In order to make the determination of packets specifically arriving from the host we need to know the hardware MAC address of the host NIC. Currently determining a NIC's MAC address is relatively easy on Windows. - The non-windows code works on linux and may work on other *nix - platforms either as is or with slight modifications. The code, - as implemented, only messes with this activity if the host + The non-windows code works on linux and may work on other *nix + platforms either as is or with slight modifications. The code, + as implemented, only messes with this activity if the host interface MAC address can be determined. - 20-May-10 MP Added general support to deal with receiving packets smaller + 20-May-10 MP Added general support to deal with receiving packets smaller than ETH_MIN_PACKET in length. These come from packets looped back by some bridging mechanism and need to be padded - to the minimum frame size. A real NIC won't pass us any + to the minimum frame size. A real NIC won't pass us any packets like that. This fix belongs here since this layer - is responsible for interfacing to the physical layer + is responsible for interfacing to the physical layer devices, AND it belongs here to get CRC processing right. 15-Aug-08 MP Fixed transmitted packets to have the correct source MAC address. Fixed incorrect address filter setting calling eth_filter(). - 07-Mar-08 MP Fixed the SCP visible SA registers to always display the + 07-Mar-08 MP Fixed the SCP visible SA registers to always display the ROM MAC address, even after it is changed by SET XQ MAC=. - 07-Mar-08 MP Added changes so that the Console DELQA diagnostic (>>>TEST 82) + 07-Mar-08 MP Added changes so that the Console DELQA diagnostic (>>>TEST 82) will succeed. 03-Mar-08 MP Added DELQA-T (aka DELQA Plus) device emulation support. 06-Feb-08 MP Added dropped frame statistics to record when the receiver discards received packets due to the receiver being disabled, or due to the XQ device's packet receive queue being full. Fixed bug in receive processing when we're not polling. This could - cause receive processing to never be activated again if we don't - read all available packets via eth_read each time we get the + cause receive processing to never be activated again if we don't + read all available packets via eth_read each time we get the opportunity. 31-Jan-08 MP Added the ability to Coalesce received packet interrupts. This - is enabled by SET XQ POLL=DELAY=nnn where nnn is a number of + is enabled by SET XQ POLL=DELAY=nnn where nnn is a number of microseconds to delay the triggering of an interrupt when a packet is received. - 29-Jan-08 MP Added SET XQ POLL=DISABLE (aka SET XQ POLL=0) to operate without + 29-Jan-08 MP Added SET XQ POLL=DISABLE (aka SET XQ POLL=0) to operate without polling for packet read completion. 29-Jan-08 MP Changed the sanity and id timer mechanisms to use a separate timer unit so that transmit and receive activities can be dealt with by the normal xq_svc routine. - Dynamically determine the timer polling rate based on the + Dynamically determine the timer polling rate based on the calibrated tmr_poll and clk_tps values of the simulator. 25-Jan-08 MP Enabled the SET XQ POLL to be meaningful if the simulator currently doesn't support idling. @@ -594,7 +594,7 @@ Dave all debug output goes to the same place. 25-Jan-08 MP Restored the call to xq_svc after all successful calls to eth_write to allow receive processing to happen before the next event - service time. This must have been inadvertently commented out + service time. This must have been inadvertently commented out while other things were being tested. 23-Jan-08 MP Added debugging support to display packet headers and packet data 18-Jun-07 RMS Added UNIT_IDLE flag @@ -608,21 +608,21 @@ Dave LANCE style AUTODIN II based hashed filtering. 07-Feb-08 MP Added eth_show_dev to display Ethernet state Changed the return value from eth_read to return whether - or not a packet was read. No existing callers used or + or not a packet was read. No existing callers used or checked constant return value that previously was being supplied. - 29-Jan-08 MP Added eth_set_async to provide a mechanism (when - USE_READER_THREAD is enabled) to allow packet reception - to dynamically update the simulator event queue and - potentially avoid polling for I/O. This provides a minimal - overhead (no polling) maximal responsiveness for network + 29-Jan-08 MP Added eth_set_async to provide a mechanism (when + USE_READER_THREAD is enabled) to allow packet reception + to dynamically update the simulator event queue and + potentially avoid polling for I/O. This provides a minimal + overhead (no polling) maximal responsiveness for network activities. 29-Jan-08 MP Properly sequenced activities in eth_close to avoid a race condition when USE_READER_THREAD is enabled. 25-Jan-08 MP Changed the following when USE_READER_THREAD is enabled: - - Fixed bug when the simulated device doesn't need crc + - Fixed bug when the simulated device doesn't need crc in packet data which is read. - - Added call to pcap_setmintocopy to minimize packet + - Added call to pcap_setmintocopy to minimize packet delivery latencies. - Added ethq_destroy and used it to avoid a memory leak in eth_close. @@ -632,8 +632,8 @@ Dave Fixed the bpf filter used when no traffic is to be matched. Reworked eth_add_packet_crc32 implementation to avoid an extra buffer copy while reading packets. - Fixed up #ifdef's relating to USE_SHARED so that setting - USE_SHARED or USE_NETWORK will build a working network + Fixed up #ifdef's relating to USE_SHARED so that setting + USE_SHARED or USE_NETWORK will build a working network environment. 23-Jan-08 MP Reworked eth_packet_trace and eth_packet_trace_ex to allow only output Ethernet header+crc and provide a mechanism for @@ -719,7 +719,7 @@ Dave 1. Added VMScluster support (thanks to Mark Pizzolato) 2. Verified VAX remote boot functionality (>>>B XQA0) 3. Added major performance enhancements (thanks to Mark Pizzolato again) - 4. Changed _DEBUG tracers to XQ_DEBUG and ETH_DEBUG + 4. Changed _DEBUG tracers to XQ_DEBUG and ETH_DEBUG 5. Added local packet processing 6. Added system id broadcast diff --git a/CMakeLists.txt b/CMakeLists.txt index beeda95d..120da396 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -96,7 +96,7 @@ if (NOT CMAKE_CONFIGURATION_TYPES) endif () # SIMH_SYSTEM_ID: Roughly analogous to the autoconf system triple. Used (almost exclusively) -# as part of the depedencies' top-level directory name. +# as part of the dependencies' top-level directory name. set(SIMH_SYSTEM_ID ${CMAKE_SYSTEM_NAME}) string(REPLACE "." ";" version_list ${CMAKE_SYSTEM_VERSION}) list(GET version_list 0 version_major) @@ -163,9 +163,9 @@ if (NOT DEFINED MAC_UNIVERSAL) else () set(MAC_UNIVERSAL_OPTVAL ${MAC_UNIVERSAL}) if (MAC_UNIVERSAL_OPTVAL) - message(STATUS "macOS unversal binaries WILL BE BUILT.") + message(STATUS "macOS universal binaries WILL BE BUILT.") else () - message(STATUS "macOS unversal binaries NOT WILL BE BUILT.") + message(STATUS "macOS universal binaries NOT WILL BE BUILT.") endif () endif () @@ -247,7 +247,7 @@ set(DEP_CMAKE_ARGS "-Wno-dev" "--no-warn-unused-cli") if (NOT (USING_VCPKG OR NO_DEP_BUILD) AND NOT EXISTS ${SIMH_DEP_TOPDIR}) message(STATUS "Creating dependency library directory hierarchy") execute_process( - COMMAND ${CMAKE_COMMAND} -E make_directory ${SIMH_DEP_TOPDIR} ${SIMH_DEP_TOPDIR}/include ${SIMH_DEP_TOPDIR}/lib + COMMAND ${CMAKE_COMMAND} -E make_directory ${SIMH_DEP_TOPDIR} ${SIMH_DEP_TOPDIR}/include ${SIMH_DEP_TOPDIR}/lib ${SIMH_DEP_TOPDIR}/bin WORKING_DIRECTORY ${CMAKE_SOURCE_DIR} ) @@ -297,7 +297,7 @@ include(platform-quirks) # Find packages, arrange for dependency download/compile/install: # -# SIMH_BUILD_DEPS is the list of the dependecies' names, for pretty-printing. +# SIMH_BUILD_DEPS is the list of the dependencies' names, for pretty-printing. # SIMH_DEP_TARGETS is the list of dependency targets' names that we'll actually build. set(SIMH_BUILD_DEPS) diff --git a/README-CMake.md b/README-CMake.md index eacf2dae..18e2403c 100644 --- a/README-CMake.md +++ b/README-CMake.md @@ -5,7 +5,7 @@ - [Why CMake?](#why-cmake) - [Before You Begin Building...](#before-you-begin-building) - [Toolchains and Tools](#toolchains-and-tools) - - [Ninja: "failed recompaction: Permission denied"](#ninja-file-recompation-permission-denied) + - [Ninja: "failed recompaction: Permission denied"](#ninja-file-recompaction-permission-denied) - [Windows XP-compatible/Server 2003 binaries](#windows-xp-compatibleserver-2003-binaries) - [Feature Libraries](#feature-libraries) - [Linux, macOS and MinGW-w64](#linux-macos-and-mingw-w64) @@ -43,7 +43,7 @@ framework. A sample of the supported build environments include: - Unix Makefiles - [MinGW Makefiles][mingw64] - [Ninja][ninja] - - macOS XCode + - macOS Xcode - MS Visual Studio solutions (2015, 2017, 2019, 2022) - IDE build wrappers ([Sublime Text][sublime] and [CodeBlocks][codeblocks]) @@ -189,7 +189,7 @@ to select a 32-bit target architecture and the `v141_xp` toolkit. _VS2022_: Install the `v141_xp` tools -Start the Visual Studio Installler, whether this is a new VS2022 install or +Start the Visual Studio Installer, whether this is a new VS2022 install or modifying an existing installation. - New install @@ -219,7 +219,7 @@ the [command line](#cmake-command-line) or [via the IDE](#xp-compatible-build-vi _VS2019_: Install the `v141_xp` tools. -Start the Visual Studio Installler, whether this is a new VS2019 install or +Start the Visual Studio Installer, whether this is a new VS2019 install or modifying an existing installation. - New installation: Follow the VS 2022 "New install" instructions. The steps are @@ -373,7 +373,7 @@ Setup and Usage: PS C:\...\vcpkg> cd ..\open-simh PS C:\...\open-simh> ``` - Then set the `VCPKG_ROOT` environment variable to the `vcpkg` installaton directory. + Then set the `VCPKG_ROOT` environment variable to the `vcpkg` installation directory. [^1]: `vcpkg` does not support the `v141_xp` toolkit required to compile Windows XP binaries. Windows XP is a target platform that SIMH can hopefully deprecate @@ -1033,11 +1033,11 @@ within the IDE. The walkthrough provides directions for VS 2022 and VS 2019. `x64-Release` configuration. And wait for reconfiguration to finish (again.) 5. Select `Build All` from the `Build` menu, or equivalently chord `Ctrl-Shift-B` - on the keyboard, to start the dependecy feature library superbuild. + on the keyboard, to start the dependency feature library superbuild. - When all dependency feature libraries have been built, the build process __will__ unexpectedly terminate with a _"failed recompaction: Permission - denied"_ error (see [this `ninja` note](#ninja-file-recompation-permission-denied).) + denied"_ error (see [this `ninja` note](#ninja-file-recompaction-permission-denied).) Choose `Delete Cache and Reconfigure` from the `Project` menu. This will cause CMake to reconfigure the project and detect the dependency feature @@ -1141,7 +1141,7 @@ add_simulator(3b2 TEST 3b2) ``` -`add_simulator` is relatively self explanitory: +`add_simulator` is relatively self explanatory: - The first argument is the simulator's executable name: `3b2`. This generates an executable named `3b2` on Unix platforms or `3b2.exe` on Windows. diff --git a/SIMH-V4-status.md b/SIMH-V4-status.md index c97cf982..4e7c439b 100644 --- a/SIMH-V4-status.md +++ b/SIMH-V4-status.md @@ -99,7 +99,7 @@ #### CDC 1700 simulator from John Forecast -#### Hans-Ã…ke Lund has implemented an SCELBI (SCientic-ELectronics-BIology) simulator. +#### Hans-Ã…ke Lund has implemented an SCELBI (SCientific-ELectronics-BIology) simulator. #### IBM 650 simulator from Roberto Sancho Villa @@ -351,7 +351,7 @@ The EXPECT command now exists to provide a means of reacting to simulator output #### Help -The built-in help system provides a heirarchical oriented help command interface. +The built-in help system provides a hierarchical oriented help command interface. In addition, there is explicit support for per device help: HELP dev @@ -600,7 +600,7 @@ This link will return a file called simh-vms-pcap.zip which should be unpacked a $ unzip -a simh-vms-pcap.zip $ rename [.simh-vms-pcap]pcap-vms.dir [] -The PCAP-VMS components are presumed (by the descript.mms file) to be +The PCAP-VMS components are presumed (by the descrip.mms file) to be located in a directory at the same level as the directory containing the simh source files. For example, if these exist here: diff --git a/build_vstudio.bat b/build_vstudio.bat index 5b7f4669..9046e901 100644 --- a/build_vstudio.bat +++ b/build_vstudio.bat @@ -4,7 +4,7 @@ :: If this procedure is not invoked from a Developer command prompt :: then the VS2008 tools are preferred if VS2008 is installed, :: otherwise the installed Visual Studio tools will be used -:: prefering newer Visual Studio versions over older ones. +:: preferring newer Visual Studio versions over older ones. :: :: If this procedure is invoked from a Developer command prompt :: then the tool chain provided with the command prompt is used diff --git a/descrip.mms b/descrip.mms index 3534466e..1e6d2a26 100644 --- a/descrip.mms +++ b/descrip.mms @@ -10,7 +10,7 @@ # HP C V7.3-009-48GBT (AXP), HP C V7.2-001 (IA64) and v6.4-005(VAX). # # Notes: On VAX, the PDP-10, Eclipse, IBM 7094 and BESM6 simulators will -# not be built due to the fact that INT64 is required for these +# not be built due to the fact that INT64 is required for these # simulators. # # This build script will accept the following build options. @@ -25,9 +25,9 @@ # ECLIPSE Just Build The Data General Eclipse. # GRI Just Build The GRI Corporation GRI-909. # LGP Just Build The Royal-McBee LGP-30. -# H316 Just Build The Honewell 316/516. -# HP2100 Just Build The Hewlett-Packard HP-2100. -# HP3000 Just Build The Hewlett-Packard HP-3000. +# H316 Just Build The Honeywell 316/516. +# HP2100 Just Build The Hewlett-Packard HP-2100. +# HP3000 Just Build The Hewlett-Packard HP-3000. # I1401 Just Build The IBM 1401. # I1620 Just Build The IBM 1620. # I7094 Just Build The IBM 7094. @@ -75,22 +75,22 @@ # VAX8600 Just Build The DEC VAX8600. # CLEAN Will Clean Files Back To Base Kit. # -# To build with debugging enabled (which will also enable traceback +# To build with debugging enabled (which will also enable traceback # information) use.. # # MMK/MACRO=(DEBUG=1) # # This will produce an executable named {Simulator}-{I64|VAX|AXP}-DBG.EXE # -# To build on older Alpha VMS platforms, SIM_ASYNCH_IO must be disabled. +# To build on older Alpha VMS platforms, SIM_ASYNCH_IO must be disabled. # use.. # # MMK/MACRO=(NOASYNCH=1) # -# On AXP and IA64 the VMS PCAP components are built and used to provide +# On AXP and IA64 the VMS PCAP components are built and used to provide # network support for the VAX and PDP11 simulators. # -# The AXP PCAP components can only be built using a version of the +# The AXP PCAP components can only be built using a version of the # DEC/Compaq/HP Compiler version V6.5-001 or later. To build using an # older compiler, networking support must be disabled. Use... # @@ -716,7 +716,7 @@ S3_OPTIONS = /INCL=($(SIMH_DIR),$(S3_DIR))/DEF=($(CC_DEFS)) # SDS_DIR = SYS$DISK:[.SDS] SDS_LIB = $(LIB_DIR)SDS-$(ARCH).OLB -SDS_SOURCE = $(SDS_DIR)SDS_CPU.C,$(SDS_DIR)SDS_DRM.C,$(SDS_DIR)SDS_DSK.C,\ +SDS_SOURCE = $(SDS_DIR)SDS_CPU.C,$(SDS_DIR)SDS_DRM.C,$(SDS_DIR)SDS_DSK.C,\ $(SDS_DIR)SDS_IO.C,$(SDS_DIR)SDS_LP.C,$(SDS_DIR)SDS_MT.C,\ $(SDS_DIR)SDS_MUX.C,$(SDS_DIR)SDS_RAD.C,$(SDS_DIR)SDS_STDDEV.C,\ $(SDS_DIR)SDS_SYS.C,$(SDS_DIR)SDS_CR.C,$(SDS_DIR)SDS_CP.C @@ -1431,7 +1431,7 @@ ALL : ALTAIR GRI H316 HP2100 I1401 I1620 IBM1130 ID16 ID32 \ $! No further actions necessary .ENDIF -CLEAN : +CLEAN : $! $! Clean out all targets and building Remnants $! @@ -1578,7 +1578,7 @@ $(ECLIPSE_LIB) : $(ECLIPSE_SOURCE) # # We Are On VAX And Due To The Use of INT64 We Can't Build It. # -$(ECLIPSE_LIB) : +$(ECLIPSE_LIB) : $! Due To The Use Of INT64 We Can't Build The $! $(MMS$TARGET) Library On VAX. .ENDIF @@ -1832,19 +1832,19 @@ $(KI10_LIB) : $(KI10_SOURCE) # # We Are On VAX And Due To The Use of INT64 We Can't Build It. # -$(PDP10_LIB) : +$(PDP10_LIB) : $! Due To The Use Of INT64 We Can't Build The $! $(MMS$TARGET) Library On VAX. -$(PDP6_LIB) : +$(PDP6_LIB) : $! Due To The Use Of INT64 We Can't Build The $! $(MMS$TARGET) Library On VAX. -$(KA10_LIB) : +$(KA10_LIB) : $! Due To The Use Of INT64 We Can't Build The $! $(MMS$TARGET) Library On VAX. -$(KI10_LIB) : +$(KI10_LIB) : $! Due To The Use Of INT64 We Can't Build The $! $(MMS$TARGET) Library On VAX. .ENDIF @@ -1955,7 +1955,7 @@ $(BESM6_LIB) : $(BESM6_SOURCE) # # We Are On VAX And Due To The Use of INT64 We Can't Build It. # -$(BESM6_LIB) : +$(BESM6_LIB) : $! Due To The Use Of INT64 We Can't Build The $! $(MMS$TARGET) Library On VAX. .ENDIF @@ -1978,7 +1978,7 @@ $(B5500_LIB) : $(B5500_SOURCE) # # We Are On VAX And Due To The Use of INT64 We Can't Build It. # -$(B5500_LIB) : +$(B5500_LIB) : $! Due To The Use Of INT64 We Can't Build The $! $(MMS$TARGET) Library On VAX. .ENDIF @@ -2001,7 +2001,7 @@ $(CDC1700_LIB) : $(CDC1700_SOURCE) # # We Are On VAX And Due To The Use of INT64 We Can't Build It. # -$(CDC1700_LIB) : +$(CDC1700_LIB) : $! Due To The Use Of INT64 We Can't Build The $! $(MMS$TARGET) Library On VAX. .ENDIF @@ -2499,7 +2499,7 @@ $(I7094_LIB) : $(I7094_SOURCE) # # We Are On VAX And Due To The Use of INT64 We Can't Build It. # -$(I7094_LIB) : +$(I7094_LIB) : $! Due To The Use Of INT64 We Can't Build The $! $(MMS$TARGET) Library On VAX. .ENDIF @@ -2519,7 +2519,7 @@ ATT3B2 : $(BIN_DIR)ATT3B2-$(ARCH).EXE # Else We Are On VAX And Tell The User We Can't Build On VAX # Due To The Use Of INT64. # -ATT3B2 : +ATT3B2 : $! Sorry, Can't Build $(BIN_DIR)ATT3B2-$(ARCH).EXE Simulator $! Because It Requires The Use Of INT64. .ENDIF @@ -2557,7 +2557,7 @@ ALTAIRZ80 : $(BIN_DIR)ALTAIRZ80-$(ARCH).EXE # Else We Are On VAX And Tell The User We Can't Build On VAX # Due To The Use Of INT64. # -ALTAIRZ80 : +ALTAIRZ80 : $! Sorry, Can't Build $(BIN_DIR)ALTAIRZ80-$(ARCH).EXE Simulator $! Because It Requires The Use Of INT64. .ENDIF @@ -2583,7 +2583,7 @@ ECLIPSE : $(BIN_DIR)ECLIPSE-$(ARCH).EXE # Else We Are On VAX And Tell The User We Can't Build On VAX # Due To The Use Of INT64. # -ECLIPSE : +ECLIPSE : $! Sorry, Can't Build $(BIN_DIR)ECLIPSE-$(ARCH).EXE Simulator $! Because It Requires The Use Of INT64. .ENDIF @@ -2847,19 +2847,19 @@ $(BIN_DIR)PDP10-KI-$(ARCH).EXE : $(SIMH_MAIN) $(SIMH_NONET_LIB) $(PCAP_LIBD) $(K # Else We Are On VAX And Tell The User We Can't Build On VAX # Due To The Use Of INT64. # -PDP10 : +PDP10 : $! Sorry, Can't Build $(BIN_DIR)PDP10-$(ARCH).EXE Simulator $! Because It Requires The Use Of INT64. -PDP6 : +PDP6 : $! Sorry, Can't Build $(BIN_DIR)PDP6-$(ARCH).EXE Simulator $! Because It Requires The Use Of INT64. -PDP10-KA : +PDP10-KA : $! Sorry, Can't Build $(BIN_DIR)PDP10-KA-$(ARCH).EXE Simulator $! Because It Requires The Use Of INT64. -PDP10-KI : +PDP10-KI : $! Sorry, Can't Build $(BIN_DIR)PDP10-KI-$(ARCH).EXE Simulator $! Because It Requires The Use Of INT64. .ENDIF @@ -2968,7 +2968,7 @@ $(BIN_DIR)BESM6-$(ARCH).EXE : $(SIMH_MAIN) $(SIMH_NONET_LIB) $(BESM6_LIB) # Else We Are On VAX And Tell The User We Can't Build On VAX # Due To The Use Of INT64. # -BESM6 : +BESM6 : $! Sorry, Can't Build $(BIN_DIR)BESM6-$(ARCH).EXE Simulator $! Because It Requires The Use Of INT64. .ENDIF @@ -2994,7 +2994,7 @@ $(BIN_DIR)B5500-$(ARCH).EXE : $(SIMH_MAIN) $(SIMH_NONET_LIB) $(B5500_LIB) # Else We Are On VAX And Tell The User We Can't Build On VAX # Due To The Use Of INT64. # -B5500 : +B5500 : $! Sorry, Can't Build $(BIN_DIR)B5500-$(ARCH).EXE Simulator $! Because It Requires The Use Of INT64. .ENDIF @@ -3020,7 +3020,7 @@ $(BIN_DIR)CDC1700-$(ARCH).EXE : $(SIMH_MAIN) $(SIMH_NONET_LIB) $(CDC1700_LIB) # Else We Are On VAX And Tell The User We Can't Build On VAX # Due To The Use Of INT64. # -CDC1700 : +CDC1700 : $! Sorry, Can't Build $(BIN_DIR)CDC1700-$(ARCH).EXE Simulator $! Because It Requires The Use Of INT64. .ENDIF @@ -3363,7 +3363,7 @@ $(BIN_DIR)I7094-$(ARCH).EXE : $(SIMH_MAIN) $(SIMH_NONET_LIB) $(I7094_LIB) # Else We Are On VAX And Tell The User We Can't Build On VAX # Due To The Use Of INT64. # -I7094 : +I7094 : $! Sorry, Can't Build $(BIN_DIR)I7094-$(ARCH).EXE Simulator $! Because It Requires The Use Of INT64. .ENDIF @@ -3375,9 +3375,9 @@ $(PCAP_VCI) : $(PCAP_VCMDIR)PCAPVCM.EXE $! $! Installing the PCAP VCI Execlet in SYS$LOADABLE_IMAGES $! - $ COPY $(PCAP_VCMDIR)PCAPVCM.EXE SYS$COMMON:[SYS$LDR]PCAPVCM.EXE + $ COPY $(PCAP_VCMDIR)PCAPVCM.EXE SYS$COMMON:[SYS$LDR]PCAPVCM.EXE -$(PCAP_VCMDIR)PCAPVCM.EXE : $(PCAP_VCM_SOURCES) +$(PCAP_VCMDIR)PCAPVCM.EXE : $(PCAP_VCM_SOURCES) $! $! Building The PCAP VCI Execlet $! diff --git a/helpx b/helpx index d3b79680..62b93522 100644 --- a/helpx +++ b/helpx @@ -226,7 +226,7 @@ while( ) { next; } elsif ($tok eq 'word' && $val =~ /^fprint_(set|show|reg)_help(?:_ex)?$/) { my %alt = ( set => "\$Set commands", - show => "\$Show commmands", + show => "\$Show commands", reg => "\$Registers" ); $b .= "/* Use \"$alt{$1}\" topic instead:\n"; do { @@ -272,7 +272,7 @@ while( ) { " The SET commands for the device will automagically display above\n" " this line. Add any special notes.\n" "2 OSNAME1\n" - " Operating System-specif configuration details\n" + " Operating System-specific configuration details\n" " If the device needs special configuration for a particular OS, a subtopic\n" " for each such OS goes here.\n" "2 Files\n" @@ -299,7 +299,7 @@ while( ) { "1 Related Devices\n" " If devices are configured or used together, list the other devices here.\n" " E.G. The DEC KMC/DUP are two hardware devices that are closely related;\n" - " The KMC controlls the DUP on behalf of the OS.\n" + " The KMC controls the DUP on behalf of the OS.\n" /* **** Your converted help text starts hare **** */ diff --git a/makefile b/makefile index 17642a81..45620509 100644 --- a/makefile +++ b/makefile @@ -19,21 +19,21 @@ # In general, the logic below will detect and build with the available # features which the host build environment provides. # -# Dynamic loading of libpcap is the preferred default behavior if pcap.h +# Dynamic loading of libpcap is the preferred default behavior if pcap.h # is available at build time. Support to statically linking against libpcap -# is deprecated and may be removed in the future. Static linking against -# libpcap can be enabled if GNU make is invoked with USE_NETWORK=1 on the +# is deprecated and may be removed in the future. Static linking against +# libpcap can be enabled if GNU make is invoked with USE_NETWORK=1 on the # command line. # -# Some platforms may not have vendor supplied libpcap available. HP-UX is +# Some platforms may not have vendor supplied libpcap available. HP-UX is # one such example. The packages which are available for this platform -# install include files and libraries in user specified directories. In -# order for this makefile to locate where these components may have been -# installed, gmake should be invoked with LPATH=/usr/lib:/usr/local/lib +# install include files and libraries in user specified directories. In +# order for this makefile to locate where these components may have been +# installed, gmake should be invoked with LPATH=/usr/lib:/usr/local/lib # defined (adjusted as needed depending on where they may be installed). # -# In the unlikely event that someone wants to build network capable -# simulators without networking support, invoking GNU make with +# In the unlikely event that someone wants to build network capable +# simulators without networking support, invoking GNU make with # NONETWORK=1 on the command line will do the trick. # # By default, video support is enabled if the SDL2 development @@ -44,49 +44,49 @@ # If debugging is desired, then GNU make can be invoked with # DEBUG=1 on the command line. # -# When building compiler optimized binaries with the gcc or clang -# compilers, invoking GNU make with LTO=1 on the command line will -# cause the build to use Link Time Optimization to maximally optimize -# the results. Link Time Optimization can report errors which aren't -# otherwise detected and will also take significantly longer to +# When building compiler optimized binaries with the gcc or clang +# compilers, invoking GNU make with LTO=1 on the command line will +# cause the build to use Link Time Optimization to maximally optimize +# the results. Link Time Optimization can report errors which aren't +# otherwise detected and will also take significantly longer to # complete. Additionally, non debug builds default to build with an -# optimization level of -O2. This optimization level can be changed -# by invoking GNU OPTIMIZE=-O3 (or whatever optimize value you want) +# optimization level of -O2. This optimization level can be changed +# by invoking GNU OPTIMIZE=-O3 (or whatever optimize value you want) # on the command line if desired. # -# The default setup will fail simulator build(s) if the compile -# produces any warnings. These should be cleaned up before new -# or changd code is accepted into the code base. This option +# The default setup will fail simulator build(s) if the compile +# produces any warnings. These should be cleaned up before new +# or changed code is accepted into the code base. This option # can be overridden if GNU make is invoked with WARNINGS=ALLOWED # on the command line. # -# The default build will run per simulator tests if they are -# available. If building without running tests is desired, -# then GNU make should be invoked with TESTS=0 on the command +# The default build will run per simulator tests if they are +# available. If building without running tests is desired, +# then GNU make should be invoked with TESTS=0 on the command # line. # # Default test execution will produce summary output. Detailed -# test output can be produced if GNU make is invoked with +# test output can be produced if GNU make is invoked with # TEST_ARG=-v on the command line. # -# simh project support is provided for simulators that are built with -# dependent packages provided with the or by the operating system -# distribution OR for platforms where that isn't directly available -# (OS X/macOS) by packages from specific package management systems (MacPorts -# or Homebrew). Users wanting to build simulators with locally built -# dependent packages or packages provided by an unsupported package -# management system may be able to override where this procedure looks -# for include files and/or libraries. Overrides can be specified by define -# exported environment variables or GNU make command line arguments which -# specify INCLUDES and/or LIBRARIES. +# simh project support is provided for simulators that are built with +# dependent packages provided with the or by the operating system +# distribution OR for platforms where that isn't directly available +# (OS X/macOS) by packages from specific package management systems (MacPorts +# or Homebrew). Users wanting to build simulators with locally built +# dependent packages or packages provided by an unsupported package +# management system may be able to override where this procedure looks +# for include files and/or libraries. Overrides can be specified by define +# exported environment variables or GNU make command line arguments which +# specify INCLUDES and/or LIBRARIES. # Each of these, if specified, must be the complete list include directories -# or library directories that should be used with each element separated by +# or library directories that should be used with each element separated by # colons. (i.e. INCLUDES=/usr/include/:/usr/local/include/:...) -# If this doesn't work for you and/or you're interested in using a different +# If this doesn't work for you and/or you're interested in using a different # ToolChain, you're free to solve this problem on your own. Good Luck. # # Some environments may have the LLVM (clang) compiler installed as -# an alternate to gcc. If you want to build with the clang compiler, +# an alternate to gcc. If you want to build with the clang compiler, # invoke make with GCC=clang. # # Internal ROM support can be disabled if GNU make is invoked with @@ -362,7 +362,7 @@ ifeq (${WIN32},) #*nix Environments (&& cygwin) $(shell git log -1 --pretty="SIM_GIT_COMMIT_ID %H$(GIT_EXTRA_FILES)%nSIM_GIT_COMMIT_TIME $(isodate)" >.git-commit-id) endif endif - LTO_EXCLUDE_VERSIONS = + LTO_EXCLUDE_VERSIONS = PCAPLIB = pcap ifeq (agcc,$(findstring agcc,${GCC})) # Android target build? OS_CCDEFS += -D_GNU_SOURCE @@ -585,16 +585,16 @@ ifeq (${WIN32},) #*nix Environments (&& cygwin) LIBEXTSAVE := ${LIBEXT} LIBEXT = a ifneq (,$(call find_lib,pthread)) - AIO_CCDEFS += -DUSE_READER_THREAD -DSIM_ASYNCH_IO + AIO_CCDEFS += -DUSE_READER_THREAD -DSIM_ASYNCH_IO OS_LDFLAGS += -lpthread $(info using libpthread: $(call find_lib,pthread) $(call find_include,pthread)) else ifneq (,$(findstring Haiku,$(OSTYPE))) - AIO_CCDEFS += -DUSE_READER_THREAD -DSIM_ASYNCH_IO + AIO_CCDEFS += -DUSE_READER_THREAD -DSIM_ASYNCH_IO $(info using libpthread: $(call find_include,pthread)) else ifeq (Darwin,$(OSTYPE)) - AIO_CCDEFS += -DUSE_READER_THREAD -DSIM_ASYNCH_IO + AIO_CCDEFS += -DUSE_READER_THREAD -DSIM_ASYNCH_IO OS_LDFLAGS += -lpthread $(info using macOS libpthread: $(call find_include,pthread)) endif @@ -688,7 +688,7 @@ ifeq (${WIN32},) #*nix Environments (&& cygwin) OS_CCDEFS += -DHAVE_GLOB else ifneq (,$(call find_include,fnmatch)) - OS_CCDEFS += -DHAVE_FNMATCH + OS_CCDEFS += -DHAVE_FNMATCH endif endif ifneq (,$(call find_include,sys/mman)) @@ -1285,8 +1285,8 @@ else $(info ***********************************************************************) $(error .) else - $(info ** date. For the most functional and stable features you shoud **) - $(info ** Download the file: **) + $(info ** date. For the most functional and stable features you should **) + $(info ** download the file: **) $(info ** https://github.com/simh/windows-build/archive/windows-build.zip **) $(info ** Extract the windows-build-windows-build folder it contains to **) $(info ** $(abspath ..\) **) @@ -1332,7 +1332,7 @@ else else CFLAGS_O := $(OPTIMIZE) endif - LDFLAGS_O = + LDFLAGS_O = GCC_MAJOR_VERSION = $(firstword $(subst ., ,$(GCC_VERSION))) ifneq (3,$(GCC_MAJOR_VERSION)) ifeq (,$(GCC_OPTIMIZERS_CMD)) @@ -1743,7 +1743,7 @@ H316D = ${SIMHD}/H316 H316 = ${H316D}/h316_stddev.c ${H316D}/h316_lp.c ${H316D}/h316_cpu.c \ ${H316D}/h316_sys.c ${H316D}/h316_mt.c ${H316D}/h316_fhd.c \ ${H316D}/h316_dp.c ${H316D}/h316_rtc.c ${H316D}/h316_imp.c \ - ${H316D}/h316_hi.c ${H316D}/h316_mi.c ${H316D}/h316_udp.c + ${H316D}/h316_hi.c ${H316D}/h316_mi.c ${H316D}/h316_udp.c H316_OPT = -I ${H316D} -D VM_IMPTIP @@ -1795,7 +1795,7 @@ I7090 = ${I7000D}/i7090_cpu.c ${I7000D}/i7090_sys.c ${I7000D}/i7090_chan.c \ ${I7000D}/i7090_cdr.c ${I7000D}/i7090_cdp.c ${I7000D}/i7090_lpr.c \ ${I7000D}/i7000_chan.c ${I7000D}/i7000_mt.c ${I7000D}/i7090_drum.c \ ${I7000D}/i7090_hdrum.c ${I7000D}/i7000_chron.c ${I7000D}/i7000_dsk.c \ - ${I7000D}/i7000_com.c ${I7000D}/i7000_ht.c + ${I7000D}/i7000_com.c ${I7000D}/i7000_ht.c I7090_OPT = -I $(I7000D) -DUSE_INT64 -DI7090 -DUSE_SIM_CARD I7080D = ${SIMHD}/I7000 @@ -1803,7 +1803,7 @@ I7080 = ${I7000D}/i7080_cpu.c ${I7000D}/i7080_sys.c ${I7000D}/i7080_chan.c \ ${I7000D}/i7080_drum.c ${I7000D}/i7000_cdp.c ${I7000D}/i7000_cdr.c \ ${I7000D}/i7000_con.c ${I7000D}/i7000_chan.c ${I7000D}/i7000_lpr.c \ ${I7000D}/i7000_mt.c ${I7000D}/i7000_chron.c ${I7000D}/i7000_dsk.c \ - ${I7000D}/i7000_com.c ${I7000D}/i7000_ht.c + ${I7000D}/i7000_com.c ${I7000D}/i7000_ht.c I7080_OPT = -I $(I7000D) -DI7080 -DUSE_SIM_CARD I7070D = ${SIMHD}/I7000 @@ -1811,7 +1811,7 @@ I7070 = ${I7000D}/i7070_cpu.c ${I7000D}/i7070_sys.c ${I7000D}/i7070_chan.c \ ${I7000D}/i7000_cdp.c ${I7000D}/i7000_cdr.c ${I7000D}/i7000_con.c \ ${I7000D}/i7000_chan.c ${I7000D}/i7000_lpr.c ${I7000D}/i7000_mt.c \ ${I7000D}/i7000_chron.c ${I7000D}/i7000_dsk.c ${I7000D}/i7000_com.c \ - ${I7000D}/i7000_ht.c + ${I7000D}/i7000_ht.c I7070_OPT = -I $(I7000D) -DUSE_INT64 -DI7070 -DUSE_SIM_CARD I7010D = ${SIMHD}/I7000 @@ -1819,20 +1819,20 @@ I7010 = ${I7000D}/i7010_cpu.c ${I7000D}/i7010_sys.c ${I7000D}/i7010_chan.c \ ${I7000D}/i7000_cdp.c ${I7000D}/i7000_cdr.c ${I7000D}/i7000_con.c \ ${I7000D}/i7000_chan.c ${I7000D}/i7000_lpr.c ${I7000D}/i7000_mt.c \ ${I7000D}/i7000_chron.c ${I7000D}/i7000_dsk.c ${I7000D}/i7000_com.c \ - ${I7000D}/i7000_ht.c + ${I7000D}/i7000_ht.c I7010_OPT = -I $(I7010D) -DI7010 -DUSE_SIM_CARD I704D = ${SIMHD}/I7000 I704 = ${I7000D}/i7090_cpu.c ${I7000D}/i7090_sys.c ${I7000D}/i7090_chan.c \ ${I7000D}/i7090_cdr.c ${I7000D}/i7090_cdp.c ${I7000D}/i7090_lpr.c \ - ${I7000D}/i7000_mt.c ${I7000D}/i7090_drum.c ${I7000D}/i7000_chan.c + ${I7000D}/i7000_mt.c ${I7000D}/i7090_drum.c ${I7000D}/i7000_chan.c I704_OPT = -I $(I7000D) -DUSE_INT64 -DI704 -DUSE_SIM_CARD I701D = ${SIMHD}/I7000 I701 = ${I7000D}/i701_cpu.c ${I7000D}/i701_sys.c ${I7000D}/i701_chan.c \ ${I7000D}/i7090_cdr.c ${I7000D}/i7090_cdp.c ${I7000D}/i7090_lpr.c \ - ${I7000D}/i7000_mt.c ${I7000D}/i7090_drum.c ${I7000D}/i7000_chan.c + ${I7000D}/i7000_mt.c ${I7000D}/i7090_drum.c ${I7000D}/i7000_chan.c I701_OPT = -I $(I7000D) -DUSE_INT64 -DI701 -DUSE_SIM_CARD @@ -1860,8 +1860,8 @@ IBM1130 = ${IBM1130D}/ibm1130_cpu.c ${IBM1130D}/ibm1130_cr.c \ ${IBM1130D}/ibm1130_t2741.c IBM1130_OPT = -I ${IBM1130D} ifneq (${WIN32},) -IBM1130_OPT += -DGUI_SUPPORT -lgdi32 ${BIN}ibm1130.o -endif +IBM1130_OPT += -DGUI_SUPPORT -lgdi32 ${BIN}ibm1130.o +endif ID16D = ${SIMHD}/Interdata @@ -1983,7 +1983,7 @@ INTEL_PARTS = \ ${INTELSYSC}/multibus.c \ ${INTELSYSC}/mem.c \ ${INTELSYSC}/sys.c \ - ${INTELSYSC}/zx200a.c + ${INTELSYSC}/zx200a.c INTEL_MDSD = ${INTELSYSD}/Intel-MDS @@ -2008,7 +2008,7 @@ IBMPCXT = ${IBMPCXTC}/i8088.c ${IBMPCXTD}/ibmpcxt_sys.c \ ${IBMPCXTC}/i8253.c ${IBMPCXTC}/i8259.c \ ${IBMPCXTC}/i8255.c ${IBMPCXTD}/ibmpcxt.c \ ${IBMPCXTC}/pceprom.c ${IBMPCXTC}/pcram8.c \ - ${IBMPCXTC}/pcbus.c ${IBMPCXTC}/i8237.c + ${IBMPCXTC}/pcbus.c ${IBMPCXTC}/i8237.c IBMPCXT_OPT = -I ${IBMPCXTD} @@ -2044,7 +2044,7 @@ BESM6_OPT = -I ${BESM6D} -DUSE_INT64 $(BESM6_PANEL_OPT) PDP6D = ${SIMHD}/PDP10 ifneq (,${DISPLAY_OPT}) - PDP6_DISPLAY_OPT = + PDP6_DISPLAY_OPT = endif PDP6 = ${PDP6D}/kx10_cpu.c ${PDP6D}/kx10_sys.c ${PDP6D}/kx10_cty.c \ ${PDP6D}/kx10_lp.c ${PDP6D}/kx10_pt.c ${PDP6D}/kx10_cr.c \ @@ -2057,7 +2057,7 @@ PDP6_OPT = -DPDP6=1 -DUSE_INT64 -I ${PDP6D} -DUSE_SIM_CARD ${DISPLAY_OPT} ${PDP6 KA10D = ${SIMHD}/PDP10 ifneq (,${DISPLAY_OPT}) - KA10_DISPLAY_OPT = + KA10_DISPLAY_OPT = endif KA10 = ${KA10D}/kx10_cpu.c ${KA10D}/kx10_sys.c ${KA10D}/kx10_df.c \ ${KA10D}/kx10_dp.c ${KA10D}/kx10_mt.c ${KA10D}/kx10_cty.c \ @@ -2084,7 +2084,7 @@ endif KI10D = ${SIMHD}/PDP10 ifneq (,${DISPLAY_OPT}) -KI10_DISPLAY_OPT = +KI10_DISPLAY_OPT = endif KI10 = ${KI10D}/kx10_cpu.c ${KI10D}/kx10_sys.c ${KI10D}/kx10_df.c \ ${KI10D}/kx10_dp.c ${KI10D}/kx10_mt.c ${KI10D}/kx10_cty.c \ @@ -2191,12 +2191,12 @@ SAGE = ${SAGED}/sage_cpu.c ${SAGED}/sage_sys.c ${SAGED}/sage_stddev.c \ ${SAGED}/sage_cons.c ${SAGED}/sage_fd.c ${SAGED}/sage_lp.c \ ${SAGED}/m68k_cpu.c ${SAGED}/m68k_mem.c ${SAGED}/m68k_scp.c \ ${SAGED}/m68k_parse.tab.c ${SAGED}/m68k_sys.c \ - ${SAGED}/i8251.c ${SAGED}/i8253.c ${SAGED}/i8255.c ${SAGED}/i8259.c ${SAGED}/i8272.c + ${SAGED}/i8251.c ${SAGED}/i8253.c ${SAGED}/i8255.c ${SAGED}/i8259.c ${SAGED}/i8272.c SAGE_OPT = -I ${SAGED} -DHAVE_INT64 PDQ3D = ${SIMHD}/PDQ-3 PDQ3 = ${PDQ3D}/pdq3_cpu.c ${PDQ3D}/pdq3_sys.c ${PDQ3D}/pdq3_stddev.c \ - ${PDQ3D}/pdq3_mem.c ${PDQ3D}/pdq3_debug.c ${PDQ3D}/pdq3_fdc.c + ${PDQ3D}/pdq3_mem.c ${PDQ3D}/pdq3_debug.c ${PDQ3D}/pdq3_fdc.c PDQ3_OPT = -I ${PDQ3D} # @@ -2213,7 +2213,7 @@ ALL = pdp1 pdp4 pdp7 pdp8 pdp9 pdp15 pdp11 pdp10 \ swtp6800mp-a swtp6800mp-a2 tx-0 ssem b5500 intel-mds \ scelbi 3b2 3b2-700 i701 i704 i7010 i7070 i7080 i7090 \ sigma uc15 pdp10-ka pdp10-ki pdp10-kl pdp10-ks pdp6 i650 \ - imlac tt2500 sel32 + imlac tt2500 sel32 all : ${ALL} @@ -2228,7 +2228,7 @@ else if exist BIN rmdir /s /q BIN endif -${BUILD_ROMS} : +${BUILD_ROMS} : ${MKDIRBIN} ifeq (${WIN32},) @if ${TEST} \( ! -e $@ \) -o \( sim_BuildROMs.c -nt $@ \) ; then ${CC} sim_BuildROMs.c ${CC_OUTSPEC}; fi @@ -2864,7 +2864,7 @@ endif b5500 : ${BIN}b5500${EXE} -${BIN}b5500${EXE} : ${B5500} ${SIM} +${BIN}b5500${EXE} : ${B5500} ${SIM} ${MKDIRBIN} ${CC} ${B5500} ${SIM} ${B5500_OPT} ${CC_OUTSPEC} ${LDFLAGS} ifneq (,$(call find_test,${B5500D},b5500)) @@ -2874,7 +2874,7 @@ endif 3b2-400 : 3b2 3b2 : ${BIN}3b2${EXE} - + ${BIN}3b2${EXE} : ${ATT3B2M400} ${SIM} ${MKDIRBIN} ${CC} ${ATT3B2M400} ${SIM} ${ATT3B2M400_OPT} ${CC_OUTSPEC} ${LDFLAGS} @@ -2898,7 +2898,7 @@ endif i7090 : ${BIN}i7090${EXE} -${BIN}i7090${EXE} : ${I7090} ${SIM} +${BIN}i7090${EXE} : ${I7090} ${SIM} ${MKDIRBIN} ${CC} ${I7090} ${SIM} ${I7090_OPT} ${CC_OUTSPEC} ${LDFLAGS} ifneq (,$(call find_test,${I7000D},i7090)) @@ -2907,7 +2907,7 @@ endif i7080 : ${BIN}i7080${EXE} -${BIN}i7080${EXE} : ${I7080} ${SIM} +${BIN}i7080${EXE} : ${I7080} ${SIM} ${MKDIRBIN} ${CC} ${I7080} ${SIM} ${I7080_OPT} ${CC_OUTSPEC} ${LDFLAGS} ifneq (,$(call find_test,${I7080D},i7080)) @@ -2916,7 +2916,7 @@ endif i7070 : ${BIN}i7070${EXE} -${BIN}i7070${EXE} : ${I7070} ${SIM} +${BIN}i7070${EXE} : ${I7070} ${SIM} ${MKDIRBIN} ${CC} ${I7070} ${SIM} ${I7070_OPT} ${CC_OUTSPEC} ${LDFLAGS} ifneq (,$(call find_test,${I7070D},i7070)) @@ -2925,7 +2925,7 @@ endif i7010 : ${BIN}i7010${EXE} -${BIN}i7010${EXE} : ${I7010} ${SIM} +${BIN}i7010${EXE} : ${I7010} ${SIM} ${MKDIRBIN} ${CC} ${I7010} ${SIM} ${I7010_OPT} ${CC_OUTSPEC} ${LDFLAGS} ifneq (,$(call find_test,${I7010D},i7010)) @@ -2934,7 +2934,7 @@ endif i704 : ${BIN}i704${EXE} -${BIN}i704${EXE} : ${I704} ${SIM} +${BIN}i704${EXE} : ${I704} ${SIM} ${MKDIRBIN} ${CC} ${I704} ${SIM} ${I704_OPT} ${CC_OUTSPEC} ${LDFLAGS} ifneq (,$(call find_test,${I704D},i704)) @@ -2943,7 +2943,7 @@ endif i701 : ${BIN}i701${EXE} -${BIN}i701${EXE} : ${I701} ${SIM} +${BIN}i701${EXE} : ${I701} ${SIM} ${MKDIRBIN} ${CC} ${I701} ${SIM} ${I701_OPT} ${CC_OUTSPEC} ${LDFLAGS} ifneq (,$(call find_test,${I701D},i701)) @@ -2952,7 +2952,7 @@ endif i650 : ${BIN}i650${EXE} -${BIN}i650${EXE} : ${I650} ${SIM} +${BIN}i650${EXE} : ${I650} ${SIM} ${MKDIRBIN} ${CC} ${I650} ${SIM} ${I650_OPT} ${CC_OUTSPEC} ${LDFLAGS} ifneq (,$(call find_test,${I650D},i650)) diff --git a/scp.c b/scp.c index ae53b5e1..7d9ea9cf 100644 --- a/scp.c +++ b/scp.c @@ -32,26 +32,26 @@ REG "maxval" field now determines maximum allowed value 08-Mar-16 RMS Added shutdown flag for detach_all 20-Mar-12 MP Fixes to "SHOW SHOW" commands - 06-Jan-12 JDB Fixed "SHOW DEVICE" with only one enabled unit (Dave Bryan) - 25-Sep-11 MP Added the ability for a simulator built with + 06-Jan-12 JDB Fixed "SHOW DEVICE" with only one enabled unit (Dave Bryan) + 25-Sep-11 MP Added the ability for a simulator built with SIM_ASYNCH_IO to change whether I/O is actually done - asynchronously by the new scp command SET ASYNCH and + asynchronously by the new scp command SET ASYNCH and SET NOASYNCH - 22-Sep-11 MP Added signal catching of SIGHUP and SIGTERM to cause + 22-Sep-11 MP Added signal catching of SIGHUP and SIGTERM to cause simulator STOP. This allows an externally signalled event (i.e. system shutdown, or logoff) to signal a - running simulator of these events and to allow - reasonable actions to be taken. This will facilitate - running a simulator as a 'service' on *nix platforms, - given a sufficiently flexible simulator .ini file. + running simulator of these events and to allow + reasonable actions to be taken. This will facilitate + running a simulator as a 'service' on *nix platforms, + given a sufficiently flexible simulator .ini file. 20-Apr-11 MP Added expansion of %STATUS% and %TSTATUS% in do command - arguments. STATUS is the numeric value of the last + arguments. STATUS is the numeric value of the last command error status and TSTATUS is the text message relating to the last command error status 17-Apr-11 MP Changed sim_rest to defer attaching devices until after device register contents have been restored since some attach activities may reference register contained info. - 29-Jan-11 MP Adjusted sim_debug to: + 29-Jan-11 MP Adjusted sim_debug to: - include the simulator timestamp (sim_gtime) as part of the prefix for each line of output - write complete lines at a time (avoid asynch I/O issues). @@ -360,10 +360,10 @@ return "SCP Event and Internal Command Processing and Testing"; static UNIT scp_test_units[4]; DEVICE sim_scp_dev = { - "SCP-PROCESS", scp_test_units, NULL, NULL, - 4, 0, 0, 0, 0, 0, - NULL, NULL, NULL, NULL, NULL, NULL, - NULL, DEV_NOSAVE|DEV_DEBUG, 0, + "SCP-PROCESS", scp_test_units, NULL, NULL, + 4, 0, 0, 0, 0, 0, + NULL, NULL, NULL, NULL, NULL, NULL, + NULL, DEV_NOSAVE|DEV_DEBUG, 0, scp_debug, NULL, NULL, NULL, NULL, NULL, sim_scp_description}; @@ -449,13 +449,13 @@ t_bool sim_asynch_enabled = FALSE; #endif /* The per-simulator init routine is a weak global that defaults to NULL - The other per-simulator pointers can be overrriden by the init routine + The other per-simulator pointers can be overridden by the init routine WEAK void (*sim_vm_init) (void); This routine is no longer invoked this way since it doesn't work reliably - on all simh supported compile environments. A simulator that needs these - initializations can perform them in the CPU device reset routine which will + on all simh supported compile environments. A simulator that needs these + initializations can perform them in the CPU device reset routine which will always be called before anything else can be processed. */ @@ -695,10 +695,10 @@ return "Step/Next facility"; static UNIT sim_step_unit = { UDATA (&step_svc, UNIT_IDLE, 0) }; DEVICE sim_step_dev = { - "INT-STEP", &sim_step_unit, NULL, NULL, - 1, 0, 0, 0, 0, 0, - NULL, NULL, NULL, NULL, NULL, NULL, - NULL, DEV_NOSAVE, 0, + "INT-STEP", &sim_step_unit, NULL, NULL, + 1, 0, 0, 0, 0, 0, + NULL, NULL, NULL, NULL, NULL, NULL, + NULL, DEV_NOSAVE, 0, NULL, NULL, NULL, NULL, NULL, NULL, sim_int_step_description}; @@ -720,10 +720,10 @@ return SCPE_OK; static UNIT sim_runlimit_unit = { UDATA (&runlimit_svc, UNIT_IDLE, 0) }; DEVICE sim_runlimit_dev = { - "INT-RUNLIMIT", &sim_runlimit_unit, NULL, NULL, - 1, 0, 0, 0, 0, 0, - NULL, NULL, &sim_int_runlimit_reset, NULL, NULL, NULL, - NULL, DEV_NOSAVE, 0, + "INT-RUNLIMIT", &sim_runlimit_unit, NULL, NULL, + 1, 0, 0, 0, 0, 0, + NULL, NULL, &sim_int_runlimit_reset, NULL, NULL, NULL, + NULL, DEV_NOSAVE, 0, NULL, NULL, NULL, NULL, NULL, NULL, sim_int_runlimit_description}; @@ -734,10 +734,10 @@ return "Expect facility"; static UNIT sim_expect_unit = { UDATA (&expect_svc, 0, 0) }; DEVICE sim_expect_dev = { - "INT-EXPECT", &sim_expect_unit, NULL, NULL, - 1, 0, 0, 0, 0, 0, - NULL, NULL, NULL, NULL, NULL, NULL, - NULL, DEV_NOSAVE, 0, + "INT-EXPECT", &sim_expect_unit, NULL, NULL, + 1, 0, 0, 0, 0, 0, + NULL, NULL, NULL, NULL, NULL, NULL, + NULL, DEV_NOSAVE, 0, NULL, NULL, NULL, NULL, NULL, NULL, sim_int_expect_description}; @@ -754,10 +754,10 @@ static REG sim_flush_reg[] = { static UNIT sim_flush_unit = { UDATA (&flush_svc, UNIT_IDLE, 0) }; DEVICE sim_flush_dev = { - "INT-FLUSH", &sim_flush_unit, sim_flush_reg, NULL, - 1, 0, 0, 0, 0, 0, - NULL, NULL, NULL, NULL, NULL, NULL, - NULL, DEV_NOSAVE, 0, + "INT-FLUSH", &sim_flush_unit, sim_flush_reg, NULL, + 1, 0, 0, 0, 0, 0, + NULL, NULL, NULL, NULL, NULL, NULL, + NULL, DEV_NOSAVE, 0, NULL, NULL, NULL, NULL, NULL, NULL, sim_int_flush_description}; @@ -1410,7 +1410,7 @@ static const char simh_help1[] = " RADIX-50 characters.\n" "5-F\n" " The -F switch causes duplicate successive lines of debug NOT to be\n" - " summarized to reduce repetative noise from the debug data stream.\n" + " summarized to reduce repetitive noise from the debug data stream.\n" "5-E\n" " The -E switch causes data blob output to also display the data as\n" " EBCDIC characters.\n" @@ -1575,16 +1575,16 @@ static const char simh_help2[] = "+sh{ow} cons{ole} {arg} show console options\n" "+sh{ow} {-ei} dev{ices} show devices\n" "+sh{ow} fea{tures} show system devices with descriptions\n" - "+sh{ow} m{odifiers} show modifiers for all devices\n" - "+sh{ow} s{how} show SHOW commands for all devices\n" + "+sh{ow} m{odifiers} show modifiers for all devices\n" + "+sh{ow} s{how} show SHOW commands for all devices\n" "+sh{ow} n{ames} show logical names\n" "+sh{ow} q{ueue} show event queue\n" "+sh{ow} ti{me} show simulated time\n" "+sh{ow} th{rottle} show simulation rate\n" - "+sh{ow} a{synch} show asynchronous I/O state\n" + "+sh{ow} a{synch} show asynchronous I/O state\n" "+sh{ow} ve{rsion} show simulator version\n" - "+sh{ow} def{ault} show current directory\n" - "+sh{ow} re{mote} show remote console configuration\n" + "+sh{ow} def{ault} show current directory\n" + "+sh{ow} re{mote} show remote console configuration\n" "+sh{ow} RADIX show device display radix\n" "+sh{ow} DEBUG show device debug flags\n" "+sh{ow} MODIFIERS show device modifiers\n" @@ -1636,7 +1636,7 @@ static const char simh_help2[] = /***************** 80 character line width template *************************/ "2HELP\n" "+h{elp} type this message\n" - "+h{elp} type help for command\n" + "+h{elp} type help for command\n" "+h{elp} type help for device\n" "+h{elp} registers type help for device register variables\n" "+h{elp} attach type help for device specific ATTACH command\n" @@ -1707,7 +1707,7 @@ static const char simh_help2[] = "+The input sequence \"%%%%\" represents a literal \"%%\". All other\n" "+character combinations are rendered literally.\n\n" "+Omitted parameters result in null-string substitutions.\n\n" - "+Tokens preceeded and followed by %% characters are expanded as environment\n" + "+Tokens preceded and followed by %% characters are expanded as environment\n" "+variables, and if an environment variable isn't found then it can be one of\n" "+several special variables:\n\n" "++%%DATE%% yyyy-mm-dd\n" @@ -1747,10 +1747,10 @@ static const char simh_help2[] = "++%%SIM_OSTYPE%% The Operating System running the current simulator\n\n" "+Environment variable lookups are done first with the precise name between\n" "+the %% characters and if that fails, then the name between the %% characters\n" - "+is upcased and a lookup of that valus is attempted.\n\n" + "+is upcased and a lookup of that value is attempted.\n\n" "+The first Space delimited token on the line is extracted in uppercase and\n" "+then looked up as an environment variable. If found it the value is\n" - "+supstituted for the original string before expanding everything else. If\n" + "+substituted for the original string before expanding everything else. If\n" "+it is not found, then the original beginning token on the line is left\n" "+untouched.\n\n" "+Environment variable string substitution:\n\n" @@ -1789,7 +1789,7 @@ static const char simh_help2[] = "++%%~nxI%% - expands the value of %%I%% to a file name and extension only\n\n" " In the above example above %%I%% can be replaced by other\n" " environment variables or numeric parameters to a DO command\n" - " invokation.\n" + " invocation.\n" " Examples:\n\n" "++sim> set env FNAME='xyzzy.ini'\n" "++sim> echo ~FNAME=%%~FNAME%%\n" @@ -1804,7 +1804,7 @@ static const char simh_help2[] = "3GOTO\n" " Commands in a command file execute in sequence until either an error\n" " trap occurs (when a command completes with an error status), or when an\n" - " explict request is made to start command execution elsewhere with the\n" + " explicit request is made to start command execution elsewhere with the\n" " GOTO command:\n\n" "++GOTO