Bugs in the g3ee emulator and G3 MK8.67

Bugs in g3ee

Incorrect emulation of the NORM instruction

When the following simple Fortran test program is run on g3ee:

      PROGRAM (OFLO)
      INPUT 1 = /ARRAY
      END
      MASTER MAIN
      INTEGER BUF (10)
      DATA BUF /'0'/
      CALL DEFBUF (1,10,BUF)
      READ (1,1000) I
 1000 FORMAT(I0)
      CALL OVERFL (L)
      IF (L .NE. 2) STOP 1
      STOP
      END
      FINISH

Then overflow gets set in the READ instruction and the "STOP 1" is executed.

This was traced to an incorrect emulation of the ICL 1900 NORM instruction.

If the following test program is run on a real 1900 system it will exit OK, but if it is run on g3ee it will halt "!!":

#PROGRAM       /TESTNORM

#ENTRY         0

      LDN   6  0
      LDN   7  0
      NORM  67 46
      BZE   7  OK
      SUSWT    2H!!
OK    DEL      2HOK

#END
#FINISH

A version of g3ee with this problem fixed is being tested.

Bad setting of the current shift in the 7903 emulator

With the M501, M502 and M505 MENDs installed (see Modifying George) it was discovered that George assumes each line of text sent via the 7903 communications processor starts automaticaly in ALPHA shift. The current version of 7903.java was leaving the shift in the state it was in at the end of the previous line.

A fixed version of the 7903 emulator is being tested.

The 7903 emulator uses code page 437

The ICL1900 "pound sterling" character is output as 0x9c, which is the correct character in IBM code page 437. It would be nice to be able to configure the character set used.

I have written a small PERL script, iclterm, that can be used in place of telnet to work around this problem on Linux machines.

Incorrect verification of program DATUM/LIMIT

If a program tries to access memory outside its reservation then versions of g3ee before 28/1/2010 detect the error 64 words too late, possibly crashing George.

The version of g3ee available here has been updated.

The fixed version of g3ee has a bug handling interrupts between a SMO and the following instruction, causing it to crash in SCANTRA or similar routines. A fix for this problem is currently in testing.

The emulated paper tape reader is broken

If a file is read in in NORMAL mode then shift characters can be lost from sections of the file in BETA shift.

For example, with the input:

        input :john,iolib.alphabet(norm),t****
        
        	ALPHA
        	beta
        	ALPHA
        	beta
        
        	ALPHA
        	ALPHA
        	ALPHA
        	beta
        	beta
        	beta
        
        ****

(Each line starts with a TAB).

The following data is stored in the filestore:

        00$A
        P0$A^)ALPHA         <== OK
        P0$A^)]BETA         <== OK
        @0]A)ALPHA          <== lost DELTA and ALPHA shifts!
        P0]A^)]BETA         <== OK
        00]A*^)ALPHA        <== Lost one DELTA shift and ALPHA shift
        P0]A^)ALPHA         <== now in wrong shift
        P0]A^)ALPHA         <== in wrong shift
        P0]A^)]BETA         <== back in BETA, ok
        @0]A)]BETA          <== lost DELTA
        @0]A)]BETA          <== lost DELTA

A fix for this is being tested.

In order to allow copying of files to George (avoiding the limitations of the card reader device) I've written a PERL script that can write NEWCOPYOUT format "magtapes".

The 7903 emulator strips out too many control characters

George outputs many extraneous control characters to MOP terminals, notably XON/XOFF sequences to control the paper tape reader and ESC characters to be punched to paper tape.

In order to work around the bad effects these would have on modern terminal devices the 7093 emulator, ICL7903.class, filters most control characters from George output. Unfortunately it goes too far, filtering out TAB characters for example.

It would be nice if the 7903 emulator would just filter out the bad characters at end of line. Alternatively George could be modified to not produce these characters. (There is an option for that).

My iclterm script will remove unwanted ESC and other control characters from the end of lines, while leaving other control characters intact. It works best with a version of the 7903 emulator that transmits all control characters.

The 7903 emulator waits for RETURN before handling CANCEL

To cancel a line being input on a MOP terminal the user types CONTROL/X (CAN).

Unfortunately the 7903 emulator doesn't transmit the line to George untill the user presses RETURN, at which point George cancels the line, prints CANCEL and reprompts.

(In fact the 7903 is supposed to handle CAN itself, rather than pass it to George. Passing it to George works because the George code also handles dumb "scanner" and "multiplexor" devices).

Bugs in George3 MK8.67

The ALGOLCOMP macro references SUBGROUPSRA4 instead of :LIB.SUBRGROUPSRA4

# MARK NO:-  2C 13.7.77
IF NOT MOP,WE COMERR,GO 9ICL12
IF COR,DL
RV :LIB.PROGRAM XPCK,SUBGROUPSRA4

To fix:

JOB :MACROS,FIXALGOL
EDIT ALGOLCOMP
T/RV/
R/,SUBGROUPSRA4/,:LIB.SUBGROUPSRA4/
E
ENDJOB
****

The CONSOLIDATE macro starts with an unwanted DOCUMENT line

DOCUMENT    :MACROS.CONSOLIDATE
IF NOT STR(%(*TR))=() AND NOT STR(%(*TR))>(!),RV %(*TR)
IF ABS(IN),GO 9ICL83
9ICL1 IF STR(%(IN))=(), GO 9ICL81

To fix:

JOB :MACROS,FIXCON
EDIT CONSOLIDATE
T/DOCUMENT/
P1
E
EJ
****

The FORTRANCOMP macro includes both version 1B and version 1

#FORTRANCOMP MACRO MARK1B
IF NOT MOP,WE COMERR
IF PRE(HEP) AND ABS(OPT),GO 9ICL10
...
IF PRE(ER),GO %(ER)
9ICL9
#FORTRANCOMP MACRO MARK1
IF NOT MOP,WE COMERR
IF PRE(HEP) AND ABS(OPT),GO 9ICL10

The two versions of the macro appear to have been concatenated.

To make this macro work delete all text from "#FORTRANCOMP MACRO MARK1" to end of file:

JOB :MACROS,FIXFCOMP
EDIT FORTRANCOMP
T1
T/#FORTRANCOMP MACRO MARK1/
PE
E
ENDJOB
****