Jump to content
IGNORED

Fortran99 Challenge


dhe

Recommended Posts

2 hours ago, HOME AUTOMATION said:

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

 


MOV  R11,@RETADR

Fortean 99 handles that automatically. All I have to do is reserve 4 bytes in BASEAD and RETADR. I should clarify that the subprogram returns normally to the main program and the main issue is when that main program terminates.

Link to comment
Share on other sites

OK I figured out how to properly restore the Fortran 99 environment after accessing files in bitmap mode with assembly subroutines.

Apparently the CRT has to be reopened as FILE 6 using something called the File Open Processor routine located at >2070 and I have no clue as what that routine does exactly. I got this straight out from the CALL FILES subroutine by sheer trial and error. Here's the revised bitmap image display routine:

 

       DEF  IMGSHW
 
VMBW   EQU  >2048
DSRLNK EQU  >2058
OPFILE EQU  >2070        FILE OPEN PROCESSOR
PABADR EQU  >3A12        PAB ADDRESS IN VDP
BASEAD BSS  2            SUBROUTINE RETURN POINTER
RETADR BSS  2            SUBROUTINE RETURN POINTER
 
 
IMGSHW 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
 
CRTPAB DATA >0003,>0000,>5000,>0000,>0003
       TEXT 'CRT'
       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
       LI   R0,6
       LI   R1,CRTPAB
       BL   @OPFILE
       MOV  @BASEAD,R3
       MOV  @RETADR,R11
       B    *R11
       END
 
 

The 3 lines below the RETURN TO MAIN PROGRAM comment is where the magic occurs. Don't ask me why but would love to hear an explanation if somebody has one :lol:

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Finally got some simple i/o going...

Some first observations:

  1) I kept getting an odd error -  don't understand >eod - Vorticon nailed this error, some junk had appeared after end...

       ( I think this is a bug)... Easy enough to work around once you know what the problem is.....

  2) the end in the read, seems to sense end of data line, not end of file, I had to default to

       reading for a z (or 9999) record at the end of the data file.

  3) could not get Hollerith or S types to work in a file read.

  4) could not get just A to work.

  5) what ended up working was 8a1 - because, it seems like fortran99 only wants to do single character

      i/o.

 

1  99 FORTRAN File: DSK2.FI_S                                      Page    1
 
     1. C FI_S - FILE I/O SOURCE 04/06/2020
     2. C2345678
     3. C     DEFINE DATA TYPES
     4.       CHARACTER NAME(8)
     5.       INTEGER ERRSTS, NSTU, GRATOT, AVGGRA
     6.
     7.       INTEGER FILEID(8), GRADE
     8.       DATA FILEID / 10HDSK2.FI_D /
     9.
    10. C     INITALIZE DATA
    11.       NSTU = 0
    12.       GRATOT = 0
    13.       AVGGRA = 0
    14.
    15.       CALL FILES (3)
    16.       CALL OPEN ( 3, FILEID, 2, 0, 1, 0, 80, ERRSTS)
    17.
    18.     1 FORMAT (' ', C12, M1.1, '     ***  GRADES  ***' )
    19.     2 FORMAT (' ', ' ')
    20.       WRITE (6,1)
    21.       WRITE (6,2)
    22.
    23.    10 FORMAT ( 8A1, I3)
    24.    11 READ (3, 10, END=99, STATUS=ERRSTS ) NAME, GRADE
    25.
    26.       IF (GRADE.EQ.999) THEN
    27.          GO TO 25
    28.       ENDIF
    29.
    30.    20 FORMAT (' ', 8A1 , 1X, I3)
    31.       WRITE (6,20) NAME, GRADE
    32.
    33.       GRATOT = GRATOT + GRADE
    34.       NSTU   = NSTU + 1
    35.
    36.       GO TO 11
    37.
    38.
    39.    25 CONTINUE
    40.    30 FORMAT (' ',' ')
    41.    35 FORMAT ('+', 'AVG GRADE:')
    42.       WRITE (6,30)
    43.       WRITE (6,35)
    44.
    45. C     CALCULATE AVG GRADE - SIMPLE AVG
    46.       AVGGRA = GRATOT / NSTU
    47.    40 FORMAT (' ', I3)
    48.       WRITE (6,40) AVGGRA
    49.
    50.
    51. C 3 - FILE NUMBER, NO EQ TO A FORTRAN UNIT NUMBER USED IN FORMAT
    52. C 2 - INPUT MODE
    53. C 0 - DISPLAY
    54. C 1 - VARIABLE
    55. C 0 - SEQ ACCESS
