These are added based on simple drive geometry and size information
without any parameters for bad block management (not used in simulation
anyway).
Additionally, RF drives connected to Qbus systems via a KFQSA. When
connected this way, EACH drive on the DSSI bus appeared to the attached
Qbus system as a separate MSCP controller to the operating system. This
change does not model that connectivity.
Setting a unit to write locked specifically allows only read access.
- If this is done while a unit is attached, it is up to device logic to
limit write activity until it is detached.
- If this is done while a unit is not attached, a subsequent attach
opens the container read only.
Additional UNITs from 4 up to 254 are replicated from Unit 0.
If the UNIT->uname has already been populated, we could leak memory if
it isn't released before copying from the template UNIT.
Split the disk units into groups to match the OS naming convention.
Added unit group multiplexing (partially functional in the OS).
Split debug messages into categories.
Added KS10 support.
CPU Redid instruction decode to improve performance
Triple-I display cleanup.
Normalized end of line to DOS/Unix.
KL10 FE, Cleanup issues with TTY devices hanging simulator..
Fixed errors in RH20 device.
RP and TU drives more independent of RH controller.
UNIT_BUFABLE without UNIT_MUSTBUF means that uptr->filebuf is managed
outside of attach_unit's authority. The buffer copy must always be allocated
if UNIT_BUFABLE is set so that there is space to store the initial loaded copy.
Fix#1122
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.
