Open al20878 opened 10 months ago
UPD:
I downloaded an XXDP+ disk image for RL02, and bootstrapped it. Mounted the TS tape (mentioned above), and tried to issue a DIR
command again: it entered the infinite loop, just the same. So I don't think the issue is with software (or corrupted medium), but rather is with the device.
http://bitsavers.trailing-edge.com/bits/DEC/pdp11/discimages/rl02/xxdp22.rl02.gz
gunzip the image: xxdp_with_1123.dsk
$ pdp11
sim> set cpu 11/70 256
sim> set rl0 rl02
sim> att -r rl0 xxdp_with_1123.dsk
sim> set tm dis
sim> set ts ena
sim> att -r ts BB-F751Q-MC_CZZZ9Q0_MSDP+_1982.tap
sim> b rl
CHMDLD0 XXDP+ DL MONITOR
BOOTED VIA UNIT 0
28K UNIBUS SYSTEM
ENTER DATE (DD-MMM-YY): 6-OCT-93
RESTART ADDR: 152010
THIS IS XXDP+. TYPE "H" OR "H/L" FOR HELP.
.R UPD2
UPD2 .BIN
CHUP2D0 XXDP+ UPD2 UTILITY
RESTART: 003714
*DIR MS0:
ENTRY# FILNAM.EXT DATE LENGTH START
1 MSDP .SAV 16-DEC-82C
2 MSDP .SAV 16-DEC-82C
3 MSDP .SAV 16-DEC-82C
4 MSDP .SAV 16-DEC-82C
...
Cancel with <Ctrl/C>
...
@rms47 this also fails with the v3 PDP11 simulator. Since you wrote the module, and the test cases @al20878 provided seem simple enough, do you want to look into this?
Yes, it reproduces on v3, although I need to add SET TTO 7P to get the output correct on Windows.
Need to turn on tracing and see what is happening on the very first read.
So, here's the process.
Now, here's where things go off the rails. The program issues a POSITION, backspace 1 record, and then repeats 7-8 indefinitely. Why?
The status returned by the read is 0310 - tape moved, tape online, 1600 bpi. There are no errors. The read is returning exactly the same status as the first set of reads that read the whole tape, which worked just fine. Why is it backspacing AFTER it prints the directory entry? Why is it numbering the entries correctly? Both indicate that the program thinks the tape is behaving correctly.
Note that if the modifier on the position operand were <2> instead of <1> (space file forward instead of space record reverse), it would work fine - and it would be exactly the same code as in steps 2-4.
So my working assumption is that the tape is corrupt.
The v4 tape attach logic reads the whole tape at attach time and completely verifies proper forward and backward pointers.
Thank you for the investigation!
So my working assumption is that the tape is corrupt.
It would be a logical explanation if: this tape can be read by XXDP v2 perfectly fine (not as a "system device" but just as medium). If it was corrupt we would have gotten the same outcome with the endless loop, but it works.
You can check that by downloading XXDP v2 from http://bitsavers.trailing-edge.com/bits/DEC/pdp11/xxdp/
I used xxdp-v25-du.dsk.gz (first) and xxdp-v22-du.dsk.gz (second), and in both cases I could list the tape directory successfully. With the same simh configuration as above, the following is the complete log of both sessions:
sim> set tm dis
sim> set ts ena
sim> att -r rq xxdp-v25-du.dsk
%SIM-INFO: RQ0: Unit is read only
sim> att -r ts BB-F751Q-MC_CZZZ9Q0_MSDP+_1982.tap
%SIM-INFO: TS: unit is read only
%SIM-INFO: TS: Tape Image 'BB-F751Q-MC_CZZZ9Q0_MSDP+_1982.tap' scanned as SIMH format
sim> b rq
BOOTING UP XXDP-XM EXTENDED MONITOR
XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM DU0
124KW OF MEMORY
UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.DIR MS0:
ENTRY# FILNAM.EXT DATE LENGTH START VERSION
1 MSDP .SAV 16-DEC-82C
2 HSAAC4.SYS 16-DEC-82 ?.?
3 HSABC0.SYS 16-DEC-82 ?.8
4 HSACC0.SYS 16-DEC-82 ?.?
5 HSADB0.SYS 16-DEC-82 ?.?
6 HUDIB0.SYS 16-DEC-82 ?.?
7 HELP .TXT 16-DEC-82
8 HDMSB0.SYS 16-DEC-82 ?.?
9 HDMMB0.SYS 16-DEC-82 ?.?
10 HDMTB0.SYS 16-DEC-82 ?.?
11 HDDBB0.SYS 16-DEC-82 ?.?
12 HDDDC0.SYS 16-DEC-82 ?.?
13 HDDKB0.SYS 16-DEC-82 ?.?
...
<Ctrl/E>
Simulation stopped, PC: 112404 (MOV (SP)+,R1)
sim> det rq
sim> att -r rq xxdp-v22-du.dsk
%SIM-INFO: RQ0: Unit is read only
sim> b rq
XXDP VERSION 2.2
********************
******************** FIELD SERVICE NOTICE ********************
* -------------------- *
* Some diagnostic programs are incompatible with the *
* XXDP V2 Extended Monitor because of their interaction *
* with the Memory Management Hardware. If you are in doubt *
* about the Extended Monitor compatibility of the programs *
* you wish to run, it is reccommended that you boot the *
* Small Monitor. *
* *
**************************************************************
S - To boot the Small monitor.
X - To boot the Extended monitor.
Type the letter and then press the RETURN key................. X
.D MS0:
ENTRY# FILNAM.EXT DATE LENGTH START VERSION
1 MSDP .SAV 16-DEC-82C
2 HSAAC4.SYS 16-DEC-82 ?.?
3 HSABC0.SYS 16-DEC-82 ?.8
4 HSACC0.SYS 16-DEC-82 ?.?
5 HSADB0.SYS 16-DEC-82 ?.?
6 HUDIB0.SYS 16-DEC-82 ?.?
7 HELP .TXT 16-DEC-82
8 HDMSB0.SYS 16-DEC-82 ?.?
9 HDMMB0.SYS 16-DEC-82 ?.?
10 HDMTB0.SYS 16-DEC-82 ?.?
11 HDDBB0.SYS 16-DEC-82 ?.?
12 HDDDC0.SYS 16-DEC-82 ?.?
13 HDDKB0.SYS 16-DEC-82 ?.?
...
The versions of the modules cannot be correctly shown because the tape is of an earlier version of XXDP (where the versioning did not exactly exist in the form expected by V2) but everything else seems to work as it should.
So I don't think the tape is really corrupt. Structurally, it isn't, for sure. All the forward- and backward- record lengths are definitely correct, and the tape is properly terminated.
My assumption would be that the TS device's response is not in-sync with XXDP MS driver's logic... For example, it assumes the tape takes some time to execute things, and actually keep doing some housekeeping for fetching the response after initiating a command. But the tape responds too fast, so the driver, in fact, inspects the results of its own initialization rather than the tape status (which it just overwrote), so it repeats the action over and over again -- "thinking" the tape was in error. That is one of the possible explanations. In XXDP V2 such a code behavior might have been fixed (everything is prepped before triggering the command), so the obtained status is valid, and the operation progresses...
Like I said, I don't know how the TS device really works (I read about it in the handbook, and it looks it has to communicate a lot through "message packets" in external buffers via just two registers). Maybe there's an action in the implementation, which executes too quickly, posting the result, for example.
You misunderstand what I meant by "corruption." The tape structure is not corrupt; the tape contents are corrupt. There is a data error somewhere that results in generating a POS mod=1 when what is wanted is POS mod=2.
As I said, the D command performs a complete scan of the tape, using a three OP sequence: WCHR, READ, POS file forward. This works perfectly. The listing then uses a three OP sequence: WCHR, READ, POS record reverse. The program thinks that the READ has succeeded; that's why it keeps incrementing the directory number.
Increasing the TS response time from 10 to 100000 shows no change in behavior, but it does slow the listing down considerably. That's because XXDP+ is running with interrupts off (PSW = 340).
XXDP_V2 works fine.
You misunderstand what I meant by "corruption."
On the contrary, I understood you perfectly fine. Since XXDP v2 can list the tape directory, I don't think that the tape contents are corrupt: if it was the case, XXDP v2 would have had the same problem and could not continue -- and that's exactly what I said.
You are correct that XXDP never uses interrupts in the monitor (only in tests). That's documented.
If, using xxpd_with_1123.dsk
as your system drive, you attach the same tape image file to the TM device (instead of TS) and issue the DIR
command when in XXDP+, the tape contents get shown without any issues. That just proves that the tape is not actually corrupt...
$ pdp11
sim> set cpu 11/70 256
sim> set rl0 rl02
sim> att -r rl0 xxdp_with_1123.rl02
sim> att -r tm BB-F751Q-MC_CZZZ9Q0_MSDP+_1982.tap
sim> b rl
CHMDLD0 XXDP+ DL MONITOR
BOOTED VIA UNIT 0
28K UNIBUS SYSTEM
ENTER DATE (DD-MMM-YY): 10-OCT-93
RESTART ADDR: 152010
THIS IS XXDP+. TYPE "H" OR "H/L" FOR HELP.
.R UPD2
UPD2 .BIN
CHUP2D0 XXDP+ UPD2 UTILITY
RESTART: 003714
*DIR MT0:
ENTRY# FILNAM.EXT DATE LENGTH START
1 MSDP .SAV 16-DEC-82C
2 HSAAC4.SYS 16-DEC-82
3 HSABC0.SYS 16-DEC-82
4 HSACC0.SYS 16-DEC-82
5 HSADB0.SYS 16-DEC-82
6 HUDIB0.SYS 16-DEC-82
7 HELP .TXT 16-DEC-82
8 HDMSB0.SYS 16-DEC-82
9 HDMMB0.SYS 16-DEC-82
10 HDMTB0.SYS 16-DEC-82
11 HDDBB0.SYS 16-DEC-82
12 HDDDC0.SYS 16-DEC-82
13 HDDKB0.SYS 16-DEC-82
14 HDDLC0.SYS 16-DEC-82
15 HDDMB0.SYS 16-DEC-82
16 HDDUA0.SYS 16-DEC-82
17 HDDPB0.SYS 16-DEC-82
18 HDDRB0.SYS 16-DEC-82
...
Cancel with <Ctrl/C>
.
Another observation... if you don't mind
Let's take a tape image file, which is known to be good, for example, RSTS v4 installation tape from here:
http://www.rsts.org/autoindex.php?dir=distros/RSTS_tapes/V4A/
the file name is V4AT.ZIP
, and the tape image after unzipping is V4A.TAP
.
I used this tape to actually install and generate the system, so I know it's good, for sure.
Now, manipulating this tape the same way with xxdp_with_1123.dsk
as your system drive, and the tape image attached to the TS device, it enters the same infinite loop in the DIR
command (stuck at the first entry):
*DIR MS0:
ENTRY# FILNAM.EXT DATE LENGTH START
1 MBOT16.BOT 26-MAY-86
2 MBOT16.BOT 26-MAY-86
3 MBOT16.BOT 26-MAY-86
4 MBOT16.BOT 26-MAY-86
5 MBOT16.BOT 26-MAY-86
6 MBOT16.BOT 26-MAY-86
...
but if the TM device is used, the directory lists properly:
*DIR MT0:
ENTRY# FILNAM.EXT DATE LENGTH START
1 MBOT16.BOT 26-MAY-86
2 MDUP .MS 26-MAY-86
3 MDUP .MT 26-MAY-86
4 MDUP .MM 26-MAY-86
5 SWAP .SYS 26-MAY-86
6 RT11BL.SYS 26-MAY-86
7 RT11SJ.SYS 26-MAY-86
8 RT11FB.SYS 26-MAY-86
...
I chose this tape as it is of absolutely legal and compatible format: it uses pure DOS-11 tape structure, and there are no extensions in the file headers (which later were added in RSTS, for example). XXDP, too, was using the DOS-11 tape structure with some extensions (optionally, for some files) but on this tape all those extras are 0s, so they would not cause any unwanted interference.
I agree: finding a different media version of XXDP that exhibits the same problem on the simulated TS11 for DOS-formatted tapes is a smoking gun. Something in the MS "driver" for the XXDP monitor is expecting a different response from the simulated TS11 than it is getting. Without sources, I have no idea what that might be, and it will difficult to find out. It has to be behavior that XXDP V2, and all the operating systems, don't care about.
That's a strange looking tape, though. It certainly is not a "RSTS V4" tape. The description of its contents doesn't jibe with what's shown in the listing file provided. It's vaguely like the description, but only vaguely.
That's a strange looking tape, though
What tape you are talking about? There are two tapes in the talks in this thread. V4A.TAP
is an installation tape, and I used it to install the system. The other tape (with which the discussion started) is an XXDP+ tape, which is also "good".
Without sources
Yes, it's hard to figure out. I'll see if there's any decent disasm or listing available anywhere...
You mentioned V4A.TAP as sourced from www.rsts.org. That page also contains a listing of the tape (the bottom link in the list) which matches the list shown in the discussion here. It's obviously not a RSTS installation tape. It looks faintly like an RT11 installation tape, but it can't be anything from DEC since DEC never put out this sort of combined tape. And while there are some RSTS bits, they certainly don't add up to anything remotely resembling a RSTS kit.
That said, it may well be a perfectly adequate DOS-labeled tape for test purposes. But maybe not. You mentioned later RSTS extensions to the DOS label, though I'm not sure what those would be. (It's not something I know well, but I don't see any extensions in the RSTS/E V10.1 monitor sources.) An actual DEC-issued tape like those found in http://www.bitsavers.org/bits/DEC/pdp11/magtapes/ might be a better test case.
You are correct it's not an official installation tape, and the description of the tape appearing there
http://www.rsts.org/autoindex.php?dir=distros/RSTS_tapes/V4A/
explains what's on it. The point was it is a good medium that is known to work. Any DOS-11 tape would do, for that matter. The official DEC installation tapes for RSTS V4B can be found on the same site:
http://www.rsts.org/autoindex.php?dir=distros/RSTS_tapes/V4B/
The point I was making, and @rms47 agreed, that if the same tape image shows no problem listed when run by another device, it's not a tape's issue, but a device implementation issue in the simulator -- and that's what this issue is about.
P.S. http://www.bitsavers.org/bits/DEC/pdp11/magtapes/ while it's a good source, it does not have early tapes for RSTS, and like I noted above, later RSTS was using the "unused" fields in the DOS file headers on tape to store its own extras (like the file cluster size). While it should not matter, in principle, for XXDP, it's best to have a tape that definitely not using anything like that, for the most fair comparison.
Sorry, off-topic...
You mentioned later RSTS extensions to the DOS label, though I'm not sure what those would be.
@pkoning2 This is from "DEC-11-ORSUA-D-D RSTS System User Guide", 1975:
I see, but that's one (obsolete) utility doing something nonstandard, rather than the OS itself. So you would not see this nonstandard stuff on any distribution tape from DEC (since DEC never used BACKUP format tapes for distribution).
@pkoning2 : everything we are working with here is "obsolete" LOL since there's no way to tell which utility was used to create the tape, I suppose it's best to play it safe assuming it could have been that one. That was my point of selecting a tape image that would be definitely clear of any extras.
And oh, that BACKUP (vs. the newer BACKUP that was later on adopted from VMS), wasn't doing anything fancy but plainly storing the files, one after the other, using DOS labeling (plus some extras, as described). There was no other "enveloping" format, AFAIK. So it was kind of a file COPY command, but en-mass.
But that's all off-topic, though.
If using the TM device the tape can be read, it should be able to read by the TS device just the same.
I am already working on obtaining a listing of the TS (MS:) device driver... It's just 13 blocks of formatted binary :-) Unless I find anything better, like the original annotated listing (.LST or .MAC).
Should be, but it isn't. I can't find any source for the DIR utility or the XXDP+ MS driver. I did trace everything that happens between the first read following the rewind and the backspace record. From what I can tell, after reading the block, and seeing that status is okay in TSSR, the code does a lot of formatting and typing in EMT (XXDP+ monitor) routines and TRAP (DIR local) routines and then jumps directly to the backspace. No other piece of TS returned status is ever looked at.
In gorier detail: the status register is TSSR: 000200, ready, no exceptions. The status returned by the TS11 is in a seven word packet:
WADL: 006062 ; WCHR packet address WADH: 000000
sim> ex 6062/16 6062: 100020 acknowledge + end 6064: 000012 packet length without header and length 6066: 000000 residual frame count (0 means no overrun or underrun) 6070: 000310 tape has moved, online, 1600bpi 6072: 000000 6074: 000000 6076: 000000
This is never looked at. While 5000 cycles elapse between the READ finishing and the backspace being issued, almost all of it is printing out the directory entry. I've compressed the trace by snipping out the EMT and TRAP routines. The result is attached.
If you want to see the EMT routines, the reconstructed source for XXDP+ can be found here. It does not include either the DIR source or the MS driver.
So I leave this to people who have more patience or time than I have. What we do know is that the MS driver in XXDP+ fails, regardless of boot device; while the driver in XXDP_V2 works. Without sources, I can't go any further.
To reconstruct the debugging situation (I used Visual Studio):
At this point, I suggest SAVEing the state of the simulator, for easy repetition of the case. I set CPU HISTORY=5000 and changed TTO TIME to 1, to remove wasted cycles waiting for the terminal output to finish. You can now step through the code, perhaps bypassing the EMT and/or TRAP routines, to see if there's someplace it goes astray.
Okay, I have an inkling of what's going wrong, but I can't prove it, and it will be hard to fix.
Working with the xxdp_with_1123 tape, I see the following DIR behavior with the TM11:
Then for the second record
etc.
In contrast, the TS11, on the first backspace, sets BOT in the extended status. It doesn't cause an error, but it is incorrect. It should set nothing.
tl;dr on tape behavior. BOT is not followed immediately by the first record. In 1600bpi tapes, it is followed by an ID burst that identifies the tape as high(er) density. Backspacing over the first record (or reading it backward) works and does not set BOT. Backspacing AGAIN should set RIB (reverse into BOT) and cause an error. Backspacing with BOT set causes the command to be rejected.
The issue in the TS11 is updating BOT at the end of very command, based on POS == 0, and it should not. BOT should set only on these conditions:
Once BOT is set, it should stay set until a forward motion command actually succeeds.
The problem is arising because XXDP+ only has driver entry points for record spacing, not file spacing. So it is trying to emulate how the TM11 would do things, and the first space reverse is providing incorrect status.
So it sounds like for TS11, and for that matter for other tape drives when emulating 1600 BPI operation, you have two have two distinct states:
but beyond EOT
You meant BOT, correct?
but beyond EOT
You meant BOT, correct?
Oops, yes.
I don't know about 800bpi tapes per se, but there's usually a tape gap before the first record. Tape drives that can read in reverse will read the first record backward without setting BOT.
Well, that wasn't the issue. I modified the TS11 to correct the BOT logic, and the results are the same: XXDP+ doesn't work, XXDPv2 (and RT11) do.
Actually, it is the issue. My edit was incomplete. XXDP+ now runs correctly, as does XXDP_v2 and RT11.
I need some more run-time on this. I'd like to try RSTS/E, RSX11M+, and even VMS, to be sure that I haven't broken existing software that was working. And I want to review the code more thoroughly.
I fixed this in V3, natch, so someone else can have the pleasure of forward porting the changes to V4.
Most tape simulators do this right. They have a BOT flag, usually in the tape unit status field, and it sets and clears at the appropriate times. There are some minor nits to look at, noticeably in reset handling and the detection of an illegal reverse operation. See the attachment.
The other really broken tape simulator is the PDP11 and PDP10 TUs. They derive BOT from sim_tape_bot, so they're wrong in the same way the TS was wrong.
Does that tell us sim_tape should be fixed to implement sim_tape_bot the right way? That would/should/might then fix all the tape simulator with one swell foop.
I don't think so. As I wrote, most magtapes do this correctly. With the TS11 fixed (I hope), I'll need to rework the TU simulators, which are very similar.
If the magtape library adds this kind of BOT logic, it will probably break the many tape simulators that are correct.
I've verified that the revised TS11 works with VMS. So it's ready for its closeup. The code is available at http://simh.trailing-edge.com/sources/current/ along with the rest of my current source tree.
Someday, someone knowledgeable will show me how to use GitHub so I can replace Supnik-Current with these sources...
I will now work on the TU simulators for the PDP10 and PDP11.
P.S. How do I get rid of the stupid emoji that appears at the end of every comment?
All the tape simulators that need updating are done. New modules are in http://simh.trailing-edge.com/sources/current
Context
XXDP+ (despite being perfectly able to boot from the TS device), cannot list contents of a tape with the
DIRECTORY
command, entering an infinite loop.Steps to reproduce:
Download a tape image of XXDP+ located at: http://bitsavers.trailing-edge.com/bits/DEC/pdp11/magtapes/xxdp/BB-F751Q-MC_CZZZ9Q0_MSDP+_1982.tap.gz gunzip the file, and attach it to the TS device in the PDP11 simulator, boot
XXDP
and try to list the contents of the tape:The directory command gets stuck listing the same (1st) file over and over again (cancel with
<Ctrl/C>
). When the state of the TS device is examined, it looks like it does not advance when reading, and appears stuck at position 22 (octal, I presume; note that DOS tape labels are 14(10)=16(8) bytes long):It's interesting that it looks like somehow the
UPD2
utility can be located, loaded into memory, and started, but using its ownDIR
command causes the same never-ending listing:Cancel with
<Ctrl/C>
, then enterEXIT
at the*
prompt to return to the monitor.The
.tap
file seems to be of the valid SIMH structure, throughout, and is readable with tape file utilities, showing the tape contents without any errors:how you built the simulator or that you're using prebuilt binaries
This is a current build from the repo with
make pdp11
.the expected behavior and the actual behavior
I suppose the expected behavior is that it should just work, and XXDP+ should be able to list the tape catalog without getting stuck. There can be a problem with the tape image file itself, though, which is quite possible. But I'd assume the corruption would have manifested much worse than just a stuck tape read (but something like the machine crashing or freezing) -- and that's not the case.
I have to note that XXDPv2 tapes found in the same directory on
bitsavers.org
(*MSDP*
are all for the TS device) do appear to boot and list the directory w/o issues. (Although a 1990 XXDPv2 tape, from a zip file, seems to be incomplete.) But XXDPv2 is a later version, and is not exactly XXDP+.I do not know how the TS device works, but maybe some "timing" adjustments are necessary in the simulator code for XXDP+ to be happy.