Fortran99 Challenge

+mizapf · April 1, 2020

Here is some code to write to a file. Good thing that I kept all my tests from those times; I never thought I'd really have a second look.


      CHARACTER MYDATA(128),NAME(20)
      INTEGER I,J,ERR,POS

      DATA MYDATA / 0,250,0,0,0,0,17,6,51,7,
     A   23,1,39,3,81,1,
     A   39,6,113,1,115,3,97,6,100,6,17,4,101,2,85,5,119,7/

      WRITE(6,*) 'Test for writing on disk'
      WRITE(6,*)

      WRITE(6,100) 'File name: '
      READ(6,120) NAME

      CALL OPEN(3,NAME,1,0,0,0,128,ERR)

      POS=35
      DO 1 I=1,212
         MYDATA(POS)=242
         POS=POS+1
         MYDATA(POS)=0
         POS=POS+1
         IF (POS.EQ.129) THEN
            WRITE(3,130) MYDATA
            POS=1
         ENDIF
1     CONTINUE
      IF (POS.NE.1) WRITE(3,130) MYDATA

      CALL CLOSE(3)

100   FORMAT('+',A)
110   FORMAT('+',10A1)
120   FORMAT(20A1)
130   FORMAT(128A1)

      END

This code produces this file (DIS/FIX 128):


000000: 00 fa 00 00 00 00 11 06 33 07 17 01 27 03 51 01     ........3...'.Q.
000010: 27 06 71 01 73 03 61 06 64 06 11 04 65 02 55 05     '.q.s.a.d...e.U.
000020: 77 07 f2 00 f2 00 f2 00 f2 00 f2 00 f2 00 f2 00     w...............
000030: f2 00 f2 00 f2 00 f2 00 f2 00 f2 00 f2 00 f2 00     ................
...
0001f0: f2 00 f2 00 f2 00 f2 00 f2 00 f2 00 f2 00 f2 00     ................

+DuaneAL · April 2, 2020

Thanks for the info! I’m really excited to get back to FORTRAN- it has been a long time. I would like to try some programs in different languages to gauge size and speed of the compiled program. I’ve got a bit of a learning curve ahead!

+mizapf · April 2, 2020

BTW, the above test program created a Myart-formatted picture file; it was obviously intended as a template for screen dumps to disk.

wolhess · April 2, 2020

Hello,

I copied the Vorticon disks into a TIPI directory and converted them into TI-Files with Ti99Dir. I'm using my real TI-99/TIPI PEB System with 1MB SAMS, a TI-Controller (80 track mod) and
1 x 5,25" DSSD 80 Track, 1 x 3,5" DSSD 80 Track and 1 x 5,25" SSSD 40 TRACK. Then I loaded the UTIL1 program with an EA5 loader to load the 99 Fortran from the tipi directory.

So far it works well and I can edit and compile programs.

First I tried the example of "dhe" from Post # 10. The program works, ~~but at the end (entry 999) my TI console hangs.~~ ~~After a reset, everything is OK again.~~
I linked the program with the FL library and the end cretaria returns to the menu screen! I should read the manual first.

1. (1) Edit the SAMPLE source code

2. (3) Save as DSK1.SAMPLE
(DSK1=mapped on tipi.DISK.-W.FORTCOMP)

3. (7) Exit the EDITOR

4.     (2) Compile                    ENTER
Input File Name?                                  DSK1.SAMPLE + ENTER
Object File Name?                                DSK1.SAMPLE-O         + ENTER
Listing File Name?                                DSK1.SAMPLE-L1        + ENTER
Scratch Disk Number (1-5)                    1 + ENTER
Compilation Options?                           ENTER
Press ENTER to Continue   ENTER

Compilation in Progress
            0000     Warning(s)
            0000     Error(s)
Compilation Complete

Press Enter to Continue                        ENTER

5.     (3) Link                                       ENTER
Listing File Name?                                DSK1.SAMPLE-L2 + ENTER
Object File Name?                                DSK1.SAMPLE-O + ENTER
Object File Name?                                ENTER
Library File Name?                               ENTER
Symbol File Name?                              DSK1.SAMPLE-SY + ENTER
Executable File Name?                         DSK1.SAMPLE-E
Press ENTER to Continue   ENTER

