scsi.device

[Toni Wilen]

How did you mount the tape directory because "TAPEEMU DIR" means tape.index was not detected -> whole directory becomes the tape, including the index file. (Perhaps it was locked by something?)

There should be "TAPEEMU INDEX: 'file'" log message and then "TAPEEMU: FILE 'filename'" when first file gets accessed.

("no direction specified" is harmless because command does not transfer any data)

[mark_k]

Ah thanks. I initially pointed WinUAE to an empty directory for the tape drive.

When QuarterBack wrote to the tape, WinUAE created index.tape and 00000.tape, 00001.tape. But on reading back WinUAE seems to ignore/forget the index.tape it just wrote and (I assume) just reads each file in the directory in turn, the first being index.tape I guess???

If instead I create an empty index.tape file first, then on starting emulation and using QuarterBack, creating and restoring the backup does work OK.

[Toni Wilen]

I can't duplicate this. If directory is selected and index.tape exists, index mode is enabled. Anyway, more detailed mode logging added.

[mark_k]

Right, but if an empty directory is selected, and you write to tape, WinUAE creates index.tape and 00000.tape etc. but doesn't enable index mode.

So using QuarterBack:
- Back up some files to tape.
- Without exiting Quarterback, try restoring those files. Get error.

However if after doing the backup you reset the emulated Amiga, you can start QuarterBack and restore the backup you just made with no error. So WinUAE must then be working in index mode.

[Toni Wilen]

Right, read and write operations had incompatible index handling if same session used both. Should be fixed now (untested).

[mark_k]

That problem is fixed. Well actually, in the post above I forgot that Quarterback rewinds the tape when you quit it. So now, backup/quit QB/run QB/restore works when it didn't before.

Attempting to backup then immediately restore doesn't work because after the backup the tape would be positioned at end-of-data. On real hardware anyway. (You would select Utilities->Tape Control... menu item then click Rewind to rewind the tape from within Quarterback, before restoring.)

I inadvertently tried to restore right after backup (without rewinding), and noticed some issues with WinUAE's response. On WinUAE, Quarterback shows a message "This tape does not contain a valid Quarterback backup." and seems to hang/get stuck.

TAPEEMU: 00.00.00.00.00.00
TAPEEMU: 08.01.00.04.00.00
TAPEEMU READ 524288 (1024, 1)
TAPEEMU: end of tape
-> READ 0 bytes
TAPEEMU READ FILE END, 524288 remaining
TAPEEMU SENSE: F0.00.C0.00.00.04.00.00.00.00.00.00.00.01.00.00.00.00.
TAPEEMU: 03.00.00.00.20.00
REQUEST SENSE 32 (18 -> 18)
F0.00.C0.00.00.04.00.00.00.00.00.00.00.01.00.00.00.00
TAPEEMU: 08.01.00.04.00.00
TAPEEMU READ 524288 (1024, 1)
-> READ -1 bytes
TAPEEMU SENSE: F0.00.08.00.00.04.00.00.00.00.00.00.00.02.00.00.00.00.
TAPEEMU: 03.00.00.00.20.00
REQUEST SENSE 32 (18 -> 18)
F0.00.08.00.00.04.00.00.00.00.00.00.00.02.00.00.00.00

The first sense data: F0.00.C0.00.00.04.00.00.00.00.00.00.00.01.00.00.00.00.

Problems I can see with this:
Byte 2: FM=1, EOM=1. Filemark should not be detected (i.e. FM=0) because tape is at end-of-data. EOM should not be 1 because we're not at beginning or end of tape.
Byte 7: Additional sense length is 0??? Should be 10 since there are 10 more bytes after that.
Bytes 12/13: ASC/ASCQ. 00/01 means FILEMARK DETECTED
That should probably be 00/05, END-OF-DATA DETECTED, since the tape was positioned at end-of-data before the READ was attempted.

The other sense data has FM=1, EOM=0, ASC/ASCQ 00/02h END-OF-PARTITION/MEDIUM DETECTED
That's not correct, we're not at the end of the medium.

[Toni Wilen]

"end of data" didn't exists previously. Should work now but it really needs Amix installation test because Amix checks and validates too much and aborts immediately if response is slightly wrong.

[mark_k]

I checked winuae.exe dated 2017-11-28 14:17. Didn't check Amix but did try backup and restore in Quarterback.

