File pointers in CC65!

[Greg King]

9 hours ago, ZeroByte said:

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....

Their philosophies are different.  stdio is stream-oriented, while conio is screen-oriented.

A stdio program is expected just to print and print and print and...  It cares little about the height of a screen.

A conio program is expected to stay on a single screen.  It reuses that screen's real estate.  It overwrites old text with new text.

That's why conio has ...xy() positioning functions.  It's why there are cclear... functions.  And, it's why carriage return and line feed are separate characters.  We can use carriage return to type and retype on the same line.

[Scott Robison]

A lot of it depends on the platform you're targeting. stdio.h is one of the language mandated standard headers, so it is well defined what it should do. conio.h is a "quasi standard". Many platforms have it, but it isn't mandated by the bodies that say "this is what you must have in a C environment" so it will vary a lot more based on the platform. It's been a while since I used conio on DOS, but i seem to recall it *did* scroll the screen when it wrapped around the bottom line. But because it isn't standardized, there is no requirement that be the case.

Even the processing of CR & LF is not mandated by the standard. The systems based on posix will treat LF as and end of line character that both advances to the next line (what LF is defined to do in ASCII) and to the beginning of the line (what CR is defined to do). This provides more "flexibility" on DOS & Windows platforms (though maybe not the most useful depending on your point of view) but keeps lines "shorter" in posix because you only need a single character to mark the end of a line.

Once you move outside of the standard libraries, there is no requirement that they behave the same way.

[Scott Robison]

20 hours ago, rje said:

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.

Yes, it can. My (perhaps poorly phrased) point was that the difference is not as big as you might think it would be otherwise.

If you write a program that only uses printf, and one that only uses cprintf, and another that uses both, you'd see that the incremental size for both includes overlap when functionality is shared (like a common formatting function that both can use).

[rje]

I'd like to fopen() files in the native filesystem, i.e. not the mounted SD image, while I'm just writing code and testing things out.

I'm not sure that can be done, though.  Except by using the KERNAL functions I suppose.  Anyone?

 

[TomXP411]

On 9/30/2021 at 9:25 AM, rje said:

I'd like to fopen() files in the native filesystem, i.e. not the mounted SD image, while I'm just writing code and testing things out.



I'm not sure that can be done, though.  Except by using the KERNAL functions I suppose.  Anyone?

You mean the "host" file system. And I don't think that's possible. IIRC, the emulator used a hack to load files from the host file system in early versions of the emulator. I could be wrong on this, but my take was that rather than open a file and deliver the bytes to the KERNAL through an I/O port, the emulator just shoves data directly into guest RAM. 

 

 

[rje]

That makes sense to me.  No worries, I have a work-around for my current project... I'll load a file into banked RAM and then operate on that data.  Maybe create a fake stream function, or not.