This is a global command possibly for folks who have configurations which
always explicitly specify the drive type they want a particular unit to be
before they attach a container to the unit. The side effect of this will
be to avoid the addition of drive type describing meta data to disk
containers.
The key change is the addition of:
When a simulator starts execution, the following sequence of simh command
files are executed if they are found:
1. If a file named simh.ini is located in your HOME directory, it is
executed.
2. If the simh.ini file in your HOME directory isn’t found, a file named
simh.ini in your current working directory is executed if it exists.
3. If the simulator is invoked with any arguments, then the arguments are
presumed to be a command file and possible arguments to that command
file which is executed.
4. If the simulator is invoked without any arguments, then a command file
with the same name as the simulator binary with .ini appended that is
located in the current working directory is executed.
Note, that up to 2 separate command files may be executed on simulator
startup. The simh.ini file allows the user to define local user
preferences that align with their personal goals for simulator execution
across all simulators that may be used on their system.
Steps 3 and 4 were inherited from simh v3.x. Steps 1 and 2 was inspired
by conversations with J. David Bryan in April of 2012. Some how it
never got documented.
At this time:
- The ZAP command exists to remove meta data from containers that
have it. Container files processed by the ZAP command will generally
be restored to the size it was before the addition of the meta data
and the file time stamps will be unchanged.
- Newly created containers get meta data.
- At attach time, containers that don't have meta data, but have
recognized file systems that fit within the drive it is being
attached to get meta data added without changing the file timestamps.
- Containers that don't have meta data and don't have a recognized
file system that is <= the drive size are attached without comment
and without adding meta data as long as the drive is NOT set to
autosize (controllers that support multiple drive types all default to
autosize, which can explicitly be disabled on a drive by drive basis).
- Containers that don't have meta data which are > the drive size can
only be attached read only.
- Containers with meta data can not be attached to a different
controller at all if the container size is smaller than the drive on the
other controller.
- Containers that have meta data can be freely be attached to the
controller that they were attached to when they got the meta data.
If a file system is detected, it will be reported. Otherwise if no
recognized file system is found, the attach will be silent. File
system detection reporting can be suppressed with -Q on the attach
command.
- Containers with meta data can only be attached read only to a different
controller if the container is larger than the drive it is being
attached to.
In the future:
- In general, containers with meta data (or recognized file systems)
will be attachable to MSCP and SCSI controllers, as long as reasonable
sector sizes and file system not requiring interleaving have been found.
- Containers without meta data will only be attachable if autosize
is disabled and the container is <= the size of the drive.
- Explicitly setting a drive type on a unit will implicitly disable
autosizing. If a user wants to set the default drive for a unit
and still allow autosizing they must explicitly set the unit to
autosize after setting the drive type.
Relevant to: #1065, #1059, #1094, #1100, #1118, #1117
Reported by Reindert Voorhorst: if several bytes/words are processed
by the KG11 without intervening status/config register writes, the
wrong answer is produced. The issue is a missing reset of the pulse
count internal register, which should be cleared by a data register
write. The manual (DEC-11-KKGAA-B-D) has the details.
- ZAP with -Z switch now trims all zero sectors, where the default is
to trim zero sectors added beyond the container file size when the
meta data was added.
- Remove file system wording from the skipping autosizing message.
This adds support for the "framer" device, which is a USB-connected
device built around a Raspberry Pico that connects to a synchronous
line, either RS-232 or DEC "integral modem" coax connection. It
implements the framing portion of DDCMP: clock recovery for the
integral modem case, byte sync, and DDCMP frame handling including
CRC. The actual DDCMP protocol state machine, with its handling of
sequencing, timeout and retransmit, etc. is left to the host
software. All the design files for the framer may be found at
https://github.com/pkoning2/ddcmp .
This commit adds code to drive the framer from the TMXR library,
allowing it to be used either from simulated DMC-11 or simulated
DUP-11 devices. Both have been tested, using RSTS/E, RSX-11/M+, and
TOPS-20.
Fixed the one-digit limit on eth<n> device names, the limit is now 2.
When performing floating point multiplication, the prior code overwrote
an additional word of the floating point fraction with zeros. This is
harmless with standard FP, as the floating variables always have space
for EP-length vars. When doing an EP multiply, this causes a word on
the stack to be zeroed. For the latest Raspbian release, this causes a
segfault as there's no padding past that var on the stack.
This fix, which has been tested against the original crashing code plus
validated using the FPP-8 diagnostics, avoids the overwrite.