6. (4) Run ENTER
The program is running

wolhess · April 2, 2020

Hi again,

The second thing I tried was Vorticon's Logistic Equation program.

The program can be compiled, but the linker cannot find the library files on the tipi drive DSK1.

So I copied all library files to my physical drive DSK2 and with that the link process works.

The program works well and ends (with ENTER) in the 99 Fortran menu.

If I select (6) Librarian and (1) To List Library in the 99 Fortran menu, 99 Fortran will also find the file in the tipi directory and I can list the Library File on the CRT or on the printer. I tried some more configurations e.g. the Library Files on a DSK2. mapped tipi directory, but the Link process works only with Library Files on physical disks.

Do we have a manual for the 99 Fortran program? The system is very interesting, even if you have to follow the syntax exactly.

+Vorticon · April 2, 2020

5 hours ago, wolhess said:

Do we have a manual for the 99 Fortran program? The system is very interesting, even if you have to follow the syntax exactly.

Here you go

99-9640 FORTRAN Version 4 by LGMA Products.pdf

99-9640 FORTRAN Manual Errata Sheet (14-Feb-90 Rev.7).pdf

wolhess · April 2, 2020

Thank you, now I have something to read and to learn.

I tried to run the logistic equation program from the E/A Module, but I got only a green screen and nothing happens. From the 99 Fortran menu it works fine.

I compiled and linked the program again and used only my real floppy drive. The program runs from the 99 Fortran menu. I changed to the E/A (in my FG99) and it runs once from E/A option 5. The second try I got the green screen again. Do I something wrong? After a reset the same program runs from the 99 Fortran menu again.

+dhe · April 2, 2020

Compiler Complaint. Nope, Not a Warning, Not an Error.

This was the first program that seemed to really want to use a scratch disk.

I'm sure I've put something in the code the compiler, doesn't like, but it has me baffled.

Can anyone else play spot the error?

1                               Version 4.42                Page   0001                    
0      0001 C FI_S - FILE I/O SOURCE 04/02/2020
       0002 C2345678
       0003       CHARACTER NAME(8)
       0004
       0005       INTEGER FILEID(8),ERROR,GRADE
       0006       DATA FILEID / 10HDSK2.FI_D /
       0007       CALL OPEN ( 3, FILEID, 2, 0, 1, 0, 80, ERROR)
       0008
       0009     1 FORMAT ('+', C12, M1.1, 'GRADES:' )
       0010       WRITE (6,1)
       0011
       0012    10 FORMAT ( 8A1, 1X, I3)
       0013       READ (3, 10, END=99) NAME, GRADE
       0014
       0015    20 FORMAT ('+', M2.1, 8A1, 1X, I3)
       0016       WRITE (6,20) NAME, GRADE
       0017
       0018
       0019 C 3 - FILE NUMBER, NO EQ TO A FORTRAN UNIT NUMBER USED IN FORMAT
       0020 C 2 - INPUT MODE
       0021 C 0 - DISPLAY
       0022 C 1 - VARIABLE
       0023 C 0 - SEQ ACCESS
       0024 C 80 - MAX RECORD LENGTH
       0025 C ERROR - VARIABLE TO RETURN ERROR IN
       0026
       0027 C     SEE PAGE 07-11 - FILE I/O REF
       0028 C     SEE CALC1 FOR FILE I/O EXAMPLES
       0029
       0030 C  NAME = 8   HOL
       0031 C  SPACE = 1  HOL
       0032 C  GRADE = 3  INT
       0033
       0034
       0035    99 CALL CLOSE ( 3 )
       0036       STOP
 
1           Allocation          Version 4.42                Page   0002                    
0 Statement Labels:
 
    0001 0042         0010 006A         0020 0096         0099 00C6
0 Subprogram References:
 
         OPEN              CLOSE             STOP$             CALL$
