It would be a much better idea to write a MEX wrapper for your FORTRAN code. This way there is no need to port anything to MATLAB code. Also, porting FORTRAN code to MATLAB code will most likely make execution much slower.
I will add the following to my earlier answer, just in case the MEX file approach isn't clear. MEX is short for MATLAB Executable. A MEX acts as a wrapper (or glue or gateway or interface) between MATLAB and existing FORTRAN (or C/C++) code. The MEX file approach basically consist of writing a gateway procedure that calls the existing FORTRAN subroutine or function.
MATLAB sees a MEX as a MATLAB function. You pass it arguments in MATLAB and it returns arguments to MATLAB, just as any MATLAB function does. The MEX gateway function receives the arguments as MATLAB objects, which it processes and passes the required information to the FORTRAN subroutine or function. The return values produced by the FORTRAN subroutine or function are processed by the gateway subroutine into MATLAB objects, which are then passed to MATLAB.
MEX files may be a bit cumbersome to write. But, in my opinion, they are a much better way to make existing FORTRAN code work with MATLAB. Much better than porting the FORTRAN code to MATLAB code using third party software, with results that are not guaranteed to work as they should. Especially if the code to be ported is long and complex and requires changes before porting.
Afaq, I am just reading this, but I thought I would write this in case you are still working on this translation. Something seems to have gone wrong with file permissions when f2matlab is trying to find the file writeFmt.m. Please contact me so I can help you with this one.