Conference vaxaxp::vmsnotes

   Here are some URL for these "does anyone know?" questions:
	http://webir.das.dec.com/
	http://comet.alf.dec.com/
	http://altavista.pa.dec.com/
	http://altavista.notes.lkg.dec.com:8000/
	http://www.altavista.digital.com/

   There are any number of IEEE-488 cards around, but I'd try to
   forget about adding any hardware to the BI -- look at the IEZ11
   product, which is SCSI-to-IEEE488.  SPD 31.41.xx.   There are
   various ways to get a SCSI bus hooked to the VAX 6000 series.
   (I'd move any existing BI controllers off to the XMI, or off
   to other busses -- I'd look at removing the BI entirely.)

:     Another driver we have source code for but are having trouble getting
:it working.  What is the best place for me to go with questions about 
:modifying a vaxbi device driver for expanded addressing mode?

   The device driver manuals cover this topic.  For those times
   when the manuals do not go into sufficient detail, I'd acquire
   the OpenVMS source listings CD-ROM set and look there.  And for
   OpenVMS device driver questions, this is the right conference.

    A last ditch type measure could be forthe customer to use DISM32
    to turn an EXE of his driver into macro-32, then maybe add teh flag.
    I presume he doesn't in fact have the extra memory?
    
    DISM32 requires iterative use to get all the instructions but does
    eventually get them and the result can generally be rebuilt.
    

    The mods for the DMB32 to work with XBI+ were relatively trivial, but
    it does depend on having a BI device that either works in physical mode
    or understands the new PTE format (IIRC, DMB does the former). So there
    may be device constraints which prevent you moving to a system where
    XBI+ is in use (i.e. VAX 6600 with > 512MB of memory or any VAX 7000
    systems). You need more than just the driver sources, you need the
    device firmware spec too.
    
    If the price for the sources is that high (and the prot potentially
    risky) can the customer not simply buy a MicroVAX 3100 of some flavour
    and hang a SCSI-IEEE converter off it? (Those 3100s can be dirt cheap
    in the "pre-enjoyed" market ... ).
    
    For the driver that you do have sources for, you'll need to post
    specific questions to get specific answers: "it doesn't work" won't get
    you very far :-)
    
    Antonio

    
:    If the price for the sources is that high (and the prot potentially
:    risky) can the customer not simply buy a MicroVAX 3100 of some flavour
:    and hang a SCSI-IEEE converter off it? (Those 3100s can be dirt cheap
:    in the "pre-enjoyed" market ... ).

   A MicroVAX or VAXstation add-on is certainly one option.  One might also
   be able to use -- check with the IEZ folks -- an KFMSA/HSD, CIXCD/HSJ,
   or similar widgets.  Adding these widgets also means cheaper SCSI storage
   for the host system.  (The KZMSA would be ideal, but there is no support
   for this particular widget under OpenVMS VAX...)

	The driver for which we have source code available (I work with Amy)
is a Numerix/DRB32 hybrid.  It looks as though an early UQDRIVER was used
for the DRB32-specific stuff, and it is *heavily* customized for use with
the Numerix array processor.  It looks as though the firm that bought up
Numerix (Mercury) may still be in business, but probably is not interested
in supporting the old Numerix products anymore.

	We're wondering if anyone (within Digital or otherwise) may have
updated this driver for the Numerix NMX-432.  We realize that the customer
is better off in the long run, if he ports the application to Alpha and
gets rid of the Numerix entirely.  But, he has recently upgraded to
OpenVMS V7.1 without realizing that there were driver porting issues
to be faced.  So, he has now painted himself into a corner, with no time
allocated to the porting effort.

	I'll go off and use the search engines, and let you know if I
happen to find anything useful.

	Bob Sampson

	I could not find any mention of the old Numerix array processor.

    If the only change is the OpenVMS V5.5-2 to V7.1 change, then the
    driver port should be fairly straightforward. I have some old
    documentation and a DECUS handout that discuss the changes introduced
    by BLADE (VMS V6.0?). It's all fairly mechanical.
    
    If the failing brain cells recall correctly, you can more or less leave
    everything alone and just upgrade a few symbols to account for changed
    symbol names to do with VA and sprinkle the code with new macros to
    read/write CSRs. I helped a customer do this for their own custom DMB
    driver and it took them just a few weeks to get it all working.
    
    Send me mail if you need copies of the docs (assuming I still have
    them). I still have the mail exchange with the customer I helped, so I
    can pick through that and summarise the points he had problems with
    (mainly how the new XBI mappiong stuff works). I also found that one of
    the VAX 6000 docs actually has an excellent desciption of the XBI+ and
    what it does and why it is needed. I'll dig out that doc reference too
    if you need that.
    
    Try searching with AltaVista Notes for a reference to UQDRIVER ports
    within the last two years or so - I'm sure I remember something about
    someone having done one. A look at the before and after sources might
    prove to save a lot of time.
    
    Antonio

	Yes, we charge hourly consulting rates.  Please do send us anything
you have that might be helpful (to CUJO::MEIER, CUJO::MURTHA, and
CUJO::SAMPSON).  Porting UQDRIVER itself is not that much of a problem,
especially since that work was already done by the maintainers for V5
of that driver.  This particular driver is so heavily customized for
the Numerix, though, that the current UQDRIVER isn't a lot of help.

	Thanks,
	Bob Sampson

    Mercury Computer is in Lowell, Mass.  I know folks working there.
    
    jim

	BTW, I should mention that just rebuilding the driver (assemble,
link) results in an UNXINTEXC crash when an attempt is made to actually
make use of the device.

    Thanks for the suggestions for the missing IEEE-488 type driver,
we are persuing options.

     As for the numerix NMX-432 driver we are trying to get it working; here is
the situation.  It is a VAX 6610 with 511.5 Mb of memory.  We have no info on
the device firmware and as far as we can tell there is no support avail for
it, so we are probably limited to < 512Mb until a real upgrade solution is
found.

     The device does DMA and maps user page addresses to on board mapping
registers.  It looks like I still need to allocate XBI+ mapping registers
for the XBI-XMI address translation even if staying under 512Mb.  Is this
true?  I don't think I need to use the READ/WRITE_CSR routines as this does
not need to run on vax 7000/10000 and the device's chances for future upward
mobility are slim.

     Yes, as Bob says we will gladly take any source code.  We have DRB32
sources to study also.  The driver was originally hacked fromm DRB32 driver,
with some customization, but the differences are not that terrible.  I think
I found the DECUS docs in VAXBI conference.   


                Thanks,

                                    Amy
     

    

    I found the reference to the manual I mentioned earlier:
    
            VAX 6000 Platform Technical User's Guide. EK-600EA-TM-001
    
    Chapter 3 covers the XBI/XBI+ (and chapter 2 covers basic XMI
    operation).
    
    It's online somewhere ... try the MCS Learning Utility or TIMA.
    
    As for staying under 512MB ... there are conditions (and I forget the
    exact details but I'm sure someone will chip in with them before I can
    referesh my memory back n the office tomorrow) when the XA features
    kick in. You can force the XA stuff to keep out of your way by keeping
    PHYSICALPAGES below 512MB and setting one (or more) other SYSGEN
    parameters ... now if I could just remember *which* SYSGEN parameter(s)
    ...
    
    
    Antonio