Re: [cc65] Common macros for dirent.d_type

On 2012-07-06, at 11:45, Oliver Schmidt wrote:

> Hi,
> 
> I'd like to learn some more...

Out of my rusty brain cells...

> I think I understood that LOAD is the only Kernal call doing a "mass
> transfer" of data from disk - in contrast to the "other" single byte
> calls - correct?

Yes. You can CHRIN bytes one by one from a previously OPEN file or you can LOAD the whole file at once. The latter is of course faster if you want always the whole content transferred.

> And according to the discussion here LOAD is only applicable to PRG
> files - correct?

By default yes. If you try to load a SEQ file, you get an error.
Still you can override the default and ask explicitly to LOAD a different type of file. Except REL, that is.

> I believe that "usually" a PRG file starts with A two btye load addr.

LOAD treats the first two bytes as load address. It doesn't care much about what it is neither what follows it. If the first two bytes of the file to be LOADed are in fact data bytes, those will be either skipped or used as load address and possibly overwrite some vital memory areas. Whether they are simply skipped or used as load address depends on the parameters passed when setting up LOAD. SETLFS is the function. In any of those cases the program loading the file does not receive the bytes in question.

> I seem to remember that we talked about this here already. I sort of
> remember that those first two bytes can't be read by LOAD so one would
> need to "read" them in the "usual" way and then LOAD the rest.

Yes, but...

> Or one
> would need to add two dummy bytes to the file in order to be able to
> LOAD the actual content.

... in practice the latter approach was used most of the time as it was a good trade-off of two bytes of data in place of several needed to handle the case differently. And again - opposite to Groepaz's experience, I both saw and used a lot of SEQ files.

> As far as I understand all this has to be
> taken care of by the programmer - the cc65 C library doesn't do so.

I believe so as I see no reason for it to do at least in the POSIX part. CBM specific functions can do it differently but still should take into account what's the trade off.

> So it seems to me that in order to actually benefit from PRG files so
> much has to be done manually that setting the cc65 filetype to 'p'
> seems only a very minor additional step.

I believe that whenever one wants to use ISO/POSIX calls fopen() fwrite() and friends it translates well into OPEN11,8,1,"FILE,S,W", PRINT#1,"MY DATA". While I see the point of keeping it the same as what BASIC does by default, I believe that disadvantages of this default outweigh the gains. YMMV of course.

> But if a programmer doesn't want to use LOAD but probably even stay
> with the POSIX stuff then he won't benefit from PRG and thus SEQ seems
> the better default - keeping CBM-specific stuff from the source code.

That's what I believe too. SEQ in the directory listing tells the user immediately: "this is data file, don't try to LOAD it"

> Maybe I'm missing an important point but from the arguments I
> understand so far the decision seem easy to me.

The only point for me against this decision is that when you OPEN a file for writing from BASIC without specifying that it has to be a SEQ file, it will create PRG by default. A valid point but I would still keep it as SEQ. When people needed sequential data rather than a block that is to be LOADed in one shot, they often used SEQ files overriding this (wrong IMHO) default.

Therefore IMHO the best approach would be (don't know if it is feasible):

- keep SEQ as default whenever ISO/POSIX functions are used to create the file
- keep PRG as default whenever cbm_k_ functions are used

This would serve both worlds best. One using POSIX stuff gets what he expects - a SEQ file, one using CBM specific stuff gets what he expects - the same as what CBM specific BASIC would give him.

Regards,

-- 
SD!----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.