+mizapf Posted April 1, 2020 Share Posted 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 ................ 2 Quote Link to comment Share on other sites More sharing options...
+DuaneAL Posted April 2, 2020 Share Posted 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! Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 2, 2020 Share Posted 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. 2 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 2, 2020 Share Posted 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 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 2, 2020 Share Posted 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. 2 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 2, 2020 Share Posted 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 3 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 2, 2020 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
+dhe Posted April 2, 2020 Author Share Posted 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) Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 3, 2020 Share Posted 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 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 3, 2020 Share Posted 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... Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 3, 2020 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 3, 2020 Share Posted 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! Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 3, 2020 Share Posted 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 3 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 3, 2020 Share Posted 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 4 Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 4, 2020 Share Posted April 4, 2020 hehe, glad you got it working! I like watching TI Bitmap mode draw, but dang! Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 4, 2020 Share Posted 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 2 Quote Link to comment Share on other sites More sharing options...
+dhe Posted April 5, 2020 Author Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 5, 2020 Share Posted 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... 4 Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 5, 2020 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
+dhe Posted April 5, 2020 Author Share Posted 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! ? Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 5, 2020 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted April 5, 2020 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted April 5, 2020 Share Posted April 5, 2020 ...I wasn't done editing yet! I hate it when that happens! Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 5, 2020 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 5, 2020 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.