+Vorticon Posted April 5, 2022 Share Posted April 5, 2022 OK so I'm probably missing something very basic here, but can someone please tell me why running this snippet is giving me an I/O ERROR 25 (i.e. not enough data for the input variables)? 3320 OPEN #1:"DSK1.STATFILE",OUTPUT 3330 FOR I=1 TO 8 :: PRINT #1:HLIST(I) :: NEXT I 3340 PRINT #1:KFT,KCR,KTR,KCO,KMB,PFT,PCR,PTR,PCO,KHCOUNT,PHCOUNT,KCCOUT,TURN 3350 CLOSE #1 3360 OPEN #1:"DSK1.STATFILE",INPUT 3370 FOR I=1 TO 8 :: INPUT #1:HLIST(I) :: NEXT I 3380 INPUT #1:KFT,KCR,KTR,KCO,KMB,PFT,PCR,PTR,PCO,KHCOUNT,PHCOUNT,KCCOUT,TURN 3390 CLOSE #1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted April 5, 2022 Share Posted April 5, 2022 Try writing the values out as strings using STR$. I'm wondering if binary values are confusing the INPUT (i.e. parsing numeric radix 100 data as things such as line endings, carriage returns, or other control characters. 2 Quote Link to comment Share on other sites More sharing options...
Willsy Posted April 5, 2022 Share Posted April 5, 2022 Also: You're opening the file in DV80 yes? I think that is the default if you don't specify anything for the file mode. Are you sure the PRINT and INPUT are doing what you think they are doing? If you printed those values to the screen, rather than a file, you would see they were separated by a number of blank spaces (because each value is separated by a comma in the PRINT statement). Because you are using DV80 (maybe DF80?), a number of variables may fit into a single disk record. What happens if you replace line 3340 with individual PRINT, and line 3380 with individual INPUT statements? I've always had trouble writing and reading numeric values to a DISPLAY format file. IIRC, that's what INTERNAL is for. 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 5, 2022 Share Posted April 5, 2022 (edited) 1 hour ago, Vorticon said: OK so I'm probably missing something very basic here, but can someone please tell me why running this snippet is giving me an I/O ERROR 25 (i.e. not enough data for the input variables)? @Willsy is absolutely right. Using INPUT on a DISPLAY file is like trying to read a PRINTed screen and, obviously, not what you expected to happen. As Mark said, you need to PRINT to an INTERNAL file and INPUT from it in that mode as well. PRINTing in INTERNAL mode quotes strings as needed, stores numbers as radix 100, separating all the data with commas. ...lee Edited April 5, 2022 by Lee Stewart CORRECTIONS 2 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted April 5, 2022 Share Posted April 5, 2022 A couple excerpts from Classic99... PAB requested file type is DV0 Seek past end of file STATFILE Failed reading max 80 bytes DSK1.STATFILE on drive type Image Setting file error 5 on file buffer 27 Releasing file buffer 27 ...looks like it got as far as the 10th RECORD. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 5, 2022 Author Share Posted April 5, 2022 2 hours ago, Willsy said: Also: You're opening the file in DV80 yes? I think that is the default if you don't specify anything for the file mode. Are you sure the PRINT and INPUT are doing what you think they are doing? If you printed those values to the screen, rather than a file, you would see they were separated by a number of blank spaces (because each value is separated by a comma in the PRINT statement). Because you are using DV80 (maybe DF80?), a number of variables may fit into a single disk record. What happens if you replace line 3340 with individual PRINT, and line 3380 with individual INPUT statements? I've always had trouble writing and reading numeric values to a DISPLAY format file. IIRC, that's what INTERNAL is for. The output file appears correct will all the appropriate values in place separated by spaces. I think you and Lee are probably correct and I should convert the file to internal format particularly since it's all numeric data. That said, since the data elements in the file are separated by spaces and the input is all numeric variables, it should not have had too much trouble reading them. Me thinks it's a bug... Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted April 5, 2022 Share Posted April 5, 2022 This seems like a nice opportunity to peek under the hood and understand what basic does a bit deeper. It tries it's best to delineate those numbers, your joining operator can impact it. In display mode, if I remember correctly, you get quite a bit of padding too with a comma, and it'll fill that 80 character record limit quickly. Use a hex editor to peek into the file and see what the print did. Then try again with different delineation, semicolon, and ampersand... Try again with a variable 254 record size, and again with internal mode. It'll show you just how much work TI did to make BASIC a business language. 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 5, 2022 Share Posted April 5, 2022 19 minutes ago, Vorticon said: The output file appears correct will all the appropriate values in place separated by spaces. I think you and Lee are probably correct and I should convert the file to internal format particularly since it's all numeric data. That said, since the data elements in the file are separated by spaces and the input is all numeric variables, it should not have had too much trouble reading them. Me thinks it's a bug... I do not see it as a bug. All you need to do is to mimic the PRINT #1/INPUT #1 with INPUT from the keyboard to see the problem: >10 INPUT A,B >20 PRINT A,B >RUN ? 123 456 * WARNING INPUT ERROR IN 10 ? 123,456 123 456 * READY * ...lee 1 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted April 5, 2022 Share Posted April 5, 2022 34 minutes ago, Vorticon said: That said, since the data elements in the file are separated by spaces and the input is all numeric variables, it should not have had too much trouble reading them. Me thinks it's a bug... I don't think it's a bug (could be wrong). It's just not doing what you think its doing. Imagine: PRINT #1:100,200,300 Its easy to think that this creates three separate records, each with a numeric value (i.e. radix 100, a sequence of (10?) bytes). However, I do not believe it does. It creates ONE string record, with three numeric values in the record, each separated by a number of spaces (due to the use of the comma as a separator). That means, when you read them, since they are not three records, but a single record, you will read them using a single INPUT statement, into a single variable. They will come back as a string. I.e., "100 200 300" However, it can get more complicated! When writing binary data to a DISPLAY type file, certain bytes may be interpreted as the end of record, so in some cases you can never read back what you wrote. When we need to use binary data, we need the INTERNAL file mode. Quote Link to comment Share on other sites More sharing options...
Willsy Posted April 5, 2022 Share Posted April 5, 2022 45 minutes ago, Vorticon said: That said, since the data elements in the file are separated by spaces and the input is all numeric variables, it should not have had too much trouble reading them. Me thinks it's a bug... I think that particular problem is because you didn't specify a file type, so it defaulted to DISPLAY, and them some of the binary bytes in the radix 100 values are subsequently interpreted as control characters. I always surprised how powerful and comprehensive TIs file system was. I was stunned when I moved to other systems (PCs) only to find they have nothing like it. Just raw, dumb files - effectively everything is binary. Although the advantage of that is that nothing happens 'under the covers' - unlike TIs file system, where gotchas can easily catch you out! 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted April 5, 2022 Share Posted April 5, 2022 (edited) TI-99/4A User's Reference Guide P. II-133 Edited April 5, 2022 by HOME AUTOMATION better pic. 3 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 5, 2022 Share Posted April 5, 2022 57 minutes ago, Vorticon said: That said, since the data elements in the file are separated by spaces and the input is all numeric variables, it should not have had too much trouble reading them. In DISPLAY format, everything output by PRINT is in ASCII text and exactly as it would output to the screen or a printer. Numbers are not output in radix-100 format. That only happens for INTERNAL format. ...lee 4 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 5, 2022 Share Posted April 5, 2022 6 hours ago, Vorticon said: OK so I'm probably missing something very basic here, but can someone please tell me why running this snippet is giving me an I/O ERROR 25 (i.e. not enough data for the input variables)? 3320 OPEN #1:"DSK1.STATFILE",OUTPUT 3330 FOR I=1 TO 8 :: PRINT #1:HLIST(I) :: NEXT I 3340 PRINT #1:KFT,KCR,KTR,KCO,KMB,PFT,PCR,PTR,PCO,KHCOUNT,PHCOUNT,KCCOUT,TURN 3350 CLOSE #1 3360 OPEN #1:"DSK1.STATFILE",INPUT 3370 FOR I=1 TO 8 :: INPUT #1:HLIST(I) :: NEXT I 3380 INPUT #1:KFT,KCR,KTR,KCO,KMB,PFT,PCR,PTR,PCO,KHCOUNT,PHCOUNT,KCCOUT,TURN 3390 CLOSE #1 I would just do this and this fixes the issues: 3320 OPEN #1:"DSK1.STATFILE",OUTPUT 3330 FOR I=1 TO 8 :: PRINT #1:HLIST(I) :: NEXT I 3340 PRINT #1:KFT,KCR,KTR,KCO,KMB 3342 PRINT #1:PFT,PCR,PTR,PCO 3344 PRINT #1:KHCOUNT,PHCOUNT,KCCOUT,TURN 3350 CLOSE #1 3360 OPEN #1:"DSK1.STATFILE",INPUT 3370 FOR I=1 TO 8 :: INPUT #1:HLIST(I) :: NEXT I 3380 INPUT #1:KFT,KCR,KTR,KCO,KMB 3382 INPUT #1:PFT,PCR,PTR,PCO 3384 INPUT #1:KHCOUNT,PHCOUNT,KCCOUT,TURN 3390 CLOSE #1 Well after some investigation it errored out, turns out it is a data format error. It would be best to convert to all Strings and use LINPUT to retrieve the data. Or do a single variable at time like you did in for next loop. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted April 5, 2022 Share Posted April 5, 2022 I got an error with your version as well Rich. Just changing the file format to INTERNAL worked with your code. (so INT/VAR) 3000 OPEN #1:"DSK1.STATFILE",OUTPUT,INTERNAL 3010 FOR I=1 TO 8 :: PRINT #1:HLIST(I):: NEXT I 3020 PRINT #1:KFT,KCR,KTR,KCO,KMB 3030 PRINT #1:PFT,PCR,PTR,PCO 3040 PRINT #1:KHCOUNT,PHCOUNT,KCCOUT,TURN 3050 CLOSE #1 3060 OPEN #1:"DSK1.STATFILE",INPUT, INTERNAL 3070 FOR I=1 TO 8 :: INPUT #1:HLIST(I):: NEXT I 3080 INPUT #1:KFT,KCR,KTR,KCO,KMB 3090 INPUT #1:PFT,PCR,PTR,PCO 3100 INPUT #1:KHCOUNT,PHCOUNT,KCCOUT,TURN 3110 CLOSE #1 Using the original code however still failed with INTERNAL file format. 3320 OPEN #1:"DSK1.STATFILE",OUTPUT,INTERNAL 3330 FOR I=1 TO 8 :: PRINT #1:HLIST(I) :: NEXT I 3340 PRINT #1:KFT,KCR,KTR,KCO,KMB,PFT,PCR,PTR,PCO,KHCOUNT,PHCOUNT,KCCOUT,TURN 3350 CLOSE #1 3360 OPEN #1:"DSK1.STATFILE",INPUT,INTERNAL 3370 FOR I=1 TO 8 :: INPUT #1:HLIST(I) :: NEXT I 3380 INPUT #1:KFT,KCR,KTR,KCO,KMB,PFT,PCR,PTR,PCO,KHCOUNT,PHCOUNT,KCCOUT,TURN 3390 CLOSE #1 It looks like 3340 is failing trying to write 13 variables into one record. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 5, 2022 Share Posted April 5, 2022 Yea that is why upon inspection I determined it is a DATA FORMAT ERROR. If each line was PRINT #1:variable just like the 3330 FOR I=1 TO 8 :: PRINT #1:HLIST(I) :: NEXT I it would not error out. 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted April 5, 2022 Share Posted April 5, 2022 3320 OPEN #1:"DSK1.STATFILE",OUTPUT 3330 FOR I=1 TO 8 :: PRINT #1:HLIST(I):: NEXT I 3340 PRINT #1:KFT;",";KCR;",";KTR;",";KCO;",";KMB;",";PFT;",";PCR;",";PTR;",";PCO;",";KHCOUNT;",";PHCOUNT;",";KCCOUT;",";TURN 3350 CLOSE #1 3360 OPEN #1:"DSK1.STATFILE",INPUT 3370 FOR I=1 TO 8 :: INPUT #1:HLIST(I):: NEXT I 3380 INPUT #1:KFT,KCR,KTR,KCO,KMB,PFT,PCR,PTR,PCO,KHCOUNT,PHCOUNT,KCCOUT,TURN 3390 CLOSE #1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted April 5, 2022 Share Posted April 5, 2022 2 minutes ago, HOME AUTOMATION said: 3320 OPEN #1:"DSK1.STATFILE",OUTPUT 3330 FOR I=1 TO 8 :: PRINT #1:HLIST(I):: NEXT I 3340 PRINT #1:KFT;",";KCR;",";KTR;",";KCO;",";KMB;",";PFT;",";PCR;",";PTR;",";PCO;",";KHCOUNT;",";PHCOUNT;",";KCCOUT;",";TURN 3350 CLOSE #1 3360 OPEN #1:"DSK1.STATFILE",INPUT 3370 FOR I=1 TO 8 :: INPUT #1:HLIST(I):: NEXT I 3380 INPUT #1:KFT,KCR,KTR,KCO,KMB,PFT,PCR,PTR,PCO,KHCOUNT,PHCOUNT,KCCOUT,TURN 3390 CLOSE #1 So this creates comma-delimited text in line 3340. 0 0 0 0 0 0 0 0 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 Very clever you. 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted April 5, 2022 Share Posted April 5, 2022 It seems that this only allows for 42, digits, shared amongst the 13, variables. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 5, 2022 Author Share Posted April 5, 2022 28 minutes ago, TheBF said: So this creates comma-delimited text in line 3340. 0 0 0 0 0 0 0 0 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 Very clever you. So this would read correctly then? Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 5, 2022 Author Share Posted April 5, 2022 54 minutes ago, RXB said: Yea that is why upon inspection I determined it is a DATA FORMAT ERROR. If each line was PRINT #1:variable just like the 3330 FOR I=1 TO 8 :: PRINT #1:HLIST(I) :: NEXT I it would not error out. I figured as much... Thanks for all the input (no pun intended!) guys. Even after all these years I still get a gotcha with XB... Quote Link to comment Share on other sites More sharing options...
+TheBF Posted April 5, 2022 Share Posted April 5, 2022 Just now, Vorticon said: So this would read correctly then? To the limitations said by @HOME AUTOMATION 42 digits max. So not really practical probably for your needs. Better to split the variables into multiple lines line Rich did, or make another array for your stats and remember them by index number, writing each element into its own record. 3 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 5, 2022 Share Posted April 5, 2022 I don't have my computer in front of me to check, but here I think the problem is simple. You have specified INTERNAL but no length, so this would use the default of 80 length and so will open as IV80. Each number takes 8 bytes. 8*13=104 which is more than 80 even without separator bytes. Try OPEN #1:"DSK1.STATFILE",OUTPUT,INTERNAL,VARIABLE 127 and see what happens. 3320 OPEN #1:"DSK1.STATFILE",OUTPUT,INTERNAL 3330 FOR I=1 TO 8 :: PRINT #1:HLIST(I) :: NEXT I 3340 PRINT #1:KFT,KCR,KTR,KCO,KMB,PFT,PCR,PTR,PCO,KHCOUNT,PHCOUNT,KCCOUT,TURN 3350 CLOSE #1 2 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 5, 2022 Author Share Posted April 5, 2022 2 hours ago, senior_falcon said: I don't have my computer in front of me to check, but here I think the problem is simple. You have specified INTERNAL but no length, so this would use the default of 80 length and so will open as IV80. Each number takes 8 bytes. 8*13=104 which is more than 80 even without separator bytes. Try OPEN #1:"DSK1.STATFILE",OUTPUT,INTERNAL,VARIABLE 127 and see what happens. 3320 OPEN #1:"DSK1.STATFILE",OUTPUT,INTERNAL 3330 FOR I=1 TO 8 :: PRINT #1:HLIST(I) :: NEXT I 3340 PRINT #1:KFT,KCR,KTR,KCO,KMB,PFT,PCR,PTR,PCO,KHCOUNT,PHCOUNT,KCCOUT,TURN 3350 CLOSE #1 That worked perfectly. Thanks! Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 6, 2022 Share Posted April 6, 2022 Glad to hear that. It turns out that VARIABLE 117 is the smallest that will work with 13 numbers. 9 bytes per number *13=117. I don't think there is any disadvantage in using VARIABLE 255. Since the size is variable your two writes should require just one sector on the disk. If it was FIXED 255 then your two writes would take 2 sectors. 4 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted April 6, 2022 Share Posted April 6, 2022 I believe with variable, the biggest record size allowed is 254. Each variable record starts with a length byte. It has to fit into a sector, and there is an end of sector byte. Fixed type files don't have a per record record length, so you probably can do fixed 255. To point at the lower bound, any fixed record length greater than half a sector (128) causes you to only get one record per sector. If you do use fixed the 4A can calculate what sector the record is in which allows the random access by record number. That doesn't matter if you always load all the data. 1 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.