English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 25 November 2017, 22:20   #21
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,876
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)
Toni Wilen is offline  
Old 25 November 2017, 22:47   #22
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,961
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.
mark_k is offline  
Old 26 November 2017, 10:27   #23
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,876
I can't duplicate this. If directory is selected and index.tape exists, index mode is enabled. Anyway, more detailed mode logging added.
Toni Wilen is offline  
Old 26 November 2017, 14:15   #24
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,961
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.
mark_k is offline  
Old 26 November 2017, 17:35   #25
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,876
Right, read and write operations had incompatible index handling if same session used both. Should be fixed now (untested).
Toni Wilen is offline  
Old 26 November 2017, 21:40   #26
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,961
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.
mark_k is offline  
Old 28 November 2017, 16:46   #27
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,876
"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.
Toni Wilen is offline  
Old 28 November 2017, 20:28   #28
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,961
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).
mark_k is offline  
Old 28 November 2017, 20:49   #29
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,876
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.
Toni Wilen is offline  
Old 28 November 2017, 21:16   #30
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,961
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
mark_k is offline  
Old 28 November 2017, 21:37   #31
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,876
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"
Toni Wilen is offline  
Old 28 November 2017, 21:48   #32
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,961
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 is offline  
Old 28 November 2017, 22:37   #33
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,961
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 is offline  
Old 29 November 2017, 14:38   #34
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,961
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 is offline  
Old 29 November 2017, 17:07   #35
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,961
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."
mark_k is offline  
Old 30 November 2017, 20:36   #36
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,876
Quote:
Originally Posted by mark_k View Post
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)
Toni Wilen is offline  
Old 30 November 2017, 20:58   #37
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,961
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.
mark_k is offline  
Old 01 December 2017, 16:56   #38
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,876
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.
Toni Wilen is offline  
Old 02 December 2017, 13:42   #39
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,961
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.
mark_k is offline  
Old 30 December 2017, 22:35   #40
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,876
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
Toni Wilen is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Kickstart 1.3 with scsi.device 8bitbubsy support.Hardware 53 06 February 2018 13:14
Which scsi.device for emulation? MartinW support.WinUAE 17 04 September 2017 00:56
What is 2nd.scsi.device videofx support.Hardware 2 25 May 2014 18:45
Instaling SCSI.DEVICE in CWB 3.9 paulo_becas support.Other 13 21 April 2014 15:57
Which scsi.device? dannyp1 support.Apps 7 25 January 2012 22:10

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 12:54.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.08999 seconds with 12 queries