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.
- Rewrote get_rval, put_rval to support fields within arrays of structures
- REG "size" field now determines access size
- REG "maxval" field now determines maximum allowed value
Merge from v3.12
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>
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.
- General cleanup of codebase
- Fixed condition codes m6800.c from Roberto Sancho Villa
- Add additional FDC lfd-400 from Roberto Sancho Villa
- Add additional OS's (FLEX 1.0, FDOS 1.0, DOS68, MiniDOS, and MiniDOS-MPX)
to software support
- Add additional disk formats to software support dc-4.c from Roberto
Sancho Villa
- Add CPU history
- Fix LOAD/DUMP to support binary and hex
- Fix fprintf_sym to disassemble 6800 code correctly
- Add EXAMINE/DEPOSIT to CPU Memory
- Fixed disasm to space the register
- Add SET_FLAG(IF) to IRQ – fixed error in handling IRQ from
Roberto Sancho Villa
These devices start disabled and will be that way in essentially all
working systems, but there apparently was a DECnet Phase V
support for this device, so it is added to all systems. The DPV
should now be readily testable.
As mentioned in #1152. That PR will fix the DUP device.
This commit is explicitly released from any license restriction
mentioned in the LICENSE.txt of the github.com/simh/simh
master branch changes.
- 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.
The recent change to check that the IMD file track header record is 5
bytes introduced a problem with the end-of-file triggering an open file
error - instead of the previous behaviour where the number of bytes in
the track header was ignored and end-of-file was checked.
I noticed this after fetching and compiling the latest simh altairz80 - it
was refusing to my mount floppy disk IMD image files (which I had made
from 8-inch floppies back in 2006).
```
maxi:s100 tony$ altairz80 cpm3bk.ini
Altair 8800 (Z80) simulator V4.0-0 Current simh git commit id: d3f1ee09
Console escape is CTRL-\
I8272: IMD disk corrupt.
/Users/tony/s100/cpm3bk.ini-58> att disk1a0 /Users/tony/s100/C3BKSIMH.IMD
File open error
```
Looking at the commit history, I saw the change by Howard Harte to
sim_imd.c to "Resolve CID 1502448, 1502460" - presumably to fix the
call to sim_fread() that was not checking the returned result.
Howard's "fix" broke the parsing of the IMD file sector headers by
not checking for an end-of-file condition (at the end of file it
would read 0 bytes and this was now treated as a fatal error - whereas
the old code had a check for end-of-file after the call to sim_fread()).
This commit now detects end-of-file correctly, as well as verifying
the track header is 5 bytes.
ISO files and real CDs exist which don't have ISO 9660 file structure.
These do contain ODS2 file systems since they were produced before
ISO 9660 was standardized and certainly before OS support for ISO
9660 was added. As such, any file named .iso or .ISO will always be
attached read-only since CDs are never naturally writable devices.