1  99 FORTRAN File: DSK2.FI_S                                      Page    2
 
    56. C 80 - MAX RECORD LENGTH
    57. C ERROR - VARIABLE TO RETURN ERROR IN
    58.
    59. C     SEE PAGE 07-11 - FILE I/O REF
    60. C     SEE CALC1 FOR FILE I/O EXAMPLES
    61.
    62. C  NAME = 8   HOL
    63. C  SPACE = 1  HOL
    64. C  GRADE = 3  INT
    65.
    66.
    67.    99 CALL CLOSE ( 3 )
    68.       STOP
    69.       END

 

and the data file...

 

1  99 FORTRAN File: DSK2.FI_D                                      Page    1
 
     1. DAN     060
     2. SALLY   100
     3. BOB     074
     4. JOE     097
     5. EOF     999

Small working, byte size pieces of code is what you build off of.

 

 

  • Like 2
Link to comment
Share on other sites

So, it was asked here, how does fortran99 compare speed wise to other compilers.

 

I decided to write two little programs that looped and printed a value. Our first contender, while not a compiled language, was BASIC

10 FOR I=1 TO 100
20 PRINT I
30 NEXT I

This took 19 seconds to run.

For a comparison - in BASIC on my little Cambridge Z88 - it took 8 seconds.

 

Next up was FORTRAN99

1  99 FORTRAN File: DSK2.SC_S                                      Page    1
 
     1. C QUICK FOR LOOP SPEED COMPARISON VS TI BASIC 04/07/2020
     2. C234567
     3.       INTEGER I
     4.
     5.       CALL CLEAR
     6.
     7.       I = 1
     8.       DO 1 I=1,100
     9.          PRINT , I
    10.
    11.     1 CONTINUE
    12.       STOP
    13.       END

This took 8 seconds to run.

 

Of course, even the simplistic program wasn't a walk in the park and included a fight with the compiler and linker. Over and above speed, not being tied to line numbers is great. I think Microsoft realized late in life, line numbers {BAD}, because on the Tandy Model 100, the last machine, I'm told that Bill Gates worked on, when you type edit, the line numbers are there, but your in full screen editing mode.

 

VORTICON again came to my rescue. The take away, I believe, if you want to use call clear (and maybe print) you have to link in the gl (graphics) library. The manual says, you will keep being prompted for libraries, until all dependencies have been resolved. That was not the behavior I was seeing. Instead, I would enter fl, and it would take me to the section about symbolic debugging. To force what I needed to happen, I entered gl on the library line, the linker, then prompted me again, for a library, this time, I entered fl.

 

That did the trick, I was now able to run the program, I did end up with so oddities, in the compiler. It would say I had 1 Error(s) - but it wouldn't tell me what that error was! fortran99 can be a tough task master! ?

 

I'm very much, hoping someday the source for FORTRAN99 show up, because, as a new user, I'm seeing a few rough spots, that probably wouldn't be that hard to fix, with specific test cases.

 

d.

 

 

Link to comment
Share on other sites

In Extended Basic it takes about 10 secs.

 

I believe programs that scroll the screen will spend most of their time in the scrolling routine, so it's not a good comparison of the actual languages.

 

Edited by Asmusr
Link to comment
Share on other sites

: SC_S  \ print index value of 100 times through loop
   PAGE         \ clear screen
   100 0 DO
      I .      \ print loop index
   LOOP
;

Same here.

I would think that this Fortran compiler is pretty naive, meaning it doesn't have a lot of room for optimizing options and simply converts the source code one way.

The TI99 doesn't give it much room to flex those kind of muscles. :)  It's remarkable that it does as much as it does.

It would be fun to see the table of emitted routines.

 

printloopindex.jpg

  • Like 1
Link to comment
Share on other sites

13 hours ago, Asmusr said:

In Extended Basic it takes about 10 secs.

 

I believe programs that scroll the screen will spend most of their time in the scrolling routine, so it's not a good comparison of the actual languages.

 

Indeed! Rewriting the Fortran program to avoid scrolling, it took it 2.63 seconds to complete the loop. It would have been even faster without the CALL CLEAR at the beginning. It took TI BASIC 13.18 seconds for something similar, so about 5x slower. 

 

      PROGRAM LOOP
 
      CALL CLEAR
      DO 10 I = 1, 100
10    WRITE(6, 20) I
20    FORMAT('+', I3)
      STOP
      END

Now taking the CALL CLEAR and PRINT out of the programs, TI BASIC clocked at 0.93 seconds! I couldn't time the Fortran equivalent as it was way too fast for my reflexes.

The lesson? Don't print anything to screen unless you absolutely have to :)

  • Like 1
Link to comment
Share on other sites

