Interpreting READST values when reading serial files in assembly

[Stefan]

Hi,

I realized that I hadn't fully understood the status word (Kernal function READST) when reading serial files in assembly.

After some experiments, this is what I think is correct. 

• 
  OPEN ($ffc0) will succeed whether or not the file exists
  


• 
  To test if a file exists, you need to call CHRIN ($ffcf) trying to read the first byte
  


• 
  If you then call READST ($ffb7)
  
  
  
  • 
    Bit 6 (EOI) is set if the file contained only one byte (value=$40)
    
  
  
  • 
    Bit 6 (EOI) and 1 (Read timeout) are set if the file is not found (value=$42)
    
  
  
  • 
    Bit 7 is set if the drive is not present. This could also be caught by checking the carry bit after calling OPEN.
    
  
  
  
  


• 
  Conclusions:
  
  
  
  • 
    READST = $00 => CHRIN returned a valid byte, and it's not the end of the file
    
  
  
  • 
    READST = $40 => CHRIN returned a valid byte, and it's the last byte of the file
    
  
  
  • 
    READST = any other value than $00 or $40 => An error condition, the value returned by CHRIN is not valid
    
  
  
  
  

Maybe someone in the community has more information, please share if so.

I'm especially interested in whether you may trust that bit 1 in READST (Read timeout) always will be set on file not found.

[pzembrod]

Hi Stefan,

this mostly looks right to me. One point: According to the C64 Programmer's Reference Guide, OPEN should return CS and error 4 in A on file not found.

Do you have a copy of or link to that guide?

Cheers

/Philip

[Stefan]

Hi,

Yes, I got a copy of the PRG from when I was just a boy, printed in 1987.

It doesn't say where error codes not reported in READST are stored, but you would assume the A register.

I tried running a program three times calling OPEN on a file that doesn't exist. The return values are not consistent, example output:

• 
  1st invokation: A=$a0, X=$00, Y=$0b, carry=0, readst=0
  


• 
  2nd invokation: A=$e0, X=$00, Y=$0b, carry=0, readst=0
  


• 
  3rd invokation: A=$e0, X=$00, Y=$0b, carry=0, readst=0
  

Calling the same code when the file exists:

• 
  1st invokation: A=$00, X=$00, Y=$0b, carry=0, readst=0
  


• 
  2nd and 3rd invokation returned the same values
  

A != 0 could indicate an error, but neither $a0 nor $e0 are listed as valid error codes. It could of coarse be a bug in the X16 Kernal. I haven't done any testing on the C64.

[Greg King]

Tape files are opened by Kernal.  Therefore, OPEN can know when they can't be found.  But, Kernal asks DOS to open disk files.  Therefore, OPEN can't know about them.

With READST, bits 6 and 1 aren't connected to each other.  It's a coincidence if bit 6 happens to be set when bit 1 is set.  Always check bit 1 by itself.  That bit is reliable.  LOAD uses it to know when a file can't be loaded.

The same is true for the other direction.  If a file can't be created, or opened for appending, then an attempt to write into it will set bit 0 (write timeout).

[Stefan]

Thank you for that @Greg King

The C64 PRG and other books I've found online are not very clear on this matter.