Commander X16

This also seems to work fine:

void readFile2(const char *filename)
{
    char buf[200];
    FILE *fp = fopen( filename, "r" );
    if (fp)
    {
        fgets(buf, 100, fp);
        fclose(fp);
        printf("data: %s\n", buf);
    }
}

52 minutes ago, rje said:

This also seems to work fine:

        cprintf("data: %s\r\n", buf);

 

You should use

printf();

in an example about stdio code.

2 hours ago, Greg King said:

You should use

printf();

in an example about stdio code.

Updated.

It is messy, isn't it?  CC65 pushes conio to us, and yet stdio is... well, stdio.  The reality is that my code is always a work in progress.

On 8/11/2021 at 9:43 AM, rje said:

@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've found the answer: no.  Reading $ means reading the "directory file" built by LOAD.  If that thing doesn't include timestamp, then this one won't ever see it.

29 minutes ago, rje said:

Updated.



It is messy, isn't it?  CC65 pushes conio to us, and yet stdio is... well, stdio.  The reality is that my code is always a work in progress.

It really depends on what you're trying to do. cprintf is not part of standard C, but it is offered by many platforms. And it doesn't have the potential overhead of processing data as a file stream, so it can be (not that it is guaranteed to be) faster when you *know* you want to write to the screen and not whatever is pretending to be the standard output stream.

Not to mention (although you hinted at it) that avoiding printf can shrink the binary size.

7 minutes ago, rje said:

Not to mention (although you hinted at it) that avoiding printf can shrink the binary size.

True, though I suspect avoiding printf by using cprintf probably doesn't help the binary size much. I would think that they both use the same formatting code underneath and the only real difference is whether the screen is targeted or a file stream pointer.

If they do not share the exact same formatting code, then that only makes things worse, especially on memory constrained 8 bit platforms!

It's actually a thing.  I checked out the memory dump files created by cc65 and I could see how many bytes are used by the presence of each function... and while a function might be only a few hundred bytes... well, it can add up.

/Users/rje/git/cc65/lib/cx16.lib(_printf.o):
    CODE              Offs=003D6C  Size=0003A5  Align=00001  Fill=0000
    BSS               Offs=000359  Size=00002B  Align=00001  Fill=0000
    DATA              Offs=0000FA  Size=000003  Align=00001  Fill=0000

933 bytes...

 

Meanwhile, cprintf is different...

/Users/rje/git/cc65/lib/cx16.lib(cprintf.o):
    CODE              Offs=004299  Size=00002A  Align=00001  Fill=0000
    BSS               Offs=000384  Size=000001  Align=00001  Fill=0000

Tiny.  As you suggest, perhaps it has its string formatter in a utility function... but printf has some extra oomph.

 

In short, if I replace the printf's with cprintf, then I get a 900 byte reduction.

"(_printf.o)" is the common formatter function that everything uses.

"(printf.o)" has the printf() function.  But, it calls "(vfprintf.o)", which calls "(fwrite.o)", which calls "(write.o)".

I was wondering what the difference was. I know that in cc65, cprintf() fails to scroll the screen and interprets \n as CR whereas printf() scrolls and interprets \n as CRLF. cprintf could probably stand to be fixed in its cx16 implementation....