Fang, Claw and Knight’s WEE FORTRAN

Posted on by

I was recently sent a copy of Knight’s WEE FORTRAN by Sharpworks who had rescued it from a tape belonging to HereBeDragons.

There are a couple of references to it in issues 3 and 4 of the Knight’s International Sharp User Group newsletters. In 1981 it retailed for £30+VAT and Knight’s were “certain that KNIGHTS WEE FORTRAN will soon become as popular as our KNIGHT TAPE BASIC COMMANDER, KNIGHT DISK COMMANDER, and KNIGHT DIS-ASSEMBLER.” Despite their certainty I’m not sure that it did become as popular as the other three titles. It definitely wasn’t a tape that I’d seen before on a MZ-80K.

Or … had I seen it before? Some time ago I used the MZ-700 RealFortran compiler that had been distributed in German by a company called BBG. Knight’s WEE FORTRAN probably pre-dates this version by a couple of years, but both are nearly identical. At the same time I’d also played with a compiler that introduced itself as SOSZ80. This would appear to be exactly the same piece of software as the Knight’s WEE FORTRAN compiler, except for the screens identifying the software’s producer.

Software piracy was in its infancy in the early 1980s. Even so, it appeared to be affecting Knight’s. Graham Knight’s final word in issue 1 of their newsletter reads “I have been surprised to see our programs running in three shops who did not buy them from us. Purchasers of our programs are reminded that they should not be copied for use on other user’s computers. Perhaps those who are ripping off our programs would like to send some food for Fang and Claw our ‘pets’.”

Assuming that Knight’s wrote this compiler, it might appear that the SOSZ80 version is a direct unauthorised copy. The BBG tape is slightly different as my previous article notes, but it still looks as if it is a copy with a few patches, one of which removed the IRND (random integer) function.

Case closed? Do Fang and Claw get their food? Well, perhaps not. One error message common to all three versions is “OBJECT PROGRAM NOTHING !” This message appears if you forget to compile your FORTRAN source before running it. The language used by this message is strange enough to a native English speaker (why not use something like NO EXECUTABLE FOUND) to suggest that the origin of the compiler might not have been Scotland after all.

A Knight's WEE FORTRAN error message - OBJECT PROGRAM NOTHING !
Entering EDIT mode and typing & deletes the current source code. ! exits to compiler mode, RUN has nothing to execute, so the error message OBJECT PROGRAM NOTHING ! is the result.

Perhaps Knight’s licensed it from elsewhere for the UK market – and perhaps BBG and SOSZ80 did likewise for theirs?

The answer is lost somewhere in the mists of time … unless, of course, you know differently! Please let me know if you can help solve this minor mystery from more than 40 years ago.

Update 19/07/2025

The copy of WEE FORTRAN rescued by Sharpworks has the real variable printing bug described in Knight’s International User Group Newsletter 4. It’s also referred to in the March 1983 (Vol. 3, issue 1) Sharp Users Club magazine. Although the compiler correctly stores and manipulates real variables, they are always displayed as 14087 by the WRITE statement and are not printed correctly.

The unpatched WEE FORTRAN compiler always WRITEs 14087 for floating point variables.

Fortunately the patch is simple to apply. It claims to correct the printing issue (but not when WRITE is used to display the variable on screen!) and also provides a ‘.F’ format specifier allowing reals to be output in a 10 character wide field rounded to 3 decimal places.

The patch code. USR(33) followed by USR(36) writes the patched compiler to tape.

Even with this patch, WRITE (//,A,//) still sends 14087 to the screen, but using WRITE(//,A.F,//) gives a sensible result. I don’t (yet) have a printer simulator for the Pico MZ-80K/A, so I can’t check that the printer part of the patch works.

The result. Note that WRITE (//,A,//) still produces 14087! I suppose half a patch is better than none …

Playing with this has also uncovered a bug in the Pico MZ-80K/A’s tape handling. The FORTRAN compiler allows source code to be stored in tape data files with a block length of 256 bytes. If the source code is under 256 bytes, the file is written correctly to the SD card. If it is over 256 bytes, the write fails. I suspect this issue will also affect other multi-block files – for example, BASIC tape data files. The problem is now logged and I will get around to fixing it in due course.