BAD144 info was written correctly if the user answered Y when the disk
image was created, but would not work if SET RPn BADBLOCK was
entered later.
Auto sizing would be potentially wrong if a disk had been created
without writing the BAD144 data. Now, if the disk contains a file system
that information along with the physical container's size is used to
properly auto size the disk.
As reported by Josh Dersch in #358
Read hardware notes:
- While the TCCM error bit is a real flop, it is supposed to reflect
the OR of the TCST error bits at all time, so it is updated on read.
- A read of TCDT while the function is RALL clears DONE.
Write hardware notes:
- The TC11 behaves much more like a traditional DECtape controller
than a typical PDP11 peripheral. In particular, execution is
initiated/controlled by any write to TCCM, rather than setting
the GO (DO) bit. Unless the function is STOP or STOP ALL, writing
TCCM will put the selected tape in motion.
- Writing GO (DO) clears DONE (READY) and the error flops in TCST.
- Writing a 0 to ERROR clears the error flops in TCST. Because it
is write 0 to clear (later controllers used write 1 to clear),
the simulator has to know whether ERROR is actually written.
- STOP ALL ignores select errors. Every other function is rejected
if there is a select error.
- An illegal operation (setting ILO) will stop the selected tape.
- A write of TCDT while the function is RALL, WALL, or WTMK clears
DONE (READY). RALL should not be included, but it saved a gate
not to prevent it.
- Because DONE (READY) may not be clear when an operation completes
and DONE (READY) is set, the DT_SETDONE must test for DONE (READY)
not being already set.
These changes cure a number of issues in RSTS/E, which is more
sensitive to details of emulation than most:
1. Additional KMC opcodes supported for ROMI
2. MCLR now initializes the CSRs per the spec
3. MCLR and ROMI are processed immediately at CSR write rather than
being deferred, because these actions are implemented in the device
hardware rather than in the microprogram.
Previously, the history would always use a register value as source or
destination as if the mode were zero, even when it wasn't. Also, now
the destination value reflects the destination after instruction
execution rather than before.
Rather than use a simh event to increment/decrement the counter register
for each 'clock cycle', compute the time the interrupt will eventually fire
and schedule a single event to deal with that. If the clock counter is
referenced before the interrupt fires, interpolate the value based on the
number of instructions that have actually been executed.
sim_activate_after() is used here, and the time value for the scheduled
activation is a uint32 representing microseconds. The range of values
that the PCLK can programmatically specify could be large enough
to exceed an uint32 when number of microseconds is converted to
a count of instructions. This is an issue that has minimal consequences,
but should be addressed internal to the implementation of
sim_activate_after().
sim> SET XQ MAC=aa:bb:cc:dd:ee:ff{/bits}{>filespec}
where:
- all of the aa:bb:cc:dd:ee:ff values must be hex digits
- bits is the number of bits which are to be taken from the supplied
MAC aa:bb:cc:dd:ee:ff with legal values from 16 to 48 and a default
of 48 bits.
- filespec specifies a file which contains the MAC address to be used
and if it doesn't exist an appropriate generated address will be stored
in this file and a subsequent SET MAC invocation specifying the same
file will use the value stored in the file rather than generating a new
MAC.
As discussed in #317
Multiple devices sharing the same pool of fixed and/or vector addresses
need to properly account for earlier devices that may have already consumed
available fixed addresses or vectors.
These changes facilitate more robust parameter type checking and helps
to identify unexpected coding errors.
Most simulators can now also be compiled with a C++ compiler without
warnings.
Additionally, these changes have also been configured to facilitate easier
backporting of simulator and device simulation modules to run under the
simh v3.9+ SCP framework.
The processing of initialization commands improperly attempted to initialize
all controllers AND these attempts (for controllers beyond 0) referenced
beyond the bounds of the unit array. This problem was reported in issue #309
When a mix of Massbus devices are configured with some enabled and
others disabled, the MBA's need to be allocated and properly configured
in the desired preferred order (RP, TU, RS). On the PDP11, this interacts
with auto-configure since the RH devices are visible in the Unibus I/O
page. On the PDP11 the second Massbus device can only be configured
if the TM device is disabled since the auto-configure assigned vectors
overlap for RHB and TM.
Problem originally reported in #301.
Also make all scheduled timing behaviors consistent and not performed by
the input polling unit which may have different scheduling characteristics
to reflect input speed rate limiting.
The problem has to do with the difference in how the PSW is stored when
the simulator is running (it's all in pieces) or stopped (it's collected in PSW).
cpu_ex is a console routine and expects the PSW to be stored in PSW, but
when history is collected, it's not. In particular, cm (current mode) is in local
variable cm.
cpu_ex with /v calls relocC, which derives the current mode from the
switches:
- if /ksup, use kernel/supervisor/user/previous mode (from PSW); otherwise,
use current mode from PSW
- if /d, use data space; otherwise, use instruction space
relocC is doing current mode i-space, which is what's wanted... except that
it's deriving current mode from PSW, rather than cm, which is where it's stored
while the simulator is running. It's fairly likely that PSW is long obsolete by the
time the history is invoked.
