[Simh] SimH: Bugfix in VAX/PDP11 TK50 driver: pinging Bob!

[Jörg Hoppe]

Hi folks, hello Bob,

There's a bug in V3.8-1 pdp11/pdp11_tq.c.
It causes errors on a simulated VAX under Ultrix-32v3 when reading TK50 
installation tapes.
A fix is given below and should go into V3.8-2.

I'd like to combine this with a plea for documentation:
There's nothing about the TMSCP (tape) extensions to MSCP, can somebody 
help?

regards,
Jörg Hoppe


1.) Demonstration of the bug:
----------------------------
1.1) Prerequisites:
- You need an Ultrix-32v3 installation on Simh 3.8-1 VAX.
  I installed from the tape "ULTRIX WS V2.0 SUPPORTED TK50 (DEC 1988, 
AQ-HN73D-BE)",
  maybe 
http://www.bitsavers.org/bits/DEC/vax/ultrix/3.0/Ultrix-32_3.0_supp.tap.gz 
is the same.
  Or call me for an SimH disk image.
- Download the TK50 tape image  
http://www.bitsavers.org/bits/DEC/vax/ultrix/3.0/Ultrix-32_3.0_unsupp.tap.gz

1.2)
Try to install software from TK50 tape "Ultrix-32_3.0_unsupp.tap" with 
"setld".
You will see checksum errors:

sim> set tq0 TK50
sim> att tq0 -r Ultrix-32_3.0_unsupp.tap
sim> boot cpu

... Ultrix boot ...
... Ultrix login ...
... Extract and check tape with "setld" installer ....

# setld -x /dev/rmt0
Extracting ...
Extracting ...
  ....
Extracting ULXMAN030...done.
There were checksum errors on:
         ULXCPM030
         ULXHYPER030
         ULXTOOLS030

Media extraction complete.
#


2) Demonstration: The tape is good, Ultrix is good, the TMSCP driver is bad.
----------------------------------------------------------------------------
2.1) read the tape files in sequence as "setld" does: ERROR!
# mt rewind                                             begin from tape 
start
# mt fsf 13                                             jump to 14th 
tape file
# dd if=/dev/nrmt0h bs=10240 of=tapefile14              read it
7+0 records in
7+0 records out
# dd if=/dev/nrmt0h bs=10240 of=tapefile15.err          and read the 
critical 15th file in sequence
2+0 records in                                          only 2 blocks 
are read!
2+0 records out

2.2) read the critical 14th file with direct positioning: OK!

# mt rewind                                             begin from tape 
start
# mt fsf 14                                             now jump 
directly to critical 15th file
# dd if=/dev/nrmt0h bs=10240 of=tapefile15.ok           read it
3+0 records in                                          now correctly 3 
records are read!
3+0 records out


2.3) Conclusion
If the tape files are read sequentially one by one, some files are 
truncated by one data record (=10240 bytes).
But these files can be read correctly, if we wind the tape to their 
starting position before reading.


3) Analysis
------------
When debugging SimH with
         sim> set console debug=stdout
         sim> set tq debug
we see that the Ultrix-32 TMSCP driver reads a few more data records 
(approx 5) than it needs (cache?).
It backspaces then a few data records to the start of tapefile15.
The TMSCP command for that is 35 "M_OP_POS" (REPOSITION), with modifiers 
"REVERSE" and "OBJECT".
This means: backspace a certain amount of "tape records" (and not "tape 
files").

! But when the Simh "tq" driver backspaces, it counts the tape mark 
between file 14 and file 15
also as an "object". But for TMSCP an "object" is only a "data record" !
So if there are short files on the tape, the backspace will traverse a 
tape mark
and SimH steps one record less backwards than it should.
So it lands on the 2nd data record of the current tape file instead of 
the 1st one.
The next "file read" operation does not read the first block of the file 
... and one
record is missing.
If there are only long files on the tape (> 7 records), this bug does 
not show up.


4) Solution
-----------
The error can easily be fixed in SimH source file pdp11/pdp11_tq.c
The backward repositioning is handled by function "tq_spacer()" (="space 
reverse")
in line 1431. Insert the marked line into it:

-------------------------------------------------------------------------------
uint32 tq_spacer (UNIT *uptr, uint32 cnt, uint32 *skipped, t_bool qrec)
{
t_stat st;
t_mtrlnt tbc;

*skipped = 0;
while (*skipped < cnt) {                                /* loop */
     st = sim_tape_sprecr (uptr, &tbc);                  /* spc rec rev */
     if ((st != MTSE_OK) && (st != MTSE_TMK))            /* real error? */
         return tq_map_status (uptr, st);                /* map status */
     uptr->objp = uptr->objp - 1;                        /* upd obj cnt */
     if ((st == MTSE_TMK) && qrec)                       /* tape mark, 
stop? */
         return ST_TMK;
/***************** BEGIN CHANGE *************************/
if (st != MTSE_TMK)                                   /* do not count 
tape marks: TMSCP obj count != sim_tape object count! */
/***************** END CHANGE *************************/
     *skipped = *skipped + 1;                            /* # TMSCP obj 
skipped */
     }
return ST_SUC;
}
-------------------------------------------------------------------------------

5) Status
-----------
This is just a hack, surely there is more to be done:
- Verify in TMSCP documentation the meaning of tape commands like 
"REPOSITION".
   All I have are some BSD sources (for example 
/usr/src/sys/dev/mscp/mscp.h)
- It is not clear to me what to do with other tape markers (ERASE GAP?).
- the corresponding function "tq_spacef()" ("space forward") has more 
logic in it if it
   encounters a tape mark.  Maybe some of this should go also into 
"tq_spacer()" ?
- The different meanings of a "tape object" in the SimH tape driver and 
in TMSCP may
   have lead to more bugs.



Aren't we having fun?

Regards,
Jöeg Hoppe