File I/O

[+dhe]

 

After struggling with Pascal and "virtual" Catalog file, I decided to take a step back, and review the basic's of File I/O in BASIC.

For a subject that should be the bread and butter of computer-dom, I really couldn't find a lot of good examples.

 

The best I've found so far:

  pha2603 (Users Reference Guide)  - decent intro to file i/o commands

    php1240 (Disk Controller Manual) - examples including the dread catalog routine.

Also, presents a very basic CRUD (Create, Read, Update and Delete) example...

    Mastering the ti-99, Peter Brooks - good explanation of actual use, unfortunately cassette environment only, but there are good tricks about dealing with waiting for play to be hit by the user.

 

   Surprisingly - Grillo's File and Data Management, contains very little on how File I/O actually works! ?

 

 So some of the tips and tricks, I've discovered along the way.

   If you declare your record as say var 80, and you try to write 100 characters, most of the time, the overflow ends up as a new record (line).

   Different devices have different record lengths, cassette tapes (I think 192 is it's max) and thermal printer (32 characters).

   Different devices have different attributes supported - can't read from a thermal printer and cassettes don't do random (relative) records.

 

  The biggest learning experience I had was how differently data is written vs how it is read back.

  

Example from basic….

A$ = “Cat”

B$ = “Dog”

 

Open {blah blah}

 

Case #1

Print #1: A$,B$

Datafile

CAT  {spaces} Dog

 

Case #2

Print #1: A$:B$

Datafile

CAT

DOG

 

Ramifications: When reading back the file,

INPUT #1:A$

 

Case #1

A$ = “CAT {spaces} DOG”

 

Case #2

A$ = Cat

 

This would have taken much longer to figure out, but when debugging File I/O - using classic 99's debugger along with TI99Dir to show you the output file, really helps speed you along the way.

 

 

 

[+TheBF]

If I understand your example...

This looks like an small inconsistency in BASIC.

 

When printing to a file the comma means put the next data item in the same record.

The colon means add a "newline" after A$.

 

Since you opened the file as a display variable 80 (TI 99 text file) a newline means B$ is a new record.(ie: on a new line)

But when printing to the file, comma means A$ and B$ are on the same 80 character line.

 

The inconsistency in my opinion is when printing to the screen comma means print at column 16 and semi-colon means print sequentially.  In my opinion these should/could have been reversed for consistency between print to screen and the print to file meaning of the comma.

 

[+dhe]

Thanks, it took me a few minutes to grok what you meant, but yes I agree with you.

tp99 seems to handle this well, as you can (pseudo code).

  Field1[4]

  Field2[4]

    that allows you to have a single record

12345678
cat mice

After input you would have:

  Field1 := ' cat'

  Field2 := 'mice'

 

In retrospect, I should have expected some minor turbulents, as I am used to the concept of a 'field separator' - with <space> or <,> being amongst the most common. Another way of saying this would be: 'On read, the the space character does not act as a field separator.'

 

 

[+dhe]

Additional Enlightenment came from PHM 3026 - extended basic.

 

Print Function

  ; , : - control spacing when open in DISPLAY mode

  ; - next element to be placed immediately adjacent to the previous element

  , -  next element of print-list to be put in the next print field

  : - next element to be put on the next line or record

 

  , ; - control spacing in INTERNAL mode

   place the elements in print-list adjacent to each other

 

The number of print fields depends upon the record length of the device.

Each print field is 14 character long.

[+dhe]

also see:

 

[apersson850]

On 7/10/2021 at 1:55 AM, dhe said:

After struggling with Pascal and "virtual" Catalog file...

If you by Pascal refers to the UCSD p-system, then that's a totally different animal. It doesn't use the native file system at all. It just does disk access by sectors, then implement the p-system's traditional file handling on top of that. It sets its own rules completely.

This is why storage devices that don't have the concept of disk sectors don't work with the p-system. A RAMdisk can work, but the access to the disk is not the same as the standard system either. The p-system has its own implementation of DSRLNK, so you have to be careful not to make assumptions about how the standard DSRLNK behaves, or your device driver will not work correctly with the p-system.