Conference 49.910::kav30

Hi Alec,

In terms of device handling the KAV30 is similiar to other "bus-less" targets
supported by VAXELN (e.g. VAXstation 3100 etc.).

In EBUILD, you specify the vector that the device is to interrupt at.  In
the device driver code you map the device's CSR pages by allocating memory
at the specified address.  On the KAV30, you would achieve this by calling
KAV$OUT_MAP.

>How does Autovectoring work, and can this be used for this system.  The boards 
>are at consecutive addresses on the VME bus.

Autovectoring has nothing to do with addresses. Auto-vectoring is intended
for use with "dumb" devices that do not have logic to respond to the IACK 
signal by putting a vector out on the VMEbus.  Auto-vectored devices are
tied to a specific VMEbus IRQ level.

Graham

    Hi Alec,
    
    Out of interest, who's the customer? 
    
    This stuff works. I have a KAV30 in a box with a PEP VDAD card. Haven't
    played with it for a while but as Graham says, it just works, and the
    autovector stuff isn't for us.
    
    regards
    john

Hi John
	Tbe customer is British Steel Corporation in Scunthorpe.  I don't know
for sure, but I get the impression that they are relatively new to this KAV30/
VME type stuff.
 
Kind regards
	Alec

    Ah yes, they're moving from 1960s technology (I'm serious), either GEC
    4000 or Ferranti Argus. They're worried that, soon, no-one will know how to
    fix them. And they have *lots* of them around British Steel.
    
    A good while ago I showed them a KAV30 in a box with PEP's VDAD card,
    and they must have liked the idea (though maybe not the VDAD card).
    Sounds like they're just getting down to their pilot.
    
    If they would be interested in spending money to get it working that
    little bit sooner, I may be able to give them some on-site help. Or if
    you need some reference examples of ELN stuff (.DAT files,
    corresponding ELN$CREATE_DEVICE calls, etc). 
    
    regards
    john

Hello again
	The KAV30 problem seems to have boiled down to a Fortran programming
problem.
The customer, at British Steel says that his Fortran ISR gives him an ACCVIO.
Specifically he says that it can't write to the driver.

The ISR which works in kernel mode, and has its own local variables, writes
data to a communications region.  The driver should then read the data put
there by the ISR. Basically the driver (I think) writes the data to itself from
the comms region, but he says it writes it into a local .psect in the driver,
causing the ACCVIO.  He says that this may be a limitation/restriction of the
Fortran compiler.

As my Fortran knowledge is around about the zero mark, I could do with some
help on this if possible.

The VAXELN Fortran Guide infers that you should be able to write a driver and
ISR with Fortran.  Is this the case, or could the guide be misleading here?

Could this be a Fortran problem, rather than a VAXELN problem?

Thanks for your help

Alec.

    Hi,
    
    since our FORTRAN knowledge is as deep as yours ( well, I did something
    with it 10 years ago... ;-), I suggest you crosspost this in the
    VAXELN notesfile....
                       
    Thomas
    

Hi Alec,


Going on an assumption here that your customer's Fortran ISR fails all the
time. Be aware that Fortran doesn't support the use of pointers.  Yet, the
kernel is passing into the ISR pointers to the register and the communication
region. He will need to make use of another subroutine to dereference the
pointer. For a working example of a simple FORTRAN ISR (that writes data to
the comm region) please see the STARS/DSNlink article entitled:

        VAXELN FORTRAN Sample : Using an ISR in Fortran

Another caveat is that the fortran isr must be the last routine in the program
(see System Services Reference Manual under CREATE DEVICE, service_routine).
This is due in part to the way fortran handles demand zero pages in relation
to the s0 mapping of the isr.  (One could also force the linker to not perform
demand zero compression.  Your customer would run into problems if he had
large uninitialized data structures local to the isr.)

Probably the best thing is for your customer to set a kernel break point on
the isr itself prior to generating an interrupt.  Have him also generate a
compiler listing that contains the macro listing (i.e., $FORTRAN/LIST/MAC
driver). That way he can step into the isr from the kernel debugger at the
console and match the assembly code to where in his ISR he is actually taking the
ACCVIO.

Hope these ideas help,

Alan

    Hi Alec,
    
    Ask the customer to extract his ISR code in a separate source file,
    compile with /LIST/MACHINE. Let him point out any .ADDR directive
    generated by the compiler (it occurs when you pass a variable by
    reference). Ask him to modify the code, so that the compiler never
    generates any .addr directive.
    
    I assisted a french customer in writing his ISR in FORTRAN. It was
    something not obvious. If you don't find a solution, mail me all
    necessary sources to recompile the ISR.
    
    Hope this helps.
    Regards,
    Philippe
            

Hello all
	I'd just like to thankyou all, for all the help offered here, it is much 
appreciated.  The customer in the end, decided to use PASCAL for the ISR routine.
I ran through the suggestions from Alan and Philippe with him.  His ISR was at
the end of his program, but he didn't seem to be too keen to attempt to debug the
application.  Hence the PASCAL solution, he opted for.

Thanks again for all the help.

best regards

Alec