Recent analysis of the 2.9BSD kernel revealed that RP11 was
expected to interrupt on control RESET function if IE bit was
also set. Documentation was not very clear of the fact, saying
in one place that RESET+GO does not interrupt (which is not
contradictory with the above because it does not mention IE).
In other place, however, it says that IE always causes interrupt
when DONE is asserted. Thus, since RESET does assert DONE, an
interrupt should be posted if IE is set. The autoconfig binary
from 2.9BSD uses this feature of RP11 to check the presence
of the controller.
Formerly RESET was always clearing RPCS with DONE unconditionally,
and that reset IE as well. This patch makes sure that the IE bit
is preserved, and if set, it posts an interrupt when RESET asserts
DONE.
It looks like disk controllers, which automatically update
disk address (DA) after completion of I/O, are expected to do
so even if there was no data transfer because of I/O errors.
I was studying RSX-11's Error Logger documentation and
examples are clearly offsetting disk addresses backwards
by one when I/O errors are reported by the controller.
Since once the controller has found the DA-specified sector,
the I/O begins regardless of the condition of the sector (bad
or good data) or ability to transfer the contents between the
disk and the memory. If an error occurs (NXM, for instance)
the operation would stop (with the error reported) at the end
of the sector. So if, for example, the bus address register
had a bad address from the get-go, no data would be able to
transfer at all, yet DA should still be updated with DA + 1
once the controller asserts the DONE bit.
This patch makes sure that DA is always advanced when I/O has
actually been commenced.
Issue #294: "apple silicon build problem(s?)": If the "--flavor/-f" flag
is not specified on the command line, then complain loudly, print help
and exit. The script used to default to "Unix Makefiles".
Updates:
- Add missing "-DHAVE_LIBPNG" compiler command line define when the PNG
library is detected/present for screen capture support.
- Add "clang64" to the list of MinGW64 platforms for which the
.travis/deps.sh script can install build dependencies.
- Add PThread4W_FOUND to the condition that sets async I/O for Win32
when using vcpkg for build dependencies.
- Add vs2022-x64, vs2019-x64 and vs2017-x64 build environments to
build 64-bit Windows executables.
- Use simulator AIO only where needed by the simulator (i.e., the
simulator calls/uses AIO_CHECK_EVENT in sim_instr())
- Add "USES_AIO" flag to add_simulator() to mark a simulator that
acutally uses asynchronous I/O.
- Build "_aio" SIMH core library variants that have AIO turned on,
link with the "_aio" variant when a simulator sets USES_AIO.
- Emit a warning message when WITH_ASYNC is False (CMake configuration
option) to notify the user/developer that some functionality will be
crippled.
Affected simulator builds: 3b2 family, PDP-6, PDP-11, VAX family,
IMLAC and TT2500. The makefile and cmake/generate.py also updated
to remain in sync with CMake.
N.B.: Simulators still link with the underlying platform's threading
library. SEL32 requires pthreads or equivalent threading library,
independent of AIO.
- cmake/cmake-builder.sh
- New "--no-aio" flag: Build simulators without async I/O.
- New "--no-aio-intrinsics" flag: Don't build async I/O using compiler
compare-exchange, atomic load intrinsics.
- cmake/cmake-builder.ps1
- New "-noaio" flag: Build simulators without async I/O.
- New "-noaiointrinsics" flag: Don't build async I/O using compiler
compare-exchange, atomic load intrinsics.
CMake 3.28.1 INTERFACE_LINK_LIBRARIES behavior change: The file name
must now be an absolute path. Relative paths no longer accepted.
Internally, SIMH enforces this if CMAKE_VERSION >= 3.19, when REAL_PATH
was first implemented.
The disk type mask width (UNIT_W_DTYPE) was increased to six (6) bits, doubling
the possible number of disk types definable to sixty-four (64).
The RF35 was not entered in either the drv_tab or drv_types tables, causing any
set command issued for the drive type defined after the RF35 -- the RF71 through
RF73, as well as any disk defined after the RF73 -- to act incorrectly.
The ESE20 solid state disk and ESE50 series of solid state disks are
added based on simple drive geometry and size information without any parameters
for bad block management (not that it is used in the simulation anyways). The
ESE50 series drives are labelled as they are in the MSCP specification document,
the Ultrix-32 v4.5 disktab, and the Media Type noted in the "ESE50 SDI Solid
State Disk User Guide" (EK-ESE50-UG.B01):
* ESE50-A: ESE52
* ESE50-B: ESE56
* ESE50-D: ESE58
The RD33 is added based on the geometry of the Microscience HH-1090 hard disk
drive, with the bad block management information calculated from the bad block
information for the other RDxx series drives.
The RX18 is added based on the geometry of the RX180 floppies in the VT-180
"Robin" CP/M system, which are noted in the MSCP specification document as a
possible device. Specific information is taken from the "VT-180 Series Technical
Manual" (EK-VT18X-TM-001).
Running earlier XXDP tests revealed that a technique of concurrent command
initiation and continued housekeeping for the command completion was used in
the old code.
For example, code could initiate a SEEK command for a drive, and knowing that
CS_DONE (and thus, an interrupt) is coming in about 16us, it would then go
ahead and clear a flag, which registers that the interrupt has occurred
(expected to be set to 1 by the ISR). If CS_DONE is set by the implementation
at the function initiation immediately, that would mean that the interrupt
could be triggered before the next instruction, and the flag would be set by
the ISR right away. The main code, however, would proceed with the the flag
clear as the following instruction, thus, never detecting the interrupt down
the road.
Since this technique was in existence, it is better to introduce a delay for
setting CS_DONE in the "fast" initiation commands like SEEK and HOME, to
accommodate the software that was relying on it.
So far, however, no issues were encountered in testing (except one), where
this delay mattered, but it's hard to tell if it would not be needed at all.
All I/O commands always delay CS_DONE already because they were never supposed
to be immediate.
Since the time for CS_DONE in initiation commands was documented at 16us, the
introduced delay is set to 10 instructions, which usually took more than that
to execute. But the interrupt flag clear case would be covered, as well as
the counted waits, which used some 25+-iteration tight loops for "drive ready",
before flagging a time-out (so the delay cannot be longer, either).
It also looks like more modern code never used any such tricks, so for it, it
should not matter if CS_DONE was slightly delayed or not.
17 777 740 - 17 777 742, read-only error address registers,
and 17 777 764, a read-only System ID register,
and are not handled in the CPU70_wr() routine, which means for these
addresses the routine returns NXM, which then translates to "bus timeout"
(no response to address), and then, as a result, trap to vector 4.
That is incorrect, IMO.
These locations are read-only yet the address gets decoded, and even
though writing does not have any effect, the write routine for these
addresses should return SCPE_OK.
Having run the device code thru XXDP and some other OS's and scenarios
rigorously, a bunch of discrepancies were found, which need to be addressed
by this rather extensive patch.
1. Each unit must implement its own "drive status" register, to be able to
track per-drive errors / conditions correctly;
2. Fixed INT_SET() / INT_CLR() in RPCS write function (wrong order of the "if"
conditions);
3. Some behavior was implemented not exactly how it was expected from the real
hardware, such as:
a. Post-I/O register values in RPDA and RPCA (including the corner case of
pack overflow);
b. I/O stacking, which wasn't mentioned in any available documentation, but
only XXDP listings;
c. RESET/IDLE function must be accepted for a "busy" controller;
d. HOME function must always execute, even when "device ready" is not set
(e.g. when SEEK error detected);
e. SEEK incomplete should not respond with "device ready" (however, the
condition can be cleared by HOME, d.);
f. WLOA-induced write-lock violation wasn't reflected in "device status".
4. Some timing was off so that the device worked "too fast" -- this was fixed
(except for the pathological cases when the races are in the actual test
code, and cannot be logically fixed);
5. WLOA setup command bug was fixed;
6. Added more code comments found per the above peculiarities.
PDP11/pdp11_rq.c re-uses ->filebuf as a sector buffer (under the #defined
name rqxb) and allocates it as such. If an RQ disk is detached and
another attached, this buffer would be lost and the pointer reset to
NULL. sim_disk.c would only allocate the buffer if UNIT_BUFABLE is set,
which means to buffer the whole disk. Since this rightly isn't set on RQ
disks, the pointer would remain NULL and segfaults would ensue. See
open-simh issue 274.
add comment about safe re-use of filebuf
* CMake build infrastructure
The squashed commit that builds and packages releases for the SIMH
simulator suite with CMake, version 3.14 or newer.
See README-CMake.md for documentation.
* VIDEO: Fix bug: vid_ready can be used uninitialized.
* VIDEO: Not all events come with a valid windowID.
* PDP11: Fix NG SET TYPE.
The sense of MATCH_CMD is reversed.
* display: Fix bug in NG display controller.
There should be a separate state for each of the eight displays.
* display: Symbolic constant for number of displays.
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.
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.
