TU58FS - Oversized tape images

Parent Category: Tools Category: TU58FS - file sharing with a DECtape II emulator Written by Administrator

A TU58 cartridge can hold 256KBytes, these are 512 data blocks. However the Tu58 serial MRSP protocol allows 16bit block numbers, so theoretical a virtual tape can
hold 64K blocks = 32MBytes.

tu58fs allows to set oversized tapes with the "--size" option, breaking the 256KB barrier.

Typical you will use "--size 10M" to get the capacity of a RL02 disk.

Use of oversized data tapes works without limitation. For the system tapes (which hold the operating system and where you're booting from) some limitations apply.

Oversized tapes under XXDP

Under XXDP, the tape block count is specified on medium in the "Master File Block". The XXDP driver for TU58 (DD.SYS) can access oversized tapes without problems.
However, in my tests XXDP2.5 refused to boot from an oversized tape.
Non-bootable devices tapes work without problem.

So a typical XXDP set up is:

tu58fs mounts for boot device #0 a small bootable 256KB tape image, and uses for device #1 a 10MB tape (RL02-sized).
Device #1 is a shared directory, you can then copy the content of the standard xxdp25. RL02 image onto that device.

So all the 700+ diagnostics are accessible over a single RS232 connection. No need to wear your old RL02 disk drive while testing & repairing!

This is the command line:

tu58fs <serial_params> --xxdp -d 0 w 11XXDP.DSK --size 10M -sd 1 w xxdp#1

All this is done by the "demo_xxdp_oversized" script, on the github release.

To start a diagnostics from device #1 just type something like

.R DD1:ZRLMB?.???

In fact XXDP can access 8 TU58 devices, giving you a max tape capacity of 7 * 32MB ... a total overkill.

(All this was tested for XXDP2.5)

Directory allocation under XXDP

Under XXDp the directory is saved in a linked blocklist which is expanded on demand.
At image start a static area is reserved, size depending on the total blockcount.
If more files have to be saved, the directory block list is expandend into free space.


Oversized tapes under RT-11

RT-11 does not save the device block count on the tape/disk medium.
The block count is a fixed constant in the device driver for TU58, DD.SYS.
So to access oversized tapes, the new block size must be patched into DD.SYS, then the system must be rebooted to get that driver loaded.
This patched DD.SYS is only to be used with image tapes it was made for!

Under tu58fs, all this is handled transparently ... it just works.

Since there's only on blocksize per RT-11 system in DD:SYS, all TU58 images must have same size. A command line would be

tu58fs  --rt11 -size 10M -sd 0 w rt11v53#0   -sd 1 w rt11v53#1

For some reason RT-11 V5.3 hangs if a booted oversized tape is reloaded by tu58fs after synchronization with the shared host directory. RT-11 V5.5 is OK.
So best do not copy files onto DD0:, work only on DD1:

 

That's all you need to know ... read on for more techno-babble.

Where to patch DD.SYS ?

After a fresh install of RT-11, you get a disk full of utilities, drivers, and their source code.

The source code for DD.MAC contains a system macro call to ".DRDEF"

    .DRDEF    DD,34,FILST$,512.,176500,300

The "512" is the blockcount. For a 10M (==RL02 sized) driver, change the limit of 512 blocks to 20480:

    .DRDEF    DD,34,FILST$,20480.,176500,300

Then translate with

.macro dd
.link dd
.rename dd.sav ddnew.sys

If you compare new and old dd.sys, you see differences:

Original: (size = 512 = 0x200 = 01000 blocks
36 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 00 00 02 00 00 00 00 98 08 9A 04>00 02<1C 80

Patched: (size=204800 = 0x5000 = 050000 blocks)
36 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 00 00 02 00 00 00 00 98 08 9A 04>00 50<1C 80

So the LSB of blockcount is at offset 0x2c, MSB at 0x2d .

This applies also to DDX.SYS.

Auto-patching

DD.SYS is patched automatically by tu58fs, depending on the --size option.  DD.SYS and DDX.SYS on all mounted images are patched.

Since patching is done on start of tu58fs, you can boot from oversized tapes.

The patch is only temporary for the in-memory image, and neither saved in image files nor in shared directories. This "non-feature" is very important: would tu58fs save a patched DD.SYS permanently, a lot of sligthly different DD.SYS'ses would start to propagate ... chaos guaranteed!

For this reason it is hard to copy patched versions of DD.SYS to host image or shared directory!

The only way to make the patched DD.SYS persistent is to copy it with PDP-11 operations to non-TU58 device, or copy it to another filename.
If you copy under same name:

.COPY DD.SYS DD1:DD.SYS
.COPY DDX.SYS DD1:DDX.SYS

the patch will be removed by tu58fs before saving the image, or before exporting files to the shared directory.

Only

.COPY DD.SYS DD1:DDPAT.SYS
.COPY DDX.SYS DD1:DDXPAT.SYS

will copy DD.SYS to TU58 under changed name "DDPAT.SYS". tu58fs does not recognize "DDPAT.SYS" so the patch is not removed.
If DD1: is a shared directory, you can binary compare DD.SYS with DDPAT.SYS, and you will see the different blocksize.

Manual installation of DD.SYS

tu58fs's "auto-patching" reaches its limit when you want to access an oversize TU58 tape from a non-TU58 boot device.

Say you booted RT-11 from an RL02 disk and want to access an oversized TU58. tu58fs knows nothing about RL-drives and will not patch DD.SYS on the RL system disk. YOU have to do this then.

  1. copy a DD.SYS to the tu58fs shared dir, start tu58fs with --size ... -sd ...
  2. under RT-11, the DDn: device now contains the patched DD.SYS
  3. boot from RL02. At first the unpatched DD.SYS on the DL0: device is part of the monitor
  4. to activate the patched DD.SYS:
    .uninstall DD
    .rename DL0:DD.SYS DL0:DD.ORG
    .copy DD0:DD.SYS DL0:
    .install DD
  5. On RL02 now the patched DD.SYS is persistent!

Directory allocation under RT-11

RT-11 uses a static space for directory entries, but under tu58fs directory allocation is dynamic:
It calculates how much files of average size would fit into the freespace on the image, and makes the directory large enough.
"average size" is calculated from the files already there. If the image is yet empty, only one directory segment is allocated at first, which can hold about 140 files.

The directory space is resized on each synchronization. In RT-11 terms: "SQUEEZE-on-SYNC" ! So if you run out of dir entries: wait for sync, then continue.