File question

[+Vorticon]

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

 

[Willsy]

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.

[Willsy]

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.

[+Lee Stewart]

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

[HOME AUTOMATION]

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.

[+Vorticon]

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...

[+jedimatt42]

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.

 

[+Lee Stewart]

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

[Willsy]

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.

[Willsy]

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!

[HOME AUTOMATION]

     

 

 

 

               TI-99/4A User's Reference Guide  P. II-133

Edited April 5, 2022 by HOME AUTOMATION
better pic.

[+Lee Stewart]

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

[RXB]

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.

[+TheBF]

 

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.

 

 

[RXB]

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.

[HOME AUTOMATION]

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

[+TheBF]

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.

[HOME AUTOMATION]

It seems that this only allows for 42, digits, shared amongst the 13, variables. 

[+Vorticon]

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? 

[+Vorticon]

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...

[+TheBF]

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.

 

 

[senior_falcon]

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

 

[+Vorticon]

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!

[senior_falcon]

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.

[+jedimatt42]

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.