There are a lot of niggling fixes, mostly for incompatibility issues
found by Walter Mueller. Working out the 11/70 behavior is still not
fully done, but it's a lot better than it was, and it passes more of the
11/70 MMU diagnostic.
- Floating point. Now model sensitive in treating MMR1, for 2.11 BSD.
- MMR1 now tracks PC changes on 11/44, 11/45, 11/70, and J11 -(PC) and @-(PC).
- MMR1 is cleared at start of trap sequence on 11/45, 11/70.
- Red stack abort occurs before memory writes on 11/45, 11/70 (no other model has them).
There are 3 variations of RH11:
- 11/70 Massbus adapter AKA RH70.
- All other PDP11 systems had a Massbus adapter known as the RH11.
- Qbus PDP11 systems had a Massbus adapter known as a RH70 emulator.
This commit extends the existing DUP11/DPV11 support to add support for HDLC framing. There
is no requirement to support bit/byte stuffing, so the aim is simply to encapsulate/decapsulate
the datalink frame provided by the host driver.
DDCMP has been regression tested on VMS, RSX and TOPS20, and the HDLC mode was developed
and tested with VAX/VMS DECnet Phase V, only using the HDLC datalink implementation.
In theory this support is sufficient to allow Phase IV/V P.S.I and even VMS/SNA to be used,
but these remain to be demonstrated.
Correct RBUF_GETLINE & RBUF_PUTLINE: these are both sensitive to
modeling DHU vs. DHV; the correct bit mask was not generated for DHU.
Make certain the device presents 16 lines when modeling a DHU.
If the number of lines on a Qbus system has previously been changed
to an odd multiple of and then the bus type changed to Unibus, we
to change the number of lines to a multiple of 16 for the DHU.
If autoconfigure is disabled, either explicitly or implicitly by manual
setting of an ADDRESS or VECTOR, detect devices which don't have
addresses before boot.
Historically, if a configuration file explicitly set either a DEVICE's
ADDRESS or VECTOR, autoconfiguration was immediately disabled.
This change defers disabling autoconfigure until an explicitly setting
of a DEVICE address or VECTOR actually changes what had been previously
configured by autoconfigure.
This commit extends the existing DUP11 support to add simulation for a DPV11 in DDCMP mode.
It has been tested with DECnet-VAX Phase V, which has the only host driver I know of. Note
that you may see a few CRC errors logged with high traffic levels, these are due to a couple of
bugs in the VMS driver, for which I'm looking at developing a patch.
Regression testing has been done on the DUP11 on VMS, RSX and TOPS20, which all seemed to work
as well as previously.
- This involves adding some trailing characters to received DDCMP frames
to meet host driver expectations (simulation then behaves more like a
real synchronous device). 1 SYN is enough for VMS, but RSX needs a few
when there is no abutting frame.
- The VMS driver implements the CRC performance option in section 5.1.2
of the DDCMP spec., and thus relies on receiving a valid character after
the CRC on a received frame.
Coverity flagged one magtape simulator for having fewer case breakouts
than the range of MTSE_x errors, after they were expanded for
MTSE_LEOT (listed as "V4 compatibility") and MTSE_RUNAWAY (for
Dave Bryan's implementation of erase and erase gap).
According to Dave, it turns out that MTSE_RUNAWAY can only be
returned if the magtape simulator supports and implements a density
specification and the ERASE function. The simulators Bob Supnik wrote
don't meet that criteria, so the expanded errors can't be returned.
Simply add a "default" case to the map logic returning SCPE_IERR for
unexpected cases.
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.
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.
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.
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.
