Commander X16

I think I misunderstood the DOS commands issued by the FS calls, I thought that by "reading the status" you meant calling READST but it was just calling OPEN with a zero-length file ! ?

I'm not fully aware of all the features of the C64 / X16, so I'm still learning things everyday ^^

Sorry about the past answers >_< was dumb

OK.

READST just tells you that you have reached end of file or that there is some error, but not which one.

By opening another file with secondary address 15 you may read the disk status text stream. The text stream is read with the same functions as a normal text file(call CHKIN, and then call CHRIN and READST in a loop until you get a non-zero status value).

"00, OK, 00,00" is returned if there was no error.

"62, FILE NOT FOUND,00,00" is returned  on, you guessed it, file not found.

There are, of coarse, many other possible disk errors. Read the complete list in the 1541 user manual page 42 found here: http://www.commodore.ca/wp-content/uploads/2018/11/commodore_vic_1541_floppy_drive_users_manual.pdf

This is not entirely intuitive, being a Commodore legacy, when disk drives where almost computers of their own that you communicated with over the serial bus.

 

Got this code to check if an error occurred, it's just for testing what do you think of it ?

Looks promising. You should probably use READST to check for errors/EOI instead of return value 0 from CHRIN.

What happens when you run this?

Right now it's returning carry set (debugged the output and it made sense) but still no luck on the blinking, i'll try with the READST. I tried to check for zeroes but I need to CMP #$30 instead. (petscii zeroes)

18 minutes ago, VincentF said:

Got this code to check if an error occurred, it's just for testing.  What do you think of it?

The "00, ok" message is text, not binary numbers.  That is, your code would read $30, $30.

2 minutes ago, VincentF said:

Right now it's returning carry set (debugged the output and it made sense) but still no luck on the blinking, i'll try with the READST. I tried to check for zeroes but I need to CMP #$30 instead. (petscii zeroes)

Perhaps, you need to read the entire message.  Do a loop.  Read until it sees a $0D (carriage return).

This seems to work. Also puts out the blinking light.

15 minutes ago, Greg King said:

Perhaps, you need to read the entire message.  Do a loop.  Read until it sees a $0D (carriage return).

It was that. Now that I read the entire message the blinking is finally gone ! ?

Thank you so much @Greg King and @Stefan for helping me figuring out the issue ! I learned a lot on the filesystem process thanks to you ?

It would be nice to document this kind of stuff somewhere for people like me ? It's sometimes hard to find the right documentation for the right problem

Does Vixx really need to know why it can't read the high score file?  Maybe, it's enough that your program knows when it can, and when it can't.  If that's the case, then "check_disk_error:" actually wouldn't need to compare the status numbers.  It merely would need to do something that stops people from yelling, "Hey buddy, you left your turn signal on!" ?

• 
  Your program would OPEN the file.  If OPEN returned with the Carry flag set, then the device doesn't exist (someone forgot to attach a card to the emulator).  If the flag is unset, then the file must be closed, at some later time -- no matter what else happenned.
  


• 
  Vixx would try to read the file.  Then, if READST returned a non-zero value (the particular bits wouldn't matter), Vixx would "flush" the device's error channel.
  


• 
  If Vixx wanted to add a new high score to the file, then it would know that the score is the first one.  Vixx would create the file.
  


• 
  But, if Vixx wanted to show a high scores screen, then it would show an empty screen (nobody has scored, yet).