So I've been playing with this Fortran package for a couple of weeks. Impression? It's definitely a clunky language with very limited file I/O and no support for string functions, but with superior math functions and numerical representations. It has its limited uses, but it's certainly not a good general purpose language, although the addition of the TI specific graphic extensions helped getting it closer in that direction.

As TheBF mentioned, it likely does not optimize code very well, so performance has much to be improved upon. Of course the latest version of Fortran (Fortran 2018) has since brought the language pretty much on par with modern languages with all the associated facilities such as OOP for example.

Nonetheless, it's still an impressive achievement given the limitations of the TI, and had it come out earlier in the prime of the TI market window (early 80's), it would have been a runaway hit particularly among the engineering types.

So what to do with it? I'd really like to come up with a project using it as a personal challenge and I have a couple of ideas. Developing in Fortran 99 is rather painful for complex programs, so that will be interesting, but since I've put in the effort to learn it, I should at least have something to show for it :) I have a simple rule: if I learn a new language, I should create at least one meaningful program using it. This has been true for TI BASIC, XB, TurboForth, C99, Turbo Pascal, TMS9900 assembly, Intel 8080 assembly, and Python, so I'm going to try not to break with that tradition!

  • Like 2
Link to comment
Share on other sites

4 hours ago, Vorticon said:

This has been true for TI BASIC, XB, TurboForth, C99, Turbo Pascal, TMS9900 assembly

that is very impressive! What kind of program did you develop in Turbo Pascal? With Turbo Pascal I wrote a few small programs on a Schneider CPC464 more than 30 years ago. On the TI-99, I want to look at that again.

 

I am despite the mentioned drawbacks of the opinion that Fortran deserves a chance on the TI.

Link to comment
Share on other sites

2 hours ago, wolhess said:

that is very impressive! What kind of program did you develop in Turbo Pascal? With Turbo Pascal I wrote a few small programs on a Schneider CPC464 more than 30 years ago. On the TI-99, I want to look at that again.

 

I am despite the mentioned drawbacks of the opinion that Fortran deserves a chance on the TI.

I agree. It's just not the easiest of environments to work with, although UCSD Pascal comes close :)

Here are my Turbo Pascal projects, all done on the Coleco Adam computer under CP/M. The ADAM computer uses the same 9918 VDP chip as the TI incidentally.

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

There is a lot of work involved, for me it looks as if you have adapted Turbo Pascal to the Coleco Adam very well. Thank you for providing the videos.

I find the possibility of supplementing Turbo Pascal with assembly routines very good. Would that also be possible on the TI Turbo Pascal?

 

 

Link to comment
Share on other sites

59 minutes ago, wolhess said:

There is a lot of work involved, for me it looks as if you have adapted Turbo Pascal to the Coleco Adam very well. Thank you for providing the videos.

I find the possibility of supplementing Turbo Pascal with assembly routines very good. Would that also be possible on the TI Turbo Pascal?

 

 

Turbo Pasc 99 is an incomplete implementation of Pascal, and is missing pointers among other things. Also I don't think we ever got the compiler to fully work. Anders Persson translated the docs from German (not an issue for you though!), and I'll have dig them out to see if there is access to assembly subroutines with it. UCSD Pascal is a far better implementation, but the environment is clunky. Anders is the resident guru on it and has done some amazing extensions to it.

  • Like 1
Link to comment
Share on other sites

Today's quicky. Graphics Experiment. Unlike my previous attempts, this one worked exactly as expected the first time~!

 

1  99 FORTRAN File: DSK2.GE_S                                      Page    1
 
     1. C GRAPHICS EXAMPLE - 04/08/2020 - DHE
     2. C2345678
     3.       CALL SET32
     4. C        THIS GETS YOU COLOR AND SPRITE ROUTINES
     5.
     6.       CALL COLOR ( 10, 10, 1)
     7. C      CHAR SET,  FORE, BACK COLORS
     8.
     9.       CALL CHAR ( 111, '1824429999422418'X )
    10. C      SPRITE BUILT WITH FSF.IO SPRITEPAINTER
    11.
    12.       PRINT , 'Hello World'
    13.
    14.       CALL DELAY ( 30 )
    15. C      WAITS 3 SECONDS, COMPARE WITH CALL WAIT
    16.
    17.       CALL SPCHAR ( 128, '1824429999422418'X )
    18. C      CHARCODE 128-255 ONLY
    19.       CALL SPRITE ( 1, 128, 5, 92, 1, 24, -1, 3)
    20.
    21.       CALL DELAY ( 40 )
    22.
    23.       STOP
    24.       END
   

 

  • Like 1
Link to comment
Share on other sites

3 minutes ago, Vorticon said:

