Small PS below... On Sat, Dec 30, 2023 at 9:27 PM Clement T Cole via groups.io <clemc= ccc.com(a)groups.io&gt; wrote: In my explanation, I may have been a tad confusing. When I say fixed records -- I mean on-tape fixed records, what the QIC-24/120/150 standard refers to as: "*A group of consecutive bits comprising of a preamble, data block marker, a single data block, block address and CRC and postamble*" [the standard previous defines a data black os 512 consecutive bytes] --* i.e*., if you put an o'scope on the tape head and looked at the bit stream (see page 16 of QIC-120 Rev F - Section 5 "Recorded Block" for a picture of this format -- note is can only address 2^20 blocks per track, but it supports addressing to 256 tracks -- with 15 tracks of QIC-120 that means 15728640 unique 512-byte blocks). STOP/STOP does something similar but encodes the LRECL used [I don't have the ANSI tape standard handy - but I remember seeing a wonderful picture of all this from said documents when I first was educated about tapes in my old IBM days ~50 years ago]. After each record, STOP/STOP needs an "Inter-Record-Gap" (IRC) to allow for the motor's spin-up/spin-down time before continuing the bit stream of the next data block. The IRC distance is something like 5-10 mm [which is a great deal compared to the size of a bit when using GCR encoding (which is what 6250 BPI and QIC both use). These gaps take space (capacity) from the tape, so people tend to write with larger blocking factors [UNIX traditionally uses 10240 bytes- other systems use other values - as I said, I believe the standard says the max is 64K bytes). Since streamers (like QIC tape) are supposed to be continuous, the QIC inter-records gaps resemble fixed disk records and can be extremely small. Remember, each bit is measured in micrometers -- about *2 micrometers*, IIRC for QIC and around 10 for ½" formats -- again, and I would need to check the ANSI spec, which is not handy. But this is a huge space savings even with a smallish block (512) -- again - this was lifted from disk technology of the day which had often standardized on 512 8-bit byte blocks by then. BTW: this is again why I suspect a TK25 tape is not going to be able to read on QIC-24/120/150 drive if, indeed, page 1-5 of the TK25 user manual says it supports four different block sizes [1K/2K/4K/8K]. First, the data block format would have to be variable to 4 sizes, and second, the preamble would need to encode and write what size block to expect on read. Unfortunately, that document does not say much more about the physical tape format other than it can use cartridges "similar to ANSI Standard X3.55-1982" (which is a 3M DC-600A tape cartridge), has "11 tracks, 8000 bpi" recording density (/w 10000 flux reversals per in), using a "single track NRZI dat in a serpentine pattern, with 4-5 run length limited code similar to GCR." That said, most modern SW will allow you to *write* different size record sizes (LRECL) in the user software, but the QIC drives and I believe things like DAT and Exabyte will only write 512-byte blocks, so somewhere between your user program and tape itself, the write will be broken into N 512 byte blocks and then pad (with null is typical) the last block to 512 bytes. My memory is the QIC standard is silent on where that is done, but I suspect it's done in the controller and the driver is forced to send it 512-byte blocks. So, while you may define blocks of different sizes, unlike ½", it will always be written as 512-byte blocks. That said, using larger record sizes in your application SW can have huge performance wins (which I mentioned in my first message) - *e.g.*, keeping the drive streaming as more user data has been locked down in memory for a DMA. But by the time the driver and the controller are finished, it's fixed 512-byte blocks on the tape. One other thing is WRT to QIC, which differs from other schemes. I previously mentioned tape files - a feature of the ½" physical tape formats not typically supported for QIC tapes. QIC has an interesting feature that allows a block to be rewritten and replaced later on the tape (see the section of spec/you user manual WRT for "rewritten" or "replacement "blocks). I've forgotten all the details, but I seem to remember that features were why multiple tape files were difficult to implement. Someone who knows more about tapes may remember the details/be able to explain -- I remember dealing with tape files was a PITA in QIC, and the logic in a standard ½" tape driver could not be just cloned for the QIC driver. ᐧ ᐧ ᐧ _._,_._,_ ------------------------------ Groups.io Links: You receive all messages sent to this group. View/Reply Online (#3631) <https://groups.io/g/simh/message/3631> | Reply To Group <simh@groups.io?subject=Re:%20Re%3A%20%5Bsimh%5D%20Old%20VAX%2FVMS%20Tapes> | Reply To Sender <clemc@ccc.com?subject=Private:%20Re:%20Re%3A%20%5Bsimh%5D%20Old%20VAX%2FVMS%20Tapes> | Mute This Topic <https://groups.io/mt/103433309/4811590> | New Topic <https://groups.io/g/simh/post> Your Subscription <https://groups.io/g/simh/editsub/4811590> | Contact Group Owner &lt;simh+owner(a)groups.io&gt; | Unsubscribe <https://groups.io/g/simh/leave/8620764/4811590/1680534689/xyzzy> [ clemc(a)ccc.com] _._,_._,_