Re[2]: [cc65] Commodore file i/o (was: and another....)

Date view Thread view Subject view

From: groepaz (
Date: 2002-10-08 19:40:39

Hello Ullrich,

Tuesday, October 08, 2002, 6:58:12 PM, you wrote:

UvB> On Tue, Oct 08, 2002 at 06:43:31PM +0200, groepaz wrote:
>> ??? please explain... it implements open/close/read/write basically,
>> and also a ton of (dos/borland style) highlevel routines.

UvB> I cannot find anything named open, close, read or write in your sources.

fs_open/fs_close/fs_read/fs_write should be there (the prefix so i
could test some stuff easier)

int fs_open(const char *devname,int flag);   // open file (returns file id)
int fs_read(int fd, char *buf, int n);       // read n bytes to buf from file fd
int fs_write(int fd, char *buf,int n);       // write n bytes from buf to file fd
int fs_close(int fd);

like i said, the current version DOES work when linked against your
highlevel functions... it also implements init/deinit in module
constructor/destructor and does some more things so it can be used
without needing any modifications in the code you wanna compile. (the
only thing missing atm is some sort of "automount" at startup, atm
drive 8 is assumed as the only available drive)

UvB> However, there are some other functions like fs_printf().
UvB> And, assuming the
UvB> POSIX low level functions were available, these would not be needed, because
UvB> fprintf would work in this case.

yes true, there are some functions which are unnecessary.... the whole
thing was developed parallel to some gameboy stuff i was doing and i
didnt have those functions there (well not in a form i could use
atleast). actually i was in the process of removing those occurrences
when i had to stop working on the stuff.

>> oh, and maybe that old version is missing certain bits aswell, i dont
>> remember....been a while since i uploaded that one ,)
UvB> This may be the case, I don't know:-)

maybe is ;=)

UvB> [loadable modules]
>> does that mean dropping in open/read/close would do the trick?

UvB> All the stdio stuff is based on open/read/write/close. This means that having
UvB> these routines, fopen, fprintf, fread, fwrite and all others will
UvB> automagically start working. The later routines are not system dependent,
UvB> which is very nice in my eyes, because it minimizes the amount of platform
UvB> dependent code. And, it allows to port programs that use the POSIX interface
UvB> instead of the C file routines.

yesyes ofcoz :) (btw to make that complete, the only lowlevel
functions missing here are lseek(),opendir(),readdir(),closedir() here
right?..(not sure about dir-stuff...i am used to M$dos stuff ;=P) or
is it true that opendir/readdir/closedir is the posix-interface and
needs some other underlaying layer?)

UvB> The current implementation of tgi_load() (the function that loads graphics
UvB> drivers into memory) calls cbm_load, but this is a hack, because cbm_load
UvB> is non standard and works only on CBMs. I will change that to use fopen, fread
UvB> and fclose, so it is usable with any platform that has file i/o. you do this first...and in two weeks or sth when i have moved
all stuff around i'll concentrate on getting my open/read/close
working with that :=) (write aint THAT important atm).... then next thing
is still a suitable solution for seeking ;/ i fear that cant be done
in a generic way (except constantly rereading the file from start when
scanning backwards)...still working out some sort of caching. (any
testprograms around that can show if seeking works as intended?)

Best regards,

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.

Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2002-10-08 19:41:03 CEST