                             U34_RMB2.TXT
                            30-April-1996
                    Copyright (C)1996 Cornel Huth


NOTICE:  Use this material at your own risk.  All liabilities in the use
of this material, or the drivers, rest with you.  There are no expressed
or implied warranties.  Read this entire document before anything else.


Revision 1.

See SECTION II, below.  This first revision, which is still valid, covers
modifying the ultra14.add driver so that it can handle removable DASDs.
This patch simply makes the ultra14.add driver see the removable as a
regular fixed disk.  The problem, as I have since discovered, is that
the ultra14.add driver does not support LOCK/UNLOCK MEDIA (SCSI command
1Eh).  This patch should work for any problem you may have in getting
a removable DASD (should not apply/be needed for floppy/CD-ROM devices)
to work with your UltraStor.  An already patched ultra14n.add file is
available.  Alternatively, you may want to use what is covered in
Revision 2.


Revision 2.

See SECTION I. below.  This second revision covers modifying the
os2dasd.dmd and lockdrv.flt drivers, leaving the ultra14.add
driver as-is (unchanged).  The changes are specifically for the
SyQuest EZ135, and the os2dasd.dmd and syqlock.flt files provided
with it.  Instructions for patching are included, but file-level
patching is specific to the EZ135 in one area.  With a C6 compiler
and the DDK, you can make changes for any other drive.  Also, you
need not make the EZ135-specific change at all and still make use
of most of the patches in this revision (but only at the 'logical'
level of support).  Or, you may simply want to stick with Revision
1 support.


===================================================================
SECTION I.  MAKING THE ULTRASTOR ULTRA 34F WORK WITH SYQUEST DRIVER
===================================================================
This is revision 2 material.  See revision 1 for an alternate method.

Revision 1 obviated the need for Syquest drivers -- it patched the
ultra14.add driver to make the EZ135 appear as a regular fixed disk.
Revision 2 leaves the ultra14.add unchanged (use the original .add
file) and modifys the os2dasd.dmd and syqlock.flt files provided
by SyQuest.  Since these files are now included as part of this
package, the method used to make the changes are not so detailed
as was done in revision 1 of this text.
 
First, make copies of os2dasd.dmd and syqlock.flt.  The files used
by me are:

 1-03-96   5:01p     37596  0  OS2DASD.DMD
 7-27-95  12:26p      3858  0  SYQLOCK.FLT

These are from the SyQuest web site (www.syquest.com) and are
later than those provided in my EZ135 box.  I chose to append the
number 9 to the names, so os2dasd9.dmd and syqlock9.flt are the
names of the included files.  Store the originals in a safe place,
or just leave them where they are!

Place the *9 files in the root directory of the OS/2 boot drive.
Edit config.sys to make the following changes:

  BASEDEV=OS2DASD.DMD  change to  BASEDEV=OS2DASD9.DMD
  BASEDEV=SYQLOCK.FLT  change to  BASEDEV=SYQLOCK9.FLT

The other files (if any) are not part of this patch (and probably
not necessary for hard disk support, unless you need V/ASPI, say).
This os2dasd.dmd file is probably different than that supplied with
your version of OS/2 (newer as well), so be sure to use this one
when doing your own patching.

Reboot.  That's it.  Select the DRIVES OBJECT, right mouse button
(RMB) click on the drive with the removable icon to bring up its
select list.  Unlock should be an option.  Select it.  Repeat
RMB.  Now you should see Lock and Eject as the options (Unlock
is no longer there).  Select Eject.  You should see the drive
activate for a second.  Note that this is all logical processing;
the UltraStor .add driver DOES NOT support LOCK/UNLOCK media
SCSI commands.  This is the reason all this patching is required
(the .add seems to have left out full support for removable DASDs).


The patches/changes made are as follows.  The 'logical' patches allow
normal use, and all is that is generally required (and is not
specific to the EZ135).  The 'physical' patch is specific to the EZ135
and is needed whenever 'physical' access to the drive is needed -- this
would be IOCtl category 9, for example, or when using FDISK.  You
cannot access the drive as a physical entity unless you apply the
physical patch, or make the patch yourself for your particular drive.
More on this later.  Also, if you only need physical access rarely,
you can just boot using ULTRA14n.ADD (From Revision 1) and use that
to FDISK your new cartridges, say, then boot back using the logical
patches.  You may also find that simply using ULTRA14n.ADD does all
that you need and so you can just forget about this 'revision 2'
stuff.  I've noticed it to be faster (ultra14n.add, that is).