Turbo Pasc 99 is an incomplete implementation of Pascal, and is missing pointers among other things. Also I don't think we ever got the compiler to fully work.

I managed to write some few TurboPasc'99 programs back in those days.

 

If someone is interested in trying UCSD Pascal, remember that it is available in MAME, maybe just to get an idea (and for the sensation of having have saved several hundreds of DM/Dollars/FF/Pta/Lit (no Euro in that era)).

  • Like 1
Link to comment
Share on other sites

41 minutes ago, mizapf said:

I managed to write some few TurboPasc'99 programs back in those days.

 

If someone is interested in trying UCSD Pascal, remember that it is available in MAME, maybe just to get an idea (and for the sensation of having have saved several hundreds of DM/Dollars/FF/Pta/Lit (no Euro in that era)).

It's definitely usable, but without pointers, linked lists etc..., certainly crippled. I think the problem with the compiler is a bad disk image. If you happen to still have the disks, would you mind posting them?

As for UCSD Pascal, it's Achilles heel was the very high cost of entry (3 disk drives, 32K, pcode card), so yes using an emulator is definitely the cheaper option :) I should mention that it is also fully implemented in Classic 99 as well.

Link to comment
Share on other sites

What I have been doing, is printing the source {one of the options on the edit menu} to DSK4.?W.{SOMETHING}_LI - and then just navigating to that directory with textpad.

 

Here is another, iteration. ti99dir, in to the source disk and then opening the file.

 

C GRAPHICS EXAMPLE - 04/08/2020 - DHE
C2345678
      CALL SET32
C        THIS GETS YOU COLOR AND SPRITE ROUTINES
 
      CALL COLOR ( 10, 10, 1)
C      CHAR SET,  FORE, BACK COLORS
 
      CALL CHAR ( 111, '1824429999422418'X )
C      SPRITE BUILT WITH FSF.IO SPRITEPAINTER
 
      PRINT , 'Hello World'
 
      CALL DELAY ( 30 )
C      WAITS 3 SECONDS, COMPARE WITH CALL WAIT
 
      CALL SPCHAR ( 128, '1824429999422418'X )
C      CHARCODE 128-255 ONLY
      CALL SPRITE ( 1, 128, 5, 92, 1, 24, -1, 3)
 
      CALL DELAY ( 40 )
 
      STOP
      END

 

 

  • Like 2
Link to comment
Share on other sites

21 hours ago, Vorticon said:

It's definitely usable, but without pointers, linked lists etc..., certainly crippled. I think the problem with the compiler is a bad disk image. If you happen to still have the disks, would you mind posting them?

I'll have to search through my collection. Maybe you can send me your copy so I can see whether it is really a corruption. I seem to remember that there was a glitch with the loader, which assumed that an unused memory space looks like FF00FF00...

Link to comment
Share on other sites

I'm really hoping Beery can get the source to FORTRAN99, there are a couple of things, I'd like to change, and I think easy fixes and upgrades (even for me).

Like, I'd like to normalize more the selections on edit/compiler and link (like on compile, listing file is the third item asked for, on link the first) - consistency would help.

 

I'd also like to modify, so if you have a minimem, or supercart, your default selections would be saved after the first run. fortran99 could have used a few more years of active development and maybe 20 active developers to shake out rough patches....

 

d.

 

Link to comment
Share on other sites

1 hour ago, mizapf said:

I'll have to search through my collection. Maybe you can send me your copy so I can see whether it is really a corruption. I seem to remember that there was a glitch with the loader, which assumed that an unused memory space looks like FF00FF00...

I don't actually own the original package. I just used the disk images in the pinned Development Resources thread on this forum...

Link to comment
Share on other sites

I just did some checks in MAME with the version from the Development Resources thread.

 

- It is running in MAME, see the screenshots below. However, it seems as if there is some kind of copy protection, because after loading TP99, a lot of sectors are loaded before the greeting screen appears, and there is no file of that size. I let TIImageTool do a file system check, and the attached log proves it.

- Files that were built with TP99 only run in MAME when the internal 16bit 32K is turned off, and the external 32K expansion is used. This is what I just verified with MAME when trying to load SIEVE1. The reason is, as I remember, that the loader tests whether the libraries have already been loaded by checking whether the memory is filled with FF00. The internal 32K are filled with 0000, so the libraries are not loaded.

 

This was the reason why I stopped working with TurboPasc'99 around 1986, only a short time after I started with it. This was the time when I modded my TI console, and then, for some reason that was obscure to me back in those days, none of the Pascal programs could be loaded anymore.

 

Maybe one can make them run again using a loop of CALL LOAD(A,255,0) over the relevant memory space.

 

0123_2x.png

0124_2x.png

tp99compcheck.txt

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...