Backup works. At that point the tape is positioned at end-of-data. But restoring the backup works; it seems WinUAE magically rewinds the tape (Quarterback doesn't issue REWIND itself).

[Toni Wilen]

Writing didn't set end-of-data flag. Now any read operation after write returns end of data until REWIND or LOAD/UNLOAD is executed.

[mark_k]

Getting there...

Testing winuae.exe 2017-11-28 19:47 now. On trying to restore immediately after backup (so tape at end-of-data):
TAPEEMU: 08.01.00.04.00.00
TAPEEMU READ 524288 (1024, 1)
-> READ -1 bytes, LEN=524288 EOF=0
TAPEEMU READ DATA END, 524289 remaining
TAPEEMU SENSE: F0.00.08.00.00.04.00.0A.00.00.00.00.00.02.00.00.00.00.
TAPEEMU: 03.00.00.00.20.00
REQUEST SENSE 32 (18 -> 18)
F0.00.08.00.00.04.00.0A.00.00.00.00.00.02.00.00.00.00

[Is "524289 remaining" just a bug in the log text?]

The sense data has sense key $08 = BLANK CHECK, information: $00000400, command-specific information: $00000000. That's OK, but ASC/ASCQ 00/02 = END-OF-PARTITION/MEDIUM DETECTED. Should be 00/05 = END-OF-DATA DETECTED.


By the way, what's supposed to be in the sense data command-specific information field (bytes 8-11)? I couldn't see it mentioned in s2-r10l.pdf. Currently, after a READ it seems you put the requested transfer length in bytes in there, even if fewer bytes were actually transferred. E.g.
-> READ 111616 bytes, LEN=524288 EOF=0
TAPEEMU READ FILE END, 412672 remaining
TAPEEMU SENSE: F0.00.80.00.00.03.26.0A.00.08.00.00.00.01.00.00.00.00.
TAPEEMU: 03.00.00.00.20.00
REQUEST SENSE 32 (18 -> 18)
F0.00.80.00.00.03.26.0A.00.08.00.00.00.01.00.00.00.00

[Toni Wilen]

05 and 02 was swapped.

http://www.staff.uni-mainz.de/tacke/scsi/SCSI2-10.html mentions length fields, it looks like it should contain remaining data but explanation is not that clear..

"If the fixed bit is one, the information field shall be set to the requested transfer length minus the actual number of blocks read (not including the incorrect length block). If the fixed bit is zero, the information field shall be set to the requested transfer length minus the actual block length"

[mark_k]

Yep, that's referring to the information field (bytes 3-6 of sense data). I was asking about the command-specific information (bytes 8-11, after the additional sense length byte). In the example above bytes 8-11 contain $00080000 which was the requested read transfer length in bytes.

[mark_k]

There's another place where WinUAE is returning sense data with additional sense length byte zero. If you restore a QB backup, notice some lines like this in the log:
TAPEEMU: 03.00.00.00.20.00
REQUEST SENSE 32 (18 -> 18)
70.00.00.00.00.00.00.00.00.08.00.00.00.00.00.00.00.00

[mark_k]

Quarterback issues MODE SENSE with length 12:
TAPEEMU: 1A.00.00.00.0C.00
TAPEEMU MODE SENSE PC=0 CODE=0 DBD=0
TAPEEMU REPLY: 0B.00.00.08.00.00.00.00.00.00.02.00.

WinUAE returns 0 for density code in first byte of block descriptor (bolded above). I don't think that's a legal value. $10 meaning QIC-150 would be a good value to put there.

Quarterback gets confused very easily. With some tape condition (e.g. write protected) where it shows a requester with OK/Cancel, clicking either button does nothing. In the log you can see it continue to regularly issue TEST UNIT READY and MODE SENSE commands. I'm not sure why it gets stuck though, since WinUAE's response seems reasonable.

Would it be possible to allow user to toggle tape write-protect on-the-fly? Currently you can press F12 and change it, but on continuing emulation the WP bit is still set in MODE SENSE responses.

[mark_k]

Yet another thing... I tried getting Quarterback to space forward while at end-of-data.

TAPEEMU: 11.01.00.00.01.00
TAPEEMU: SPACE code=1 count=1
TAPEEMU: end of media
TAPEEMU SENSE: 70.00.03.00.00.00.00.0A.00.00.00.00.00.05.00.00.00.00.
TAPEEMU: 03.00.00.00.20.00
REQUEST SENSE 32 (18 -> 18)
70.00.03.00.00.00.00.0A.00.00.00.00.00.05.00.00.00.00

Quarterback shows a requester, "Error while spacing tape forward. There may be no more data on this tape." (and gets stuck there as mentioned).

In the returned sense data:
- Sense key is $03 = MEDIUM ERROR, should be $08 = BLANK CHECK
- The valid bit should be set (so $F0 in first byte)
- Information field should contain count minus actual number of [whatever] spaced over.

s2-r10l.pdf page 257 (PDF p.293) says:
"If end-of-data is encountered while spacing over blocks, filemarks, or setmarks, CHECK CONDITION status shall be returned, the sense key shall be set to BLANK CHECK, and the valid bit shall be set to one in the sense data. ... The information field shall be set to the requested count minus the actual number of blocks, filemarks, or setmarks spaced over as defined by the code value."

[Toni Wilen]

Originally Posted by mark_k

Yep, that's referring to the information field (bytes 3-6 of sense data). I was asking about the command-specific information (bytes 8-11, after the additional sense length byte). In the example above bytes 8-11 contain $00080000 which was the requested read transfer length in bytes.

It is only a coincidence. It is a single set bit. It is set if beginning-of-media. I have no idea why, I can't find any documentation that explains this (=something that is old enough, at least before SCSI-3)

[mark_k]

Byte 9 bit 3 indicating BOM was mentioned here.

The Wangtek 5525ES can be configured for SCSI-1 and SCSI-2 modes. When in SCSI-2 mode, the BOM bit is sense data byte 19 bit 3. (I think the current tape emulation always reports itself as SCSI-2 in INQUIRY data?) I wouldn't be surprised if the earlier 5150ES is "SCSI-1 mode only", or if Amix needs BOM bit in the SCSI-1 mode position.

[Toni Wilen]

Some more updates. Now it reports as SCSI-1, SPACE now reports correct count (and also count>1 is supported). READ also reports correct count.

[mark_k]

I'll see whether the Amix tape contains source for its tape driver. That could be helpful in figuring out any special requirements it has.

[Toni Wilen]

Amix install tested, it worked except last file (X11r5src) failed to install if more data was requested than was remaining. I added filemark after last file and then install succeeded with X11r5src selected. It didn't like end of media or end of file errors or BLANK CHECK status.

I am not sure if it is guaranteed that there is always filemark after last file. Spec says something about needing to execute WRITE FILEMARK after last WRITE to guarantee buffer flush to tape. Anyway, now it always returns filemark first and only after it has been "read", comes end of data/blank check error. Amix install has priority