0 Local Data Area:
 
  0004 i GRADE      0006 i ERROR      0008 k NAME       0010 i FILEID
0 Logic Size:   00D8
  Data Size:    0020
0 Module Size:  00F8
    0000  Warning(s)
    0000  Error(s)
1                               Version 4.42                Page   0001                    
0      0001       END
 
1           Allocation          Version 4.42                Page   0002                    
0 Subprogram References:
 
         STOP$
0 Logic Size:   002A
  Data Size:    0004
0 Module Size:  002E
    0000  Warning(s)
    0000  Error(s)
1                               Version 4.42                Page   0001                    
0      0001
    **Error-  Don't understand this statement
       0002
       0003
       0004
       0005
       0006
       0007
       0008
       0009
       0010
       0011
       0012
       0013
       0014
       0015
       0016
       0017
       0018
       0019
       0020
       0021
            >EOD
            >EOD
1           Allocation          Version 4.42                Page   0002                    
0 Subprogram References:
 
         STOP$
0 Logic Size:   002A
  Data Size:    0004
0 Module Size:  002E
    0000  Warning(s)
    0001  Error(s)

+Vorticon · April 3, 2020

5 hours ago, wolhess said:

Thank you, now I have something to read and to learn.

I tried to run the logistic equation program from the E/A Module, but I got only a green screen and nothing happens. From the 99 Fortran menu it works fine.

I compiled and linked the program again and used only my real floppy drive. The program runs from the 99 Fortran menu. I changed to the E/A (in my FG99) and it runs once from E/A option 5. The second try I got the green screen again. Do I something wrong? After a reset the same program runs from the 99 Fortran menu again.

You have to use the utility menu to create an EA executable. The process is detailed in the Errata section 9.4.2

+Vorticon · April 3, 2020

5 hours ago, dhe said:

Compiler Complaint. Nope, Not a Warning, Not an Error.

This was the first program that seemed to really want to use a scratch disk.

I'm sure I've put something in the code the compiler, doesn't like, but it has me baffled.

Can anyone else play spot the error?


1                               Version 4.42                Page   0001                    
0      0001 C FI_S - FILE I/O SOURCE 04/02/2020
       0002 C2345678
       0003       CHARACTER NAME(8)
       0004
       0005       INTEGER FILEID(8),ERROR,GRADE
       0006       DATA FILEID / 10HDSK2.FI_D /
       0007       CALL OPEN ( 3, FILEID, 2, 0, 1, 0, 80, ERROR)
       0008
       0009     1 FORMAT ('+', C12, M1.1, 'GRADES:' )
       0010       WRITE (6,1)
       0011
       0012    10 FORMAT ( 8A1, 1X, I3)
       0013       READ (3, 10, END=99) NAME, GRADE
       0014
       0015    20 FORMAT ('+', M2.1, 8A1, 1X, I3)
       0016       WRITE (6,20) NAME, GRADE
       0017
       0018
       0019 C 3 - FILE NUMBER, NO EQ TO A FORTRAN UNIT NUMBER USED IN FORMAT
       0020 C 2 - INPUT MODE
       0021 C 0 - DISPLAY
       0022 C 1 - VARIABLE
       0023 C 0 - SEQ ACCESS
       0024 C 80 - MAX RECORD LENGTH
       0025 C ERROR - VARIABLE TO RETURN ERROR IN
       0026
       0027 C     SEE PAGE 07-11 - FILE I/O REF
       0028 C     SEE CALC1 FOR FILE I/O EXAMPLES
       0029
       0030 C  NAME = 8   HOL
       0031 C  SPACE = 1  HOL
       0032 C  GRADE = 3  INT
       0033
       0034
       0035    99 CALL CLOSE ( 3 )
       0036       STOP
 
1           Allocation          Version 4.42                Page   0002                    
0 Statement Labels:
 
    0001 0042         0010 006A         0020 0096         0099 00C6
0 Subprogram References:
 
         OPEN              CLOSE             STOP$             CALL$
0 Local Data Area:
 
  0004 i GRADE      0006 i ERROR      0008 k NAME       0010 i FILEID