The patch references below are from the DDK-supplied files.  These
are not exactly the same as the ones from Syquest.  They are for
informational use only, in case you need to do your own patching/
recompiling.  See SECTION II for very basic debug.com instructions,
or use a debug.com manual.  You might also try comparing the supplied
patched files with the originals to spot the location of the changes
I made.

---------------------
Logical patches made:
---------------------

SYQLOCK.FLT fails to hook when the call to LOCK the drive fails.  It fails
because the ULTRA14.ADD driver does not support LOCK/UNLOCK SCSI commands
for removable drives.  It is supposed to, for removables, but doesn't.
Since this support is not available in the .add driver, the patch tells
IOCtl callers that it succeeds at the physical level and lets the logical
level take care of the rest.

----------------------------------------------------
File J:\ddk\x86\BASE\SRC\DEV\DASD\LOCKDRV\LKDRINIT.C

 Patch: Remove the line

 ...
 if (SendIORB((PIORB)pIODC, pADDEntry) {
   ; // goto Unit_Error;  // remove this line
 }
 ...

 In debug.com, this is near offset xxxx:0C76 of syqlock.flt.


---------------------------------------------------
File J:\ddk\x86\BASE\SRC\DEV\DASD\OS2DASD\DMIOCTL.C

 Patch: Remove from routine GIO_RemovMedControl() the line

   /* Call the adapter driver to lock the drive. */

     if ( (rc = IOCTL_IO( (PBYTE)pCWA->pIRP, pCWA->pVolCB)) & STERR)
       ; //  return( rc);  // remove this return, fall through to (STDON)

   return(STDON);

 In debug.com, this is near xxxx:7C58 of os2dasd.dmd.

----------------------
Physical patches made:
----------------------

This patch is exclusive to the EZ135.  The problem is that when the
ultra14.add processes a removable DASD, it does not completely fill
in data tables of disk geometry.  To the os2dasd.dmd driver, the .add
driver does not return the number of total sectors on the drive.  In
the case of the EZ135, this number is 256K sectors (or 40000h).  The
patch makes use of this fact, writing the '4' part of this value to
two data variables (both 32-bit data variables).  There is not
enough patch space to write any non-64K mod value, since only two
16-bit store instructions are available (and two are needed because
of compiler optimization -- a bug actually, that just happens to
work).  Without this patch, FDISK won't work (it trap D's), and
the benchmark program DISKIO has a weird idea on cylinders (0, and
-1).

-------------------------------------------------
File J:\ddk\x86\BASE\SRC\DEV\DASD\OS2DASD\DMBPB.C

 Patch: Change from routine f_BPBfromGeom() the line

   if (TotalSectors==0)
      TotalSectors = 5760;

 to:

   if (TotalSectors==0) {
      TotalSectors = 0x40000;          // 262144 sectors on EZ135
      pGeometry->TotalSectors=0x40000; // fix compiler bug
   }

 In debug.com, this is near xxxx:1603.  The patch changes both
 TotalSectors (at [bp-14]) and pGeometry->TotalSectors (at [bx+2]).
 The patch only writes a 4 to the high word; the low is already 0.
 Any other drive will require more patching since it's doubtful
 that the number of sectors will be an even mod-64K.  Good luck
 on that job!


That's about it.  With these changes, the EZ135 and UltraStor
get along okay.  There is no physical-level LOCK/UNLOCK available,
so you can still get into trouble if you eject a disk without
going through the logical steps (unlock, then eject, from the
drives object, or via IOCtl commands).   But this is probably
all you lose -- you can push the spin-down button and eject
regardless of the lock state -- but if you play by the rules,
you'll probably be okay (but NO guarantees!).




===================================================================
SECTION II.  MAKING ANY REMOVABLE DASD APPEAR AS NON-REMOVABLE DASD
===================================================================

Things to do to get a removable hard disk to work with the UltraStor
U34F.  The test case was with a SyQuest EZ135, but it's likely that
the problem exists for any removable DASD when using the ULTRA14.ADD.

The problem is the device is never ready.  If you don't have a problem,
don't use this (but let me know your -secret-).

Three things to do:

 1)make and work with a copy of ultra14.add
 2) use debug.exe to make the patch
 3) update config.sys.

There are some parting comments, too.

-----------------------------------------------------
1) MAKE A COPY OF ULTRA14.ADD
-----------------------------------------------------

Work with a copy of the ultra14.add file.

 G>cd \os2\boot
 G>dir ultra14.add

 The volume label in drive G is G_DRV_HPFS.
 The Volume Serial Number is 66FF:A815.
 Directory of G:\OS2\BOOT

 ULTRA14  ADD     18992   6-16-93  9:30a

