pkimpel / retro-b5500

Web-based emulator and operating environment for the Burroughs B5500 computer system.
http://www.phkimpel.us/B5500/
MIT License
76 stars 7 forks source link

Cannot purge tape under Mark XV MCP #44

Closed pkimpel closed 8 years ago

pkimpel commented 9 years ago

Reported by Paul Cumberworth on 2015-05-19:

I’ve got XV DCMCP running up and compilers updated, but I did find an issue in the emulator with Tape handling though – out the box it will not allow PG of a tape, returning a “CANNOT PURGE” error.

In PURGETAPE of XV MCP they’ve changed the handling slightly with the INTERROGATE IO call (line 08030000).

In XIII it is just:

IF WAITIO(@500000000,@120,U) ! 0 THEN%
  BEGIN; STREAM(BUFF); DS ~ 11 LIT "WRITE LOCK~";% 
…

In XV (and XVI) it is:

IF (R~WAITIO(@500000000,@177,U))!0 THEN
  IF R!@120 THEN %ERROR OTHER THAN WRITE LOCK
    BEGIN;STREAM(U~TINU[U],BUFF);
        BEGIN DS~14 LIT "#CANNOT PURGE ";
           …
        END;                                     
        LABELTABLE[U]~@214;      
        GO TO EXIT;
      END ELSE %NO WRITE RING
          BEGIN; STREAM(BUFF); DS ~ 11 LIT "WRITE LOCK~";%
..
         END

As I see it, the reason for the CANNOT PURGE is the BOT status condition present in the result descriptor. If I comment out the call to buildErrorMask in writeInterrogate of B5500MageTapeDrive.js, everything behaves as expected – I checked MCP XIII as well and it was quiet happy with this.

     } else {
        if (this.writeRing) {
//            this.buildErrorMask(0); 
                                } else {
            this.errorMask |= 0x50;     // RD bits 26 & 28 => no write ring, don't return Mod III bits
        }
        finish(this.errorMask, 0);

Looking at the MCP sourcce, I can only find Interrogate called in two places, one in TAPEPURGE at 08030000, and the other in STATUS at 22114000. The call in STATUS is :

   DO UNTIL NOT (T1~WAITIO(@500000000,@165,U)) OR    

where it is masking out BOT status (the same in MCP XIII , XV and XVII).

Given that – it seems that a WriteInterrogate call should not be returning BOT (or even EOT) status in its result.

pkimpel commented 9 years ago

All of the technical documentation indicates that the I/O Control Unit should be returning the BOT indication in response to a Write Interrogate operation, but the MCP clearly does not like it. This is similar to the problem we had with tape oscillation at load point a couple of years ago.

In release 1.02, I've finally surrendered and masked out the BOT bit in the result descriptor for a Write Interrogate. It remains present in the result for other tape operations, however.

pkimpel commented 8 years ago

This issue seems to be resolved, so I'll close it.