0 Logic Size:   00D8
  Data Size:    0020
0 Module Size:  00F8
    0000  Warning(s)
    0000  Error(s)
1                               Version 4.42                Page   0001                    
0      0001       END
 
1           Allocation          Version 4.42                Page   0002                    
0 Subprogram References:
 
         STOP$
0 Logic Size:   002A
  Data Size:    0004
0 Module Size:  002E
    0000  Warning(s)
    0000  Error(s)
1                               Version 4.42                Page   0001                    
0      0001
    **Error-  Don't understand this statement
       0002
       0003
       0004
       0005
       0006
       0007
       0008
       0009
       0010
       0011
       0012
       0013
       0014
       0015
       0016
       0017
       0018
       0019
       0020
       0021
            >EOD
            >EOD
1           Allocation          Version 4.42                Page   0002                    
0 Subprogram References:
 
         STOP$
0 Logic Size:   002A
  Data Size:    0004
0 Module Size:  002E
    0000  Warning(s)
    0001  Error(s)

You are trying to read Name using 8A1 in the FORMAT statement, and so the program is expecting 8 single character variables while you are only giving it 1 array. Try using A only and see if it works.

Unfortunately, string handling in Fortran 99 is practically non-existent...

+Vorticon · April 3, 2020

Does anyone know how to read a binary file with Fortran 99? I keep getting a bad open attribute error any time I try to access a binary file despite using the internal option. Also the READ command assumes an ASCII input and there is nothing in the manual about this.

wolhess · April 3, 2020

6 hours ago, Vorticon said:

You have to use the utility menu to create an EA executable. The process is detailed in the Errata section 9.4.2

Yes, I followed the process described in 9.4.2 an it works fine. Thank You!

wolhess · April 3, 2020

I think my 99 Fortran environment works fine now.

Today I tried an example for passing data between two programs using a disk file

From the User Reference Manual Apendices Page 0A-5.

It works for file names with two characters as used in the manual, but for filenames with more than two characters I get an error. I will more read the manual, maybe I missed something about file names or have to define a constant or a variable.

It’s also an example to chain a second program BX from the fist program AX

This is the first program:

C 99-9640 FORTRAN Version 4 by LGMA Products

C APPENDICES Page 0A-5

C A.4.1 Inter-Program Communication

C Passing Data Using Disk Files

C needs Executable File DSK1.BX

C slightly modified by wolhess

C 03.04.2020

C Compiling

C Source: DSK1.WFILE-FS

C Object: DSK1.WFILE-FO

C Compiler List File: DSK1.WFILE-L1

C Linking

C Linker List File : DSK1.WFILE-L2

C Library File(s) : DSK2.FL

C Executable File : DSK1.AX

PROGRAM WFILE

X = 1.0

I = 12

WRITE (6,9300)

CALL OPEN ( 1, 'DSK1.TT ', 1, 0, 0, 0, 16, IERR )

WRITE ( 1, 9100 ) X, I

9100 FORMAT ( F10.6, I6 )

CALL CLOSE(1)

WRITE ( 6, 9200 ) X, I

CALL CHAIN ( 'DSK1.BX ', ERROR )

9200 FORMAT ( 1X, F10.6, I6 )

9300 FORMAT ('+', C12, M5.2,'Write one Record to File DSK1.TT',M7.2)

END

And this is the second program:

C 99-9640 FORTRAN Version 4 by LGMA Products

C APPENDICES Page 0A-5

C A.4.1 Inter-Program Communication

C Passing Data Using Disk Files

C needs Executable File DSK1.AX

C slightly modified by wolhess

C 03.04.2020

C Compiling

C Source: DSK1.RFILE-FS

C Object: DSK1.RFILE-FO

C Compiler List File: DSK1.RFILE-L1

C Linking

C Linker List File : DSK1.RFILE-L2

C Library File(s) : DSK2.FL

C Executable File : DSK1.BX

PROGRAM RFILE

WRITE(6,*)' '

