Commander X16

The first section just creates a 255 byte sequential file that we can use for testing.

Starting at line 200, the program opens a sequential file named "TEST.TXT"

210 opens the command channel (secondary address 15. I use 15 as the channel number, just to keep things consistent.)

220 just shows the read pointer is at the beginning of the file

240 actually seeks to index 20 in the file (since 0 is the first byte, this will read "21")

270-280: Remember to close your channels! 

 

This is excellent. So the method is:

240 PRINT#15, "P"+CHR$(2)+CHR$(byte)+CHR$(block)+CHR$(offset16)+CHR$(offset24);

Where

• "byte" is the byte offset.
  "block" is a page or block offset (256 bytes).
  "offset16" is the block of blocks offset (64k bytes).
  "offset24" is the block of 4k blocks offset (16m bytes).

Does this mean a program could potentially seek up to byte number 4,294,967,296?

rje wrote: ↑Tue Feb 28, 2023 9:50 pm Does this mean a program could potentially seek up to byte number 4,294,967,296?

It's an unsigned 32-bit number. So yes, assuming the file system permits it.

I am not positive, but I don't remember fseek() working in cc65. I'll have to revisit that.

rje wrote: ↑Wed Mar 01, 2023 2:48 pm I am not positive, but I don't remember fseek() working in cc65. I'll have to revisit that.

The problem Matt had was due to his seek function trying to treat the data like string data, where it actually needs to be treated as a byte array. (Strings are null terminated, so the function saw the last couple of zero bytes as a terminator, rather than part of the data.)

What I can't remember is if we solved that here or on the Discord; you might search through here for posts by SlithyMatt regarding file seeking and C.