PDP11: TS11 does not work correctly with XXDP+

al20878 commented 10 months ago

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:

$ pdp11
sim> set cpu 11/70 256
sim> set tm dis
sim> set ts ena
sim> att -r ts BB-F751Q-MC_CZZZ9Q0_MSDP+_1982.tap
sim> b ts

CHMMSB1 XXDP+ MS MONITOR
BOOTED VIA UNIT 0
28K UNIBUS SYSTEM

ENTER DATE (DD-MMM-YY): 5-OCT-93

RESTART ADDR: 152010
THIS IS XXDP+.  TYPE "H" OR "H/L" FOR HELP.
.D

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
...

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):

<Ctrl/E>
Simulation stopped, PC: 153524 (MOV R2,-(SP))
sim> ex ts state
TSSR:   000200
TSBA:   00006100
TSDBX:  000
CHDR:   140001
CADL:   154532
CADH:   000000
CLNT:   000016
MHDR:   100020
MRFC:   000000
MXS0:   000314
MXS1:   000000
MXS2:   000000
MXS3:   000000
MSX4:   000000
WADL:   006062
WADH:   000000
WLNT:   000016
WOPT:   000300
WXOPT:  000000
INT:    0
ATTN:   0
BOOT:   0
OWNC:   0
OWNM:   0
TIME:   2000
POS:    22
sim> cont

It's interesting that it looks like somehow the UPD2 utility can be located, loaded into memory, and started, but using its own DIR command causes the same never-ending listing:

.R UPD2
UPD2  .BIC

CHUP2C0 XXDP+ UPD2 UTILITY
RESTART: 003714
*DIR

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>, then enter EXIT 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:

DOS: [1,1]MSDP.SAV
        C 16-DEC-1982
DOS: [1,1]HSAAC4.SYS
        16-DEC-1982
DOS: [1,1]HSABC0.SYS
        16-DEC-1982
DOS: [1,1]HSACC0.SYS
        16-DEC-1982
DOS: [1,1]HSADB0.SYS
        16-DEC-1982
DOS: [1,1]HUDIB0.SYS
        16-DEC-1982
DOS: [1,1]HELP.TXT
        16-DEC-1982
DOS: [1,1]HDMSB0.SYS
        16-DEC-1982
DOS: [1,1]HDMMB0.SYS
        16-DEC-1982
DOS: [1,1]HDMTB0.SYS
        16-DEC-1982
DOS: [1,1]HDDBB0.SYS
        16-DEC-1982
DOS: [1,1]HDDDC0.SYS
        16-DEC-1982
DOS: [1,1]HDDKB0.SYS
        16-DEC-1982
DOS: [1,1]HDDLC0.SYS
        16-DEC-1982
DOS: [1,1]HDDMB0.SYS
        16-DEC-1982
...
0x0072166A TAPE MARK 1.
        EOF
0x0072166E TAPE MARK 2.
        END

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.

al20878 commented 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>...

markpizz commented 10 months ago

@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?

rms47 commented 10 months ago

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.

rms47 commented 10 months ago

So, here's the process.

Rewind the tape.
Read each entry, 14(10) bytes long.
Position, space file forward. Space over the entry.
Repeat 2-3 until end of tape.
Print the column headers.
Rewind the tape.
Read the first record, 14(10) bytes.
Print the directory entry.

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.

markpizz commented 10 months ago

The v4 tape attach logic reads the whole tape at attach time and completely verifies proper forward and backward pointers.

al20878 commented 10 months ago

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.

al20878 commented 10 months ago

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.

rms47 commented 10 months ago

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.

al20878 commented 10 months ago

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>.

al20878 commented 10 months ago

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.

rms47 commented 10 months ago

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.

pkoning2 commented 10 months ago

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.

al20878 commented 10 months ago

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...

pkoning2 commented 10 months ago

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.

al20878 commented 10 months ago

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.

al20878 commented 10 months ago

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:

RSTSDosTapeExt

pkoning2 commented 10 months ago

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).

al20878 commented 10 months ago

@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).

rms47 commented 10 months ago

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.

hist_snip.txt

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):

Set initial parameters
Boot the tape, answer questions
^E
Set a source breakpoint on TS11 POS case 4 (rewind).
Continue
Type D(return)
Continue from first source breakpoint
Continue from second source breakpoint
At third source breakpoint, set a breakpoint on TS11 READ case 0 (read forward).
Continue from source breakpoint.
Column headers should print, then source breakpoint at READ.
Set cpu_astop to 1. This will stop the simulator immediately.
Continue from source breakpoint.
Simulator stops with read complete.

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.

rms47 commented 9 months ago

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:

Rewind
Read the record with the file name
Backspace over the record. This returns a completely normal status.
Backspace again. This returns beginning-of-tape error.
Space forward until end of file.

Then for the second record

Read the record with the file name.
Backspace over the record. This returns a completely normal status.
Backspace again. This returns end of file.
Read forward. This returns end of file.
Space forward until end of file.

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:

Mount (ATTACH).
Rewind.
Reverse operation when BOT == 0 and POS == 0 (status = RIB/TC2).

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.

pkoning2 commented 9 months ago

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:

at BOT (at the marker)
before the first record but beyond EOT and that reverse operation after reading the first label would set state 2, not 1, while reverse from 2 sets 1, as does the initial load and rewind. That's a bit messy but it doesn't sound really hard. Does this kind of split also apply to GCR tapes? And I assume from the way you described it that it does not apply to 800 BPI tape, nor to 7-track tape. Correct?

al20878 commented 9 months ago

but beyond EOT

You meant BOT, correct?

pkoning2 commented 9 months ago

but beyond EOT

You meant BOT, correct?

Oops, yes.

rms47 commented 9 months ago

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.

rms47 commented 9 months ago

~~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.

rms47 commented 9 months ago

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.

Magtape Assessment.txt

pkoning2 commented 9 months ago

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.

rms47 commented 9 months ago

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.

rms47 commented 9 months ago

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?

rms47 commented 9 months ago

All the tape simulators that need updating are done. New modules are in http://simh.trailing-edge.com/sources/current

open-simh / simh

PDP11: TS11 does not work correctly with XXDP+ #305

Context

how you built the simulator or that you're using prebuilt binaries

the expected behavior and the actual behavior