WRITE(6,*)'READ FILE DSK1.TT'

CALL OPEN ( 1, 'DSK1.TT ', 2, 0, 0, 0, 16, IERR )

READ ( 1, 9100 ) X, I

CALL DELETE(1)

WRITE ( 6, 9200) X, I

WRITE ( 6, 9300)

1000 CALL KEY(0, KEYC, ISTATUS)

IF (ISTATUS .EQ. 0) GOTO 1000

9100 FORMAT ( F10.6, I6 )

9200 FORMAT ( 1X, F10.6, I6 )

9300 FORMAT ( '+', M20.2, 'Press any Key', M22.2)

END

+Vorticon · April 3, 2020

So I found a way to read binary data, but it involved having Display Fixed records of length 1 byte, which is incredibly inefficient. Unfortunately, Fortran 99's file I/O is strictly ASCII based because it's primarily modeled after Fortran 66, so the only way I could get it to read a binary file was to break the file into 1 byte records, read each record as a character, and transfer it to an integer variable where it's ASCII value is stored then processed. There is unfortunately no block read or write facility. This makes binary file access dreadfully slow, as demonstrated in the video below where I load a bitmap image created with Tursi's Convert9918 utility program. The TIFILES header of the images was sector edited to convert the files to a DF 1 type under guidance from Tursi. Did I mention he was a very versatile and brilliant guy?

On the upside, this whole exercise was a great way to practice file access and VDP RAM writing.

Here's the disk image with all the needed files if you want to try it out. It should reside in DSK3.

IMGSHOW.dsk

And here's the program listing:

      PROGRAM IMGTEST
 
      INTEGER CT, PDT, ERR, DATABYTE
      CHARACTER IMGP(14), IMGC(14)
      DATA IMGP / 14HDSK3.VIGER4_P /
      DATA IMGC / 14HDSK3.VIGER4_C /
 
      CALL CLEAR
      CALL FILES(1)
      CALL SETMOD(4)
      CALL SCREEN(2, 16)
 
      PDT = 0
      CT = 8192
      CALL OPEN(1, IMGP, 2, 0, 0, 0, 1, ERR)
      IF (ERR .NE. 0) THEN
        PRINT , 'FILE ERROR!', ERR
        STOP
      ENDIF
10    FORMAT(A)
      DO 20 I = 1, 6144
        READ(1, 10) DATABYTE
        CALL VMBW(PDT, DATABYTE, 1)
        PDT = PDT + 1
20    CONTINUE
      CALL CLOSE(1)
 
      CALL OPEN(1, IMGC, 2, 0, 0, 0, 1, ERR)
      IF (ERR .NE. 0) THEN
        PRINT , 'FILE ERROR!'
        STOP
      ENDIF
      DO 30 I = 1, 6144
        READ(1, 10) DATABYTE
        CALL VMBW(CT, DATABYTE, 1)
        CT = CT + 1
30    CONTINUE
      CALL CLOSE(1)

40    CALL KEY(0, KEYC, ISTATUS)
      IF (ISTATUS .EQ. 0) GOTO 40
      CALL EXIT
      END

Tursi · April 4, 2020

hehe, glad you got it working!

I like watching TI Bitmap mode draw, but dang!

+Vorticon · April 4, 2020

5 hours ago, Tursi said:

I like watching TI Bitmap mode draw, but dang!

Yup...

Now I'm going to try using assembly support with Fortran 99 to speed things up a bit. More to come

+dhe · April 5, 2020

I put in a lot of effort this week with fortran99, but didn't make much progress.

I did finally:

A) Refine my disk layout with comment.

B) Figured out how to remove NULL's inserted in listings, so output could be cut and pasted.

C) Bonus, Tursi told me of a special DSR feature that allows funky programs to be sent to disk files.

==================================================================================================================
			
			** Dealing with pesky nulls in listing files **

Open your file in Notepad++ or textpad
Type Control-A (select all)
Type Control-H (replace)
In 'Find What' type \x00
In 'Replace With' leave BLANK
In 'Search Mode' Selected 'Extended'
Then Click on 'Replace All'
share
MAKE SURE IN HEXPAD to search in hex.

