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.
Add optional enabling of broadcast address to hash based filter model.
LANCE based devices which use its AUTODIN II based hash generally
match the broadcast address independent of the contents of the
multicast hash.
This change to XQ mostly undoes the prior change to pdp11_xq and
brings the functionality into sim_ether so that it is generally available
for future ethernet devices.
The actual contents of the input ROM binary files and the contents of the
created arrays are unchanged.
Multiple ROM image include files can be included in the same source module
without the need for any #undef BOOT_CODE_SIZE, etc.
- Added a specific drive type RP05 which is the same size as the RP04
but can be distringuished by OS software.
- Restrict SET rpn BADBLOCK to only disk types which actually supported
the DEC Standard 144 bad block table.
- Fixed typo's in help and comments about DEC 044 vs DEC 144 and also
in pdp11_doc and vax780_doc documentation files.
As discussed in #1065
Devices that do single character I/O could be attached to non seekable
host OS devices (tty, pipes, etc.) and thus shouldn't count on fseek()
and ftell(). These DEVICEs on these simulators do single character I/O
and easily can update their POS REGisters to reflect how much data has
been emitted. Changing such a REGister will have no useful effect
when attached to a non seekable file.
Historically this functionality was reimplemented within each
DEVICE simulator often with slightly different implementations
and inconsistencies. Solving this globally within SCP required
changes in many places, but should henceforth be reasonably
managed.
As discussed in #1034
- The REG definitions support having a REGister be pointing at an
element in an array of structures (or UNITs) as long as the element
is a scalar. Something that is not supported is when the element is
already an array (or buffer). The approach used in the TDC device
creates n additional registers each of which points at the individual
array element in each of the structure in the structure array.
- Fix simple REG declarations which didn't fully describe the size of the
underlying storage holding the REG contents in the TDC and VH
DEVICEs.
As reported in #1025