Verify that you have this file (the latest, and probably last since
UltraStor is, on last count, out of business).  If this is not what
you have, find this file before going on.  If it is, then copy it
to a new file, and work with that new file from now on.

 G>copy ultra14.add ultra14n.add


-----------------------------------------------------
2) USE DOS DEBUG.EXE TO PATCH ULTRA14.ADD
-----------------------------------------------------

Use debug.exe to do the patch.  debug.exe only understands 8086/88
opcodes, so a lot of 286 and later instructions don't display (DB 60,
etc. shows). Load the program, do a U)nassemble to verify you have
the right spot, then patch it, and finally write it out.

 G>debug ultra14n.add

 -u 3927
    :3927 2AE4          SUB     AH,AH
    :3929 894704        MOV     [BX+04],AX
    :392C C787BC000000  MOV     WORD PTR [BX+00BC],0000
    :3932 88A7BB00      MOV     [BX+00BB],AH
    :3936 8D476C        LEA     AX,[BX+6C]

That's how it looks now.  At this point, AL holds the INQUIRE data at
byte +1 (the RMB, in particular).  The ultra14.add driver does a
SHR AL,7 to move the RMB to bit0, from bit7; then a SUB AH,AH followed
by the store to the UnitInfo storage area within the data area of the
ultra14.add.

This patch is a very simple hack; it makes any drive appear as
non-removable. This may or may not impact other things, like CD drives.
A wish-list item is to use a command-line option to turn this on/off,
and also to verify that the device is a DASD type.  Simple, but a few
hours work to patch the code in place (the parse, the check, and then
the fix patches).  Also on the wish list is program support for things
like un/lolocking the disk, and reading the usage counters (usage
counters are specific to the SYQ drives probably.)

To make it so the U34F treats removable drives as non-removable during
the ultra14.add init, do the following.  Note that there is an option
to make the Syquest non-removable (via MODE SELECT), but this is too
little-too late (I would bet).  Also note that I've not determined
exactly the root problem.  I thought I had found the fix by forcing
a READ CAPACITY during the init, even though the device was detected
as removable, but that didn't do the trick.  Therefore, this little
hack is all I've got for now.

Change the sub ah,ah to a sub ax,ax by:

 -a 3927
    :3927 sub ax,ax

This gives the following:

 -u 3927
    :3927 29C0          SUB     AX,AX
    :3929 894704        MOV     [BX+04],AX
 ...

Save it:

 -w
 Writing 04A30 bytes


-----------------------------------------------------
3) CHANGE CONFIG.SYS TO LOAD THE PATCHED ULTRA14N.ADD
-----------------------------------------------------

Change config.sys to read

        BASEDEV=ULTRA14N.ADD


Reboot.


-----------------------------------------------------
4) COMMENTS
-----------------------------------------------------

You'll notice that FDISK now shows the new drive (previously it would
not show at all).  You can partition and format it.  The partition
should be an extended partition.  If you instead partition as a primary,
all your drives letter will go out of whack.  As an extended partition,
the new drive latter comes after your previous DASD letters, and comes
-before- any CD drive letters (this ordering is a function of
os2dasd.dmd).  As for using Syquest drivers, like their version of
os2dasd.dmd, and their syqlock.flt file, DON'T -- they won't do anything
for you (at least, I see no reason to load them).

As for formatting, I recommend doing a

 [C:]format drive: /L /fs:FAT

You can format as HPFS, but the first time I tried it it got about
30% through and said something about running out of memory.  That may
have been a fluke --, or who knows, maybe even a know APAR.  (Later
HPFS formats worked fine, so fluke it probably was -- do not attempt
to remove an HPFS cart -- do a system shutdown first.)

You may be able to remove the cartridge, but be aware that if you are
using a write-back cache, and remove the cart before the disk has been
completely written to, you will lose data.  I keep my FAT cache at 64K
and HPFS at the 2MB max.  If you do change the cart, a follow-up DIR
shows the contents of the LAST disk!  You may be able to get away with
the change by doing a CHKDSK on the drive with the new cart, then a
DIR, etc.  A wish-list item is to provide a means to flush the cache
and make the removal less likely to cause data loss.

Questions?  I don't have the answers!  If you need to get things going,
I might be able to throw a wrench or two into the works, and maybe bang
on it just right,  but if there's more than what is already covered in
this text, I probably don't have a clue!  Nevertheless, I can be
e-mailed at  cornel@crl.com  and elsewhere.

<blip!>
