Details in commit to master.
Added preprocessor _WINSOCK_DEPRECATED_NO_WARNINGS to suppress
warnings with VS2022
Backported VS2022 fix for FMA error in pdp18b_fpp from V4.1
Fixed uninitialized warnings fromVS2022.
Added download of external libraries
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.
The code in 3.12-2 is only part of a complete solution and thus merely
hangs the device/processor.
The reverted version wouldn't normally have the problem since the
normally partial code was trying to fix since I/O completion happens
right in dz_wr(). However, the "complete it immediately" model could
logically lose data if the sending side were driven harder than the TMXR
TCP transport was able to deliver data to the TCP session. The easiest
answer is to revert to the earlier v3 DZ code since at least that worked
almost all of the time.
The right answer would be to only signal the transmit completion
interrupt if the transmit didn't end up getting buffered and if it did
get buffered (and not successfully flushed), then schedule a separate
unit to retry the pending output until it actually made it to the TCP
wire. That separate unit would then signal the interrupt for the line
indicated in the CSR and mark CSR_TRDY.
This is more change to realize relatively little value so simply revert
and be done.
- 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.
- In vh_reset(), make certain the number of lines makes sense in the
context of the current bus and adjust if not appropriate; mark each
unit correctly for DHU vs. DHV; mark each unit enabled or disabled as
appropriate; reset the vector length; reset the number of units.
- Retrofit updates from V4 SIMH: (Mark Pizzolato)
- VH_LINES must be set according to the bus type (Unibus: 16,
Qbus: 8).
- Define VH_LINES_ALLOC at 16 lines/unit to reserve the maximum space
for lines.
- SET VH LINES=n is now sensitive to mode; appropriate values are
DHV: 8, 16, 24, 32; DHU: 16, 32, 48, 64
- In fifo_get(), sense immediately when the FIFO empties, rather
than the next time through.
- In vh_setnl(), call vh_reset () to adjust the state of the units
and lines, and invoke auto_config().
Ken's last note led me to look at magtape error handling, and it was
not right. This has resulted in a lot of code changes in sigma_mt.c, but
the changes are mostly mechanical. Instead of trying to be clever and
do channel handling in mt_map_err or at the bottom of the mt_svc
routine, every magtape command now does its own error handling.
This makes the code repetitive, but I hope it is much clearer as a result.
The problems all stem from a single root cause: when an interrupt is
requested - via any one of dozens of mechanisms (uend, normal end,
special request, error, etc), the interrupt routine must be presented
with the full device address, including the unit, which is stored in the
channel data structures. This is so that AIO (acknowledge interrupt)
can retrieve the unit number from the channel data structures and
give it back to the invoking program.
Unfortunately, service routines, error routines, etc were simply using
the base device address, which is good enough for all channel operations
EXCEPT AIO. So the four multi-unit device (RAD, DK, DP, MT) have had
changes to reconstruct the full device address, with unit number, before
any calls into the channel are made.
DP, funnily enough, required the fewest changes. Ken was exactly right
about the need to OR the unit number into dva at the start of the unit
service routine. That had to be done in a few more places where my code
was being lazy.
RAD, DK, MT required many more changes, but they were mostly mechanical.
All references to xx_dib.dva had to be examined and replaced with a full
device address. The full device address had to be reconstructed from the
UNIT pointer and the base device address, through the magic of pointer
arithmetic.
Another sore spot was HIO. HIO stops all the active unit in its tracks
and does a channel UEND on it. The calculation of the unit number in the
UEND was not correct in a few places, notably if DP did a controller reset.
Fixes for the four modules; an updated bug history; and an expanded
design document; are attached.
- TIO status routine always returns DVS_AUTO instead of proper status.
- DP_SEEK definition is off by 1.
- reset does not properly initialize controller, seek threads.
The PDP11 and VAX have length switches - B, W, and (VAX) L - to
override the default parsing of numberic display or input as words
(PDP11) or longwords (VAX CPU) or bytes (VAX byte devices).
This worked fine if every value is filled in. On the PDP11:
sim> ideposit -b 0-3
0: 1
1: 2
2: 3
3: 4
sim>
But if the user skips an input, IDEPOSIT advances by 2, not 1:
sim> ideposit -b 0-3
0: 1
1: (cr)
3: 4
sim>
This change now produces the correct behavior.
PDP-11 simulator V3.12-2
sim> id -b 0-3
0: 1
1:
2: 3
3: 4
sim>
When performing floating point multiplication, the prior code overwrote
an additional word of the floating point fraction with zeros. This is
harmless with standard FP, as the floating variables always have space
for EP-length vars. When doing an EP multiply, this causes a word on
the stack to be zeroed. For the latest Raspbian release, this causes a
segfault as there's no padding past that var on the stack.
This fix, which has been tested against the original crashing code plus
validated using the FPP-8 diagnostics, avoids the overwrite.