==================================================================================================================
			
			** Classic99 Setup for fortran99 **

Disk     Used For                                   type               name                 
----------------------------------------------------------------------------------------------
Slot 1 - Compiler - static                         -disk               dsk1\fortcomp.dsk  
----------------------------------------------------------------------------------------------
Slot 2 - Source - semi static                      -disk               fortsrc\source.dsk     
----------------------------------------------------------------------------------------------
Slot 3 - Object                                     fiad               \object\
----------------------------------------------------------------------------------------------
Slot 4 - Executable / Listing (Compile)             fiad               \list\               
----------------------------------------------------------------------------------------------
Slot 5 - Scratch - Only Used on Compile             fiad               \scratch\scratch.dsk
                      / Listing (Linker)
----------------------------------------------------------------------------------------------

Compile - Has all five disks going at once.

SEEING LOGS:
  Did you try printing in Classic99 to "DSK1.?W.FILE.TXT" ? The ".?W." part is important, it should make Classic99 write a Windows text file instead of a TI file. If it doesn't, read the debug log (in the debugger) to see why not. 
  
  
 ** Have received file i/o when scratch was set to fiad, instead of disk image. 04/03/2020

+Vorticon · April 5, 2020

And here's the same bitmap image loaded using a simple assembly language subroutine with Fortran 99. The video speaks for itself

The actual Fortran code is minimal:

      PROGRAM IMGSHOW
 
      CALL FILES(1)
      CALL SETMOD(4)
      CALL SCREEN(2, 1)
 
      CALL IMGSHW
 
10    CALL KEY(0, KEYC, ISTATUS)
      IF (ISTATUS .EQ. 0) GOTO 10
      CALL SETMOD(1)
      CALL EXIT
      END

Here's the short assembly routine. It takes advantage of the LOAD opcode in the file I/O to block load the image into the VDP.

       DEF  IMGSHW
 
VMBW   EQU  >2048
DSRLNK EQU  >2058
PABADR EQU  >1B02        PAB ADDRESS IN VDP
BASEAD BSS  2            SUBROUTINE RETURN POINTER
RETADR BSS  2            SUBROUTINE RETURN POINTER
 
 
IMGSHW EQU  $
       DATA -0           NUMBER OF PASSED ARGUMENTS
       DATA BASEAD
 
PABP   DATA >0500,>0000,>0000,>1800,>000D
       TEXT 'DSK3.VIGER4_P'
       EVEN
PABC   DATA >0500,>2000,>0000,>1800,>000D
       TEXT 'DSK3.VIGER4_C'
       EVEN
 
* LOAD PATTERN FILE
       LI   R0,PABADR
       LI   R1,PABP
       LI   R2,23
       BLWP @VMBW
       LI   R6,PABADR+9
       MOV  R6,@>8356
       BLWP @DSRLNK
       DATA 8
 
* LOAD COLOR FILE
       LI   R0,PABADR
       LI   R1,PABC
       LI   R2,23
       BLWP @VMBW
       LI   R6,PABADR+9
       MOV  R6,@>8356
       BLWP @DSRLNK
       DATA 8
 
* RETURN TO MAIN PROGRAM
       MOV  @BASEAD,R3
       MOV  @RETADR,R11
       B    *R11
       END

The one issue is that the program locks up the computer upon exit. I don't think it likes me playing with file I/O outside of the Fortran environment...

Tursi · April 5, 2020

You can check in the Classic99 debugger what the CALL FILES(1) sets the top of VDP RAM to -- if it's lower than >3800 then the disk buffers are being corrupted by the image load. Normally 1 is enough, but maybe Fortran does things differently.

Classic99 tries to complain about situations like the disk buffers being corrupted, so it may give you a clue if that's it.

+dhe · April 5, 2020

I really feel bad, even to put in a note like I did about the odd scratch disk thing. The real way of course to deal with a problem like that, would be for ME to try on real hardware, identically configured, with the exact same bits, reproducing the error or non-error in the same step by step fashion.

