KA10: MTC issue?

[larsbrinkhoff]

I get this:

Simulation stopped, PC: 000005 (SOJGE 10,5)
sim> at mtc0 good.dart
-0> at mtc0 good.dart
MTC0: Tape Image 'good.dart' scanned as SIMH format
sim> c

.R DART

*REWIND
*LIST
DART VERSION 5  TAPE HEADER
RECORDED  13:39 26-JUL-74,  BY [  1,REG] USER CLASS
TEST   TXT     1,REG
TEST2:  T  %     ,      ,$FB
  ,!,;:   1REG          , ];
P[M_30: R\D'3* Y]%   T\T,&'<
LOGICAL END OF TAPE
UNEXPECTED END OF TAPE.

*

[larsbrinkhoff]

Attaching tape image, debug log, waits.ini file used. mtc.zip

[larsbrinkhoff]

And if I use the RESTORE command instead of LIST, I get this. I have placed some breakpoints in DART to see that the word it gets from the tape is not in the expected place.

.R DART

*REWIND
*RESTORE
DART VERSION 5  TAPE HEADER
RECORDED  13:39 26-JUL-74,  BY [  1,REG] USER CLASS
TEST   TXT     1,REG
ILLEGAL TAPE FORMAT.  THIS DOESN'T LOOK LIKE A DART TAPE.
TRY A BACKSPACE COMMAND TO POSITION THE TAPE, OR AN ADVANCE COMMAND TO
SKIP THE
BAD PART.

*

[larsbrinkhoff]

Test reading a 7-track tape gives repeated errors. Image file attached. 7track.zip

MT READ ERROR. MT STATUS = 200610
MT READ ERROR. MT STATUS = 200610

[larsbrinkhoff]

Comparing tapes written by WAITS. First a 9-track tape which looks good.

Start of file.
000000:  000005000005                           ;"  %  %"
000001:  444162640000  eqv      3, @640000(2)   ;"DART  "
000002:  125045414412                           ;"*HEAD*"
000003:  000021007533                           ;"  1 ];"
000004:  000021624547                           ;"  1REG"
000005:  000000000000                           ;"      "
Start of file.
000006:  777776000023  conso    774, @23(16)    ;"__^  3"
000007:  446353000000  eqvm     7, (13)         ;"DSK   " "INX\0\0"
000010:  644563640000  trca     13, @640000(3)  ;"TEST  "
000011:  647064050000  tlcn     1, @50000(4)    ;"TXT%  " "ic P\0"
000012:  000020531433                           ;"  0K,;"
000013:  000021624547                           ;"  1REG"
000014:  000000044624                           ;"   $F4"
000015:  000000000002                           ;"     ""

Next the same files written to a 7-track tape.

Start of file.
000000:  000000050000                           ;"   %  "
000001:  004441626400                           ;" DART "
000002:  001250454144                           ;" *HEAD"
000003:  000000207575                           ;"   0]]"
000004:  000000216245                           ;"   1RE"
000005:  000000000000                           ;"      "
Start of file.
000006:  007777760000                           ;" __^  "
000007:  004463530000                           ;" DSK  "
000010:  006445636400                           ;" TEST "
000011:  006470640500                           ;" TXT% "
000012:  000000205314                           ;"   0K,"
000013:  000000216245                           ;"   1RE"
000014:  000000000446                           ;"    $F"
000015:  000000000000                           ;"      "

This is just the first few words on the tape. The first file is the tape header. The second file (partially shown) is the first dumped file by DART: TEXT.TXT[1,REG]. It looks like the words are missing one 6-bit frame.

[larsbrinkhoff]

This in pdp6_mtc.c mtc_srv should be fixed to say 6 * (5 - i) like the other two places do.

                    cc = 6 * (6 - i);

[larsbrinkhoff]

With the fix, I get this reading a 7T tape which is a slight improvement.

.R DART

*REWIND
*LIST
MT READ ERROR. MT STATUS = 100610
MT READ ERROR. MT STATUS = 100610
MT READ ERROR. MT STATUS = 100610
LOGICAL END OF TAPE
*

[larsbrinkhoff]

It looks like the number of words returned by INPUT is one too much. The first record read is 6 words, but the "input buffer ring" (is that the right phrase) indicates 7. Apparently DART works around this, maybe because the tape header is treated differently.

The next record is the first dumped file. It's 31 words (octal), but INPUT says 32. This confuses DART, and when the next record is read the first word has been flushed. Thus DART starts to read the next file at the wrong place in the tape data.

So for the next round of debugging, I will have to look into the monitor.

[larsbrinkhoff]

I noticed there is an extra DATAI after each record has been read. It's the one here:

MTEOR0: CONSO   DC,160000       ;DATA REMAINING IN DC?
        JRST    MTEOR1          ;NO.
        TLNN    IOS,IO          ;OUTPUT?
        SKIPE   MISSED          ;NO.  DATA MISSED?
        JRST    MTEOR2          ;YES.  ERROR.
        CONI    DC,TAC1         ;FETCH DC STATUS BITS
        LSH     TAC1,-15        ;SHIFT CHARACTER COUNT TO LSBITS
        IMULI   TAC1,-6         ;-NO OF BITS TOO FAR RIGHT
        CONO    DC,@MDCSAV      ;?? IF DON SAYS SO, WELL, OK (JUST)
        DATAI   DC,TAC          ;FETCH LAST PART-WORD OF DATA

Putting a breakpoint on MTEOR0, I see the CONSO does skip to TLNN. We get to CONI DC,TAC1 which gets us 000000124021. 120000 is 5 characters, 4000 is "data needs to be moved". Apparently WAITS is expecting the 160000 bits to be cleared here, but they are 120000.

The calculations depend on a character read from tape being 6 bits. Hopefully we should not get here under normal circumstances, but if we do it may be necessary to use 7-track tapes.

[larsbrinkhoff]

The code that jumped to MTEOR0 is right above.

;HERE ON ERF INTERRUPT FROM DATA TRANSFER OPERATION
MTEOR:  CONO    PI,DCTOFF       ;TURN OFF DC IN CASE BLKI/BLKO DIDNT OVERFLOW
        CONSZ   DC,10000        ;DATA MISS?
        SETOM   MISSED          ;YES.
        CONSZ   MTS,EFF         ;END-OF-FILE?
        SETOM   MTEOFF          ;YES. SET FLAG

        MOVE    ITEM,DCWRD      ;GET THE IOWD
        TLNE    IOS,IO          ;SKIP IF INPUT
        TLNN    ITEM,-1         ;OUTPUT. SKIP IF WORDS REMAIN IN THE IOWD
        JRST    MTEOR0          ;INPUT OR IOWD EXHAUSTED.

[larsbrinkhoff]

I'm not sure if it's the right fix but going by the comment ;DATA REMAINING IN DC? I made the character count zero when a data word has finished assembling. This makes WAITS happy. Reading the code above, I don't see any other path to success here.

I read the PDP-6 manuals, but they weren't very explicit about what the CONI character count should be.

[larsbrinkhoff]

On second thought, maybe something clears the character count before this code is run. Perhaps DATAI?

[larsbrinkhoff]

Verified this also works, and seems like a more likely fix.

diff --git a/PDP10/pdp6_dct.c b/PDP10/pdp6_dct.c
index 787794b..721f9e4 100644
--- a/PDP10/pdp6_dct.c
+++ b/PDP10/pdp6_dct.c
@@ -118,7 +118,7 @@ dct_devio(uint32 dev, uint64 *data) {
           clr_interrupt(dev);
           if (uptr->STATUS & DB_RQ) {
               *data = dct_buf[u];
-              uptr->STATUS &= ~(DB_RQ);
+              uptr->STATUS &= ~(NUM_CHARS|DB_RQ);
               uptr->STATUS |= DB_MV;
               sim_activate(uptr, 10);
           }