The vast majority of errors noted by the tape diagnostic T020C related to wrong length record errors, particularly when a tape operation writes from the last character of storage (39999 in my current 40K implementation), usually starting at location 39990.
The current FPGA from the ALDs implementation does not create an error stop, it simply writes until it has written the character at location 39998 and stops, with a wrong length record (WLR) error – with one less character written than the diagnostic would expect, as well. (Then, subsequently, the read operations in the tests also generate WLR because they are expecting 10 characters, but only get 9).
Part of the problem is that various documents describe what should happen in such a case differently:
Diagnostic T020C (1964):
- The diagnostics do not expect an WLR when writing from the last location in core storage or reading into the last location in core storage. (A WLR would presumably occur when reading into the last location of core storage if the record extends beyond that character.)
A22-0526 (no suffix) 1963
- Addressing: During execution of an instruction, no address must be decremented past 00000 or incremented past the highest valid address. This includes operations that act on data in a single position only; such operations will be executed but, after the operation the associated address register will contain an address beyond one of the limits and the system will stop and signal an error.
- Tape: WLR is never set on a Write or Unit control operation, unless the record is of zero length, i.e. the character at the start is a Group Mark with a Word Mark.
- Tape: Read to End of Core ($): Reads until the last storage position is filled.
- Tape: Write to End of Core (X): Writes until the last storage position is encountered. [ed: to me this is a little vague: does it mean that the last character storage position is written from, or not?]
- Console I/O: WLR is never set (I have not yet tested this)
A22-0526-3 (1961) and A22-0526-2
- Addressing: If an operation increments addresses, 59998 is the highest position (assuming a 60K system) that can be referenced or in which data can be read or inserted as the result of an instruction. If 59999 is addressed in an incrementing operation, the system will stop and signal an address check. There are two exceptions: 1. A manual console operation; that is display and alter. 2. Data may be read from or inserted into 59999 without causing an address check in the execution of a read or write “to end of core” I/O instruction.
- Tape: WLR (W-U) Never set (unless record is of zero length and first character written is GM/WM)
- Tape: Read to End of Core ($) and Write to End of Core (X): read/written until the last core-storage position is encountered. (Notice that this older document does not specifically differentiate between the read and write behaviors)
The ALDs for my machine in these areas are all dated 1962.
Because this issue is unlikely to cause operational issues, I expect to “table” it for now and revisit it later. It may be that ECOs were required to change the behavior to what is expected in the diagnostic.
UPDATE: This turned out to be very easy to fix. At first I tried all sorts of things to try and control the setting of the Internal End of Transfer Latch by inhibiting setting that when the channel Wrap Condition was asserted — but that led to an address check as the 1411 CPU tried to fetch the next higher location, instead of wrapping around to location 0.
So then I decided that I would just make a change to the ALDs on pages 13.71.05.1 (E Channel) and 13.66.09.1 (F Channel) to suppress the MC_DISCONNECT_CALL to the TAU while the E2/F2 register was still full. That worked — even better than I expected. Not only did that cause it to write out the last location of memory, it also caused the Wrong Length Record status to go away as well.
That left me with ONLY ERROR 17 on the E channel. The F Channel had ERROR 17, but also errors 20, 23 and 70, which seemed odd. But otherwise, both channels read and write tape just fine.
Error 20 occurs when a tape mark is read, and the diagnostic expects that the CPU will also set the CONDITION status for the I/O operation, but it was not setting the CONDITION status.