It was really just something I observed, as a reminder, to myself, of why I flipped dsk5., back to a disk image. I'm not even sure if fortran99 has a real limit, of dsk5. I am aware earlier versions had a limit of (3) - but I do know, many disks will get corrupt real quick, if you try to assemble and list to the same disk, so I try to make each disk do one thing.. Then I can say to each disk, you have one job, and one job only! ?

+Vorticon · April 5, 2020

7 hours ago, Tursi said:

You can check in the Classic99 debugger what the CALL FILES(1) sets the top of VDP RAM to -- if it's lower than >3800 then the disk buffers are being corrupted by the image load. Normally 1 is enough, but maybe Fortran does things differently.

Classic99 tries to complain about situations like the disk buffers being corrupted, so it may give you a clue if that's it.

Conveniently, the CALL FILES routine is actually listed in the manual as an example of a machine language subroutine, but I'm not too clear on it. It appears that the PAB area is set at >1000, and the disk buffer is at >31B6 for a CALL FILES(1). Not sure how that would work since >1000 is smack in the PDT area in bitmap mode, and yet I have been able to do file I/O previously without issues within the Fortran environment. Furthermore, when setting up the PAB, it's loading >832C (which it calls pointer to file descriptor) with the PAB base - 7, i.e >0FF9 and I have no clue what that does. It also supplies DSRLNK with >000A instead of the usual >0008 for file I/O. And by the way there is no disk buffer corruption error with the debugger.

The CALL FILES routine is listed on page 0A-12 of the attached Fortran manual for reference.

99-9640 FORTRAN Version 4 by LGMA Products.pdf

HOME AUTOMATION · April 5, 2020

10 hours ago, Vorticon said:

The one issue is that the program locks up the computer upon exit.

Looks like, you left out this reciprocal instruction...

MOV  R11,@RETADR

HOME AUTOMATION · April 5, 2020

:roll: ...I wasn't done editing yet!

I hate it when that happens! :ponder:

Tursi · April 5, 2020

2 hours ago, dhe said:

I really feel bad, even to put in a note like I did about the odd scratch disk thing. The real way of course to deal with a problem like that, would be for ME to try on real hardware, identically configured, with the exact same bits, reproducing the error or non-error in the same step by step fashion.

It was really just something I observed, as a reminder, to myself, of why I flipped dsk5., back to a disk image. I'm not even sure if fortran99 has a real limit, of dsk5. I am aware earlier versions had a limit of (3) - but I do know, many disks will get corrupt real quick, if you try to assemble and list to the same disk, so I try to make each disk do one thing.. Then I can say to each disk, you have one job, and one job only! ?

Do they get corrupt in real life, or only Classic99? The two disk corruption bugs I recently fixed would definitely corrupt any disk that was writing two output files.

Tursi · April 5, 2020

33 minutes ago, Vorticon said:

Conveniently, the CALL FILES routine is actually listed in the manual as an example of a machine language subroutine, but I'm not too clear on it. It appears that the PAB area is set at >1000, and the disk buffer is at >31B6 for a CALL FILES(1). Not sure how that would work since >1000 is smack in the PDT area in bitmap mode, and yet I have been able to do file I/O previously without issues within the Fortran environment. Furthermore, when setting up the PAB, it's loading >832C (which it calls pointer to file descriptor) with the PAB base - 7, i.e >0FF9 and I have no clue what that does. It also supplies DSRLNK with >000A instead of the usual >0008 for file I/O. And by the way there is no disk buffer corruption error with the debugger.

The CALL FILES routine is listed on page 0A-12 of the attached Fortran manual for reference.

Hmmm... the PAB at >1000 MIGHT be an issue, but that's strange because you load the pattern table first, and it doesn't appear to be corrupt when you load the color table. Classic99 will also tell you the actual PABs in use in the log. The DSRLNK settings are for the subprogram call (instead of a file I/O call).

The next step if the debug log offers no clues is to breakpoint after the load and see where it's stuck.

Fortran99 Challenge

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members