File pointers in CC65!

[Scott Robison]

Note that the way FAT32 works is: Every file has an 8.3 entry. If it has a long file name, it also has additional entries per 13 character part.

For example, a file name x16emu.exe has a file named X16EMU.EXE (because traditional file names are all uppercase). Then it will have a single long name entry because x16emu.exe is under the 13 character limit. So if you are planning on say 16 character names, you'll use 3 entries: 1 for the short, 2 for the long.

[rje]

3 hours ago, Scott Robison said:

Note that the way FAT32 works is: Every file has an 8.3 entry. If it has a long file name, it also has additional entries per 13 character part.

Ah OK.  Oh.... sure I remember seeing this back when we had DOS windows.  It would list the 8.3 name, complete with funny characters.  Windows would show the longname.  

 

[ZeroByte]

@rje - be sure to make a howtos post with an example once you get a "hello world" program for getting a directory listing and handling it. I'll bring the popcorn. ?

 

[rje]

Oh --- yeah I'll do that.

In the meantime, I can create files with content.  I don't know how to read them (yet).

NOTE: of course, you can't even COMPILE source with fgets(buf, 251, fp).  fgets won't accept anything above 250 bytes.  The docs do mention this.

 

[rje]

In the meantime, I decided just to try a local directory read.

DIR* dp = opendir( "test1");  

dp is NULL.  I might need to phrase the directory differently... like ".//test" or something.  I seem to remember I had a thread here on 16DOS...

 

[rje]

OK, use cbm_opendir, cbm_readdir, and cbm_closedir.  I've created a How-To topic for this.

Now I still have to READ a file.  Maybe there's a function in cbm.h.

 

[Greg King]

We use https://github.com/cc65/cc65/blob/master/targettest/dir-test.c to test our standard directory functions.

(Ignore the comment at the top of the file!  It describes the CBM library implementation, not the test program.)

[rje]

Yeah ok, here's comments from cbm.h.

unsigned char __fastcall__ cbm_open (unsigned char lfn, unsigned char device,  unsigned char sec_addr, const char* name);

/* Opens a file. Works just like the BASIC command.

** Returns 0 if openning was successful, otherwise an error-code (see table)

*/

void __fastcall__ cbm_close (unsigned char lfn);

/* Closes a file */

int __fastcall__ cbm_read (unsigned char lfn, void* buffer, unsigned int size);

/* Reads up to "size" bytes from a file into "buffer".

** Returns the number of actually-read bytes, 0 if there are no bytes left.

** -1 in case of an error; then, _oserror contains an error-code (see table

** above).  (Remember:  0 means end-of-file; -1 means error.)

*/

int __fastcall__ cbm_write (unsigned char lfn, const void* buffer, unsigned int size);

/* Writes up to "size" bytes from "buffer" to a file.

** Returns the number of actually-written bytes, or -1 in case of an error;

** _oserror contains an error-code, then (see above table).

*/

[rje]

The above commands appear to work.  I've tried them out with success, like so:

void readFile(const char *filename)
{
    char s[200];
    unsigned char lfn = 1;
    unsigned char dev = 8;
    unsigned char sec_addr = 0;
    unsigned char res = cbm_open(lfn, dev, sec_addr, filename);

    // read the first 200 bytes of the file.
    if (res == 0)
    {
        cbm_read(lfn, s, 200);
        cbm_close(lfn);
    }
    
    printf("data: %s\r\n", s);
}
 
	

[rje]

11 hours ago, Greg King said:

We use https://github.com/cc65/cc65/blob/master/targettest/dir-test.c to test our standard directory functions.



(Ignore the comment at the top of the file!  It describes the CBM library implementation, not the test program.)

@Greg King, would it be wrong for me to add timestamp fields to cbm_readdir?  I know most CBM devices don't read or write timestamp, but the directory entries have space for it, and it's used in the later drives, so....

...and I didn't see tests for cbm_opendir, _readdir, etc.  Where would I put "unit" tests for these?

And how do I make and submit document MRs?  

OK I'll start by cloning the repo and looking around.  Should I fork it?