Tape emulation issue

[mark_k]

I noticed an issue with tape drive emulation when booting an A2000+A2630+A2090A config (with Amix tape in the tape drive). It looks like the A2090A ROM tries to issue READ commands to the tape drive. Of course it doesn't know anything about tape drives, but the log output suggests something is amiss.

With QIC-150 tapes, tape drives (including at least Wangtek 5525ES, Archive Viper and a Tandberg one from PDFs on bitsavers) require that the fixed bit (CDB[1] bit 0) be 1 in READ and WRITE CDBs, else they report ILLEGAL REQUEST.

WinUAE accepts READ/WRITE with fixed=0. For other tape formats that would be OK, but even then emulation of what should happen is wrong. It's probably not worth trying to correct that, just return ILLEGAL REQUEST. But I'll try to explain what should happen (see also s2-r10l.pdf page 246).

The A2090A ROM issues CDB 08 00 00 00 01 00. For a direct-access device that would be a READ of one sector starting at LBA 0. However the emulated QIC tape drive/format has 512-byte tape blocks. In tape terms, that CDB means:
- FIXED bit (CDB[1] bit 0) is 0 so the transfer length in CDB[2]-CDB[4] gives a number of bytes.

What should happen: WinUAE reads the first 512-byte block from tape. Transfer the first byte of that block's data from emulated tape drive to A2090A. The tape position is then just before the second tape block. In other words, though only one byte was transferred, the tape position moves to the next tape block (i.e. byte offset 512 in the first tape file).
What actually seems to be happening, is WinUAE's "file pointer" is only advanced by 1 byte, so the following bogus READ commands transfer the remainder of the first block.

Also, it looks like WinUAE transfers more than 512 bytes (i.e. more than one tape block) if the transfer length in CDB is >512. That's incorrect; non-fixed tape READ never transfers more than one tape block of data. That is, if transfer length >= 512 the actual number of bytes transferred is 512 and tape is positioned after that block.

Config:
hXXps://www.media!fire.com/file/953nike1qjimza8/AMIX_A2000_030_A2090A_A2065.uae.zip/file

Log output:

22-977 [22 226-020]: A2090/A2091/A590 WD33C93 in use
25-150 [152 226-033]: TAPEEMU: 00.00.00.00.00.00
25-151 [152 122-042]: TAPEEMU: 1B.00.00.00.01.00
25-151 [152 122-042]: TAPEEMU LOAD/UNLOAD 0:0:1
25-152 [152 221-052]: TAPEEMU: 08.00.00.00.01.00
25-152 [152 221-052]: TAPEEMU READ 1 (1, 0)
25-152 [152 221-052]: TAPEEMU: Next file
25-153 [152 221-052]: TAPEEMU: File 'Z:\AMIX\2.1\tape\\00' Size 5120
25-153 [152 221-052]: TAPEEMU READ: Requested 1, read 1, pos 1, 5119 remaining.
25-153 [152 221-052]: -> READ 1 bytes, LEN=1 EOF=0
25-154 [152 101-078]: TAPEEMU: 08.00.00.01.01.00
25-154 [152 101-078]: TAPEEMU READ 257 (257, 0)
25-154 [152 101-078]: TAPEEMU READ: Requested 257, read 257, pos 258, 4862 remaining.
25-154 [152 101-078]: -> READ 257 bytes, LEN=257 EOF=0
25-155 [152 225-102]: TAPEEMU: 08.00.00.02.01.00
25-155 [152 225-102]: TAPEEMU READ 513 (513, 0)
25-156 [152 225-102]: TAPEEMU READ: Requested 513, read 513, pos 771, 4349 remaining.
25-156 [152 225-102]: -> READ 513 bytes, LEN=513 EOF=0
25-157 [152 031-136]: TAPEEMU: 08.00.00.03.01.00
25-157 [152 031-136]: TAPEEMU READ 769 (769, 0)
25-157 [152 031-136]: TAPEEMU READ: Requested 769, read 769, pos 1540, 3580 remaining.
25-157 [152 031-136]: -> READ 769 bytes, LEN=769 EOF=0
25-158 [152 032-161]: TAPEEMU: 08.00.00.04.01.00
25-158 [152 032-161]: TAPEEMU READ 1025 (1025, 0)
25-159 [152 032-161]: TAPEEMU READ: Requested 1025, read 1025, pos 2565, 2555 remaining.
25-159 [152 032-161]: -> READ 1025 bytes, LEN=1025 EOF=0
25-160 [152 220-192]: TAPEEMU: 08.00.00.05.01.00
25-160 [152 220-192]: TAPEEMU READ 1281 (1281, 0)
25-160 [152 220-192]: TAPEEMU READ: Requested 1281, read 1281, pos 3846, 1274 remaining.
25-162 [152 220-192]: -> READ 1281 bytes, LEN=1281 EOF=0
25-163 [152 209-241]: TAPEEMU: 08.00.00.06.01.00
25-163 [152 209-241]: TAPEEMU READ 1537 (1537, 0)
25-163 [152 209-241]: TAPEEMU READ: Requested 1537, read 1274, pos 5120, 0 remaining.
25-164 [152 209-241]: TAPEEMU: Next file
25-164 [152 209-241]: TAPEEMU: File 'Z:\AMIX\2.1\tape\\01' Size 2333184
25-164 [152 209-241]: -> READ 1274 bytes, LEN=1537 EOF=0
25-165 [152 209-241]: TAPEEMU READ FILE END, 263 remaining (BEOM=0)
25-165 [152 209-241]: TAPEEMU SENSE: F0.00.80.00.00.06.01.06.00.00.00.00.00.01.
25-168 [153 226-014]: TAPEEMU: 03.00.00.00.04.00

[Toni Wilen]

Originally Posted by mark_k

That's incorrect; non-fixed tape READ never transfers more than one tape block of data. That is, if transfer length >= 512 the actual number of bytes transferred is 512 and tape is positioned after that block.

Where is this documented? I can't find any read size limits (except READ BLOCK LIMITS which describes hardware specific limits but I don't bother with it this time) mentioned in the spec.

Not positioning to start of next block after variable read does appears to be wrong.

[mark_k]

s2-r10l.pdf page 246: "If the fixed bit is zero, a variable-length block is requested with the transfer length specifying the maximum number of bytes allocated for the returned data."
[Note the singular "a variable-length block"]

"A successful READ command with a fixed bit of one shall transfer the requested transfer length times the current block length in bytes to the initiator. A successful READ command with a fixed bit of zero shall transfer the requested transfer length in bytes to the initiator. Upon completion, the logical position shall be after the last block transferred (end-of-partition side)."

[The "Upon completion..." sentence is intended to cover both fixed=1 and fixed=0 cases but it's a little confusing since fixed=0 means only a single block is read.]

It then explains about the SILI bit, but in the above log output SILI=0 so I'll just paste that here.

"If the SILI bit is zero and an incorrect length block is read, CHECK CONDITION status shall be returned and the ILI and valid bits shall be set to one in the sense data. Upon termination, the logical position shall be after the incorrect length block (end-of-partition side). ... If the fixed bit is zero, the information field shall be set to the requested transfer length minus the actual block length. Targets that do not support negative values shall set the information field to zero if the overlength condition exists (see 10.4)."

Overlength is defined in 10.4.9 (page 272): "The incorrect length condition that exists after executing a read command when the length of the actual block read exceeds the requested transfer length in the command descriptor block."


I think it's much easier to ignore all that and just return ILLEGAL REQUEST if fixed=0 in READ or WRITE CDB, like all(?) actual drives do with QIC-150 tapes. Especially since WinUAE tape emulation only emulates 512-byte block size.

[Toni Wilen]

I read "variable-length block" as any transfer size instead of "normal" static size. I am still not sure this is correct because why would you need to read variable blocks one by one but can read non-variable blocks as many as you want with single read command..

But ok, I'll return error if READ/WRITE(6) does not have fixed bit set.

[mark_k]

The way variable-block mode works is just the way it's been since... forever I think.

One use for variable block mode (with tape drives that support it) is to determine the size of blocks on tape. Assuming all blocks of a file are the same size, you could then use fixed-block multiple-block READs for better performance.

But (I just noticed that) if the minimum and maximum supported block sizes (in READ BLOCK LIMITS data) are the same, it's mandatory to only support fixed mode. s2-r10l page 248: "If the maximum block length limit value equals the minimum block length limit value, the logical unit supports the transfer of data in the fixed-block mode only, with the block length equal to the given value. In this case the fixed bit shall be set to one in the WRITE and READ commands."

Later standards are more explicit. From ssc-r22.pdf: "If the MAXIMUM BLOCK LENGTH LIMIT value equals the MINIMUM BLOCK LENGTH LIMIT value, the logical unit supports the transfer of data in the fixed-block mode only, with the block length equal to the MINIMUM BLOCK LENGTH LIMIT value. In this case, READ and WRITE commands with the FIXED bit set to zero shall result in CHECK CONDITION status and the sense key shall be set to ILLEGAL REQUEST with the additional sense code and an additional sense code qualifier set to INVALID FIELD IN CDB."

[mark_k]

The SCSI-1 spec is actually clearer about operation when FIXED=0:

  If the maximum block length equals the minimum block length, only fixed-
length blocks of the length indicated are supported.  Otherwise, variable-
length blocks are supported.

  If the fixed bit is zero, a single block shall be transferred with the 
transfer length specifying the maximum number of bytes the initiator has 
allocated for the returned data.  If the actual block length is different from 
the specified transfer length, a CHECK CONDITION status shall be sent to the 
initiator and the incorrect length indicator (ILI) bit and valid bit in 
extended sense shall be set to one.  The information bytes in extended sense 
shall be set to the difference (residue) between the requested transfer length 
and the actual block length.  Targets that do not support negative residues 
shall set the ILI bit to one and the residue to zero when the actual block 
length is larger than the transfer length.  In any case, no more than transfer 
length bytes shall be transferred to the initiator and the medium shall be 
positioned after the block (end-of-medium side).

[mark_k]

Testing WinUAE 4.2.0b7 now. Whether a tape is in the drive or not, the system hangs at boot time. I'm not sure whether that matches real hardware, but given that AMIX was supposed to work with A2090A, maybe it doesn't? Disassembling the A2090A boot ROM might be needed to see what it expects or what a workaround could be.

Log output with empty tape drive:
TAPEEMU: 00.00.00.00.00.00
TAPEEMU SENSE: 70.00.02.00.00.00.00.06.00.08.00.00.3A.00.
TAPEEMU: 03.00.00.00.04.00

Log output with tape in drive:
TAPEEMU: 00.00.00.00.00.00
TAPEEMU: 1B.00.00.00.01.00
TAPEEMU LOAD/UNLOAD 0:0:1
TAPEEMU: 08.00.00.00.01.00
TAPEEMU SENSE: 70.00.05.00.00.00.00.06.00.08.00.00.24.00.
TAPEEMU: 03.00.00.00.04.00

[Toni Wilen]

It seems to be yet another A2090 driver bug. There is one routine that does not set correct mode to PCSS (Last write was when start DMA command was sent) before it checks the flag. All other routines write to PCSS (with correct value) first before checking status.

I added workaround: return complete status bit even if last command was DMA start.

[mark_k]

Don't know if this is related to that workaround, but AMIX 2.03 installation now fails with today's winuae.exe. (It works with WinUAE 4.1.0.)
(Using A2000+A2630+A2090A+A2065 config I uploaded in other thread.)

Pic: hXXps://www.media!fire.com/view/foo2jga187x02g0/AMIX_pic_2019-03-31.png/file
Final install script output:

Please wait while the partitions are checked...
sd: dma retry
TRAP
proc = 400D5400 (pid 6, sh) psw = 0
pc = 0

PANIC: KERNEL FAULT psw=0x0, pc=0x0, fmt=0x0, vector=0x0 (Reset: Stack Pointer)

4.0 2.03 Backtrace:
40001EE4: 23E1F8->258C0C
40001EF4: 23E3C4->23E1F4
40001F10: 23E6FA->23E2A4
40001F20: 25AC1A->23E6EE
40001F58: 259C7A->25AB9C
40001F94: 2011D2->259978
C07FFDBC:

[Toni Wilen]

I checked Amix driver source (/usr/sys/amiga/alien/a2090.c) which helped. Should be fixed now. (Not tested)

Technically according to source, it should have simply detected DMA error (A2090 DMA can apparently fail in some situations) and retried it but I guess in this situation SCSI command didn't transfer any data but code always calls stop_dma() and retrying DMA in this case probably confused the driver..

[mark_k]

Sadly today's WinUAE (2019-04-02 12:30) also shows the trap/panic text. But no "sd:dma retry" so I guess that's an improvement...
Screenshot: hXXps://www.media!fire.com/view/hr06s89c5fnpamh/2019-04-02_test.png/file


There are various newsgroup threads covering A2090 DMA issues; try searching Google Groups for A2090 DMA FFS. For example this thread has a post by Dave Haynie.

The A2090 has a 64-byte DMA FIFO. Originally that wasn't a huge problem on systems with real fast RAM. OFS only issues single-sector CMD_READs to its buffers which (if the user mounts non-boot partitions after running FastMemFirst on Kickstart 1.x) will be in real fast RAM if any is present.

For ST506-type drives which have a 5Mbit/sec data rate FIFO overruns might have been relatively infrequent (but probably still did happen with 16-colour high-res screen). SCSI drives can be much faster and so DMA to chip or slow RAM has a greater chance of FIFO overrun. With FFS each CMD_READ (and hence READ (6) SCSI command) can be much longer, and attempts to DMA directly to the destination address which may be in chip RAM. Maybe in that case, the DMA transfer will almost certainly fail, and thus a read/write error would be reported after the driver uses all retry attempts.

I guess it would be possible to write a driver for the A2090 which uses PIO, not DMA? Or one that tries to be intelligent, only attempting to use DMA to/from Zorro II RAM.

It's definitely not a good idea to have your boot partition be FFS because you can't control the Mask or MaxTransfer values. Small MaxTransfer could to some extent reduce the number of DMA retries needed.


Interestingly, with my config (4MB on A2630, 4MB Zorro II, Kickstart 3.1), Amix only sees 4MB, saying:

Total     Unix  memory = 4192256

Edit: never mind, A2630 RAM is above the 24-bit region.

[Toni Wilen]

Does this config actually match old version because of autoconfig bug that was fixed few days ago? A2090 should not have been properly configured when used with A26x0 until the bug fix. (EDIT: or it got configured multiple times + any following board was missing)

EDIT: and switch off more compatible. It (prefetch/instruction cache) is not fully compatible with MMU emulation and also makes emulation much slower. (It wasn't even 4.1, it just caused different errors).

EDIT2: I tried your config (only changed HDF and tape and floppy) and I can't duplicate the error, with or without more compatible. So perhaps it depends on HDF's old contents?

[mark_k]

Config I was using here: hXXps://www.media!fire.com/file/s97jpt7r77cqb2l/AMIX_A2000_A2630_A2090A_A2065.uae_2019-04-03.zip/file

I'll test again with more compatible unchecked. HDF was a 512MB empty (all zero bytes) file. (The config I posted at the start of this thread doesn't include A2630, the one in the A2630 AutoConfig thread does.)

Edit: It seems having more compatible checked was the problem. With it unchecked the installer gets further.

Strangely, after testing with empty HDF + more compatible checked, if I then uncheck more compatible and restart (leaving the now-not-all-empty HDF alone), the installer seems to hang (no crash message) after "Please wait while the partitions are checked...". That's probably not a WinUAE bug.

[Toni Wilen]

Config in previous post includes A2630. Did you mean to point it to config in first post? This may be useful test case if it is 100% repeatable and and happens very beginning of installation.

[mark_k]

This is A2620/30-related so I might as well mention it here.

With Kickstart 3.1 and A2620/30 ROM -07 you have to enable/install the OSMODE jumper in order to auto-boot Amix from A2090(A).

Changing the OSMODE jumper state doesn't seem to register. I think it should be recognised if you change it then click Reset. [Maybe with real hardware changing OSMODE jumper state then Ctrl-A-A would be sufficient???]

For example:
- Using AMIX_A2000_A2630_A2090A_A2065.uae config, install Amix to A2090(A). Eventually (in Amix) do shutdown -g0, wait for Amix to say it's okay to shut down then quit WinUAE.
- Run WinUAE, load the config. (The config has the OSMODE box unchecked.)
- Eject DF0: and start emulation. Get purple Kickstart insert disk screen.
- Press F12, check OSMODE box. Click Reset. Still get purple Kickstart screen.
- Press F12, click Restart. For some reason OSMODE reverts to unchecked, so check it again then click Start. Now Amix boots.

[mark_k]

Originally Posted by Toni Wilen

Config in previous post includes A2630. Did you mean to point it to config in first post? This may be useful test case if it is 100% repeatable and and happens very beginning of installation.

The AMIX_A2000_030_A2090A_A2065.uae config in the first post of this thread didn't include A2630 (just generic 68030).

[Toni Wilen]

Accelerator board options (jumpers etc) modifications didn't do anything if changed on the fly. Fixed.