It is currently Thu Dec 14, 2017 8:52 pm

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Contiki 2.1 : File I/O
PostPosted: Mon Jun 16, 2008 1:45 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 77
Edit: This topic was split from viewtopic.php?f=5&t=311&start=75


Hi lodger,

First of all I'd like to mention that I'm supposed to get email notification on answers in this thread but I didn't receive one for your post. I rather saw it yesterday my chance :?

So if you (or any other Contiki programmer) has a specific question and I seem to igonore postings in this board feel free to drop me an email: ol.sc at web.de
lodger wrote:
Well, the cfs_read command works, but it seems like you can't write data to a file (on the c64 platform, native and with VICE) using cfs_write. I've attached my example code,
Thannks for the example code. This makes analysis obviosly much simpler :)

I just fixed this in the CVS head revision. In case you're interested in the background:

Up to now the CFS_WRITE flag was translated into the POSIX flags O_CREAT | O_TRUNC | O_RDWR. This was done for precaution and to potentially increase comptibility as most systems implicate read access rights for write access rights. However now I learned that the cc65 POSIX file I/O library for CBM treats O_RDWR as an error in general - most likely due to limitations of the CBM DOS, but as you know my CBM knowledge is extremly limited...

Now the CFS_WRITE flag translates straight to O_CREAT | O_TRUNC | O_WRONLY without "trying to be smart".
lodger wrote:
feel free to try it. It just won't work.
Was there a part of the conversion in which you told me about this "can read but can't write" issue and I said "Bullshit !" that I don't remember anymore ? :wink:

Best, Oliver


Top
 Profile  
Reply with quote  
 Post subject: Re: Contiki 2.1 released
PostPosted: Sat Jun 21, 2008 8:38 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 80
Location: Duesseldorf, Germany
Oliver wrote:
Hi lodger,

First of all I'd like to mention that I'm supposed to get email notification on answers in this thread but I didn't receive one for your post. I rather saw it yesterday my chance :?

So if you (or any other Contiki programmer) has a specific question and I seem to igonore postings in this board feel free to drop me an email: ol.sc at web.de
lodger wrote:
Well, the cfs_read command works, but it seems like you can't write data to a file (on the c64 platform, native and with VICE) using cfs_write. I've attached my example code,
Thannks for the example code. This makes analysis obviosly much simpler :)


Pleased to help you on this. Since you've got a .de mail address, I'm pretty sure I'll get back to you directly via mail next time using our native language, which is german I persume? ;)

Oliver wrote:
Now the CFS_WRITE flag translates straight to O_CREAT | O_TRUNC | O_WRONLY without "trying to be smart".
lodger wrote:
feel free to try it. It just won't work.
Was there a part of the conversion in which you told me about this "can read but can't write" issue and I said "Bullshit !" that I don't remember anymore ? :wink:


As I said before: english is not my native language. So sometimes I pick the wrong words / phrases. What I really wanted to say was: feel free to try it out and hopefully you'll agree with me. Sorry for sounding so offending! :oops:

Oliver wrote:
I just fixed this in the CVS head revision. In case you're interested in the background:

Up to now the CFS_WRITE flag was translated into the POSIX flags O_CREAT | O_TRUNC | O_RDWR. This was done for precaution and to potentially increase comptibility as most systems implicate read access rights for write access rights. However now I learned that the cc65 POSIX file I/O library for CBM treats O_RDWR as an error in general - most likely due to limitations of the CBM DOS, but as you know my CBM knowledge is extremly limited...


Thank you, Oliver - that's very kind of you :) !

Just to let you know: I've been playing with the apps/shell and apps/telnetd code, getting to know Contiki 2.x a little better. I've implemented a small "login" routine to the shell, so the C64 checks a plain text file on the 1541 drive containing a username and password before popping into the shell. But it's simple, e.g. no encryption or blanked out passwords during login. Also, I've added two new processes / commands to the shell to write and read a text string to/from floppy disk. The "authentication" stuff uses <stdio.h> for reading the user/password file. However, the two new shell commands I've implemented use <cbm.h> for doing disk I/O as <stdio.h> based code (fopen, fscanf etc.) won't work within the PROCESS_BEGIN / PROCESS_END blocks. If you run it, the floppy disk drive starts to spin and the LED lights up, but then it just keeps spinning useless. You may even open the drive and take out the disk and the drive doesn't care. <cbm.h> based code (using cbm_open/cbm_close and cbm_read/cbm_write) works within PROCESS blocks, but cbm_open always returns 0 (zero) as a result, which is a bug within the cc65 compiler code. But everyone with a c64 or VICE can make proof of this.

As far as I know, unlike the Apple II disk controller(s), CBM hardware seems to be incapable of performing fseek(), fset() and ftell() with cc65. But I'm thankful for anyone explaining the correct reasons / details for these limitations.

So I'm very glad that I can now use Contiki CFS code. Be sure that I'm very thankful for any help you provide. Contiki is there and people like me are hell-bent to dig into this. Be sure, that I'll keep on digging!! ;)

_________________
LOAD ":*",8,1
READY.
RUN


Top
 Profile  
Reply with quote  
 Post subject: Re: Contiki 2.1 released
PostPosted: Sun Jun 22, 2008 9:55 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 77
lodger wrote:
Since you've got a .de mail address, I'm pretty sure I'll get back to you directly via mail next time using our native language, which is german I persume? ;)

Your presumption is correct ;)

lodger wrote:
Sorry for sounding so offending! :oops:

No offense meant, no offense taken :)

lodger wrote:
The "authentication" stuff uses <stdio.h> for reading the user/password file. However, the two new shell commands I've implemented use <cbm.h> for doing disk I/O as <stdio.h> based code (fopen, fscanf etc.) won't work within the PROCESS_BEGIN / PROCESS_END blocks.

I've read several times in the cc65 mailing list, that the POSIX I/O funtions (and therefore the stdio functions which use the POSIX I/O functions) and CBM I/O functions should never be mixed.

Apart from that Contiki prorams should always use the Contiki File System (CFS) functions for consistency reasons if there's no reason to do otherwise.

lodger wrote:
<cbm.h> based code (using cbm_open/cbm_close and cbm_read/cbm_write) works within PROCESS blocks, but cbm_open always returns 0 (zero) as a result, which is a bug within the cc65 compiler code.

Maybe you can - again - provide a small simple example on what you want to archive ...

lodger wrote:
As far as I know, unlike the Apple II disk controller(s), CBM hardware seems to be incapable of performing fseek(), fset() and ftell() with cc65. But I'm thankful for anyone explaining the correct reasons / details for these limitations.

Again, I'm the opposite of a guru on this topic but my understanding is that PRG files are only capable of sequential read or write access while REL files are capable of random access. But cc65 only deals with PRG files - for reasons I don't know.

Best, Oliver


Top
 Profile  
Reply with quote  
 Post subject: Re: Contiki 2.1 released
PostPosted: Tue Jun 24, 2008 3:48 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 80
Location: Duesseldorf, Germany
Oliver wrote:
I've read several times in the cc65 mailing list, that the POSIX I/O funtions (and therefore the stdio functions which use the POSIX I/O functions) and CBM I/O functions should never be mixed.


Oh, I didn't know that. Thanks for the info! :)

Oliver wrote:
Apart from that Contiki prorams should always use the Contiki File System (CFS) functions for consistency reasons if there's no reason to do otherwise.

lodger wrote:
<cbm.h> based code (using cbm_open/cbm_close and cbm_read/cbm_write) works within PROCESS blocks, but cbm_open always returns 0 (zero) as a result, which is a bug within the cc65 compiler code.

Maybe you can - again - provide a small simple example on what you want to archive ...


No Problem, I've attached my testfile.c program to this posting. It tries to cbm_open a file that should not and does not exist on disk (all other tests in the main routine are commented out). The cbm_open command will always return 0 where it should return an errorcode != 0 - this is a non Contiki related problem. Zero should only be returned if the cbm_open command was successful.


Attachments:
File comment: filetest.c for cc65 and c64 targets. feel free to use and modify to your needs.
filetest.c [2.9 KiB]
Downloaded 510 times

_________________
LOAD ":*",8,1
READY.
RUN
Top
 Profile  
Reply with quote  
 Post subject: Re: Contiki 2.1 released
PostPosted: Tue Jun 24, 2008 11:09 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 77
lodger wrote:
No Problem, I've attached my testfile.c program to this posting. It tries to cbm_open a file that should not and does not exist on disk (all other tests in the main routine are commented out).

Sorry for not being more precise :oops: but I was asking for a test program, I was thinking about one using CFS and/or POSIX I/O functions, because the CBM functions
    - are not supposed to work when mixed with the other functions (which already used for reading the config file and loading the driver)
    - are something that I don't understand and therefore can't test

Again sorry, Oliver


Top
 Profile  
Reply with quote  
 Post subject: Re: Contiki 2.1 released
PostPosted: Fri Jun 27, 2008 10:51 am 
Offline
Site Admin

Joined: Wed Jan 11, 2006 12:22 pm
Posts: 860
lodger wrote:
CBM hardware seems to be incapable of performing fseek(), fset() and ftell() with cc65.


Since I've seen this floating around...

Only to clarify: CBM hardware is incapable of fseek(), fset() and ftell(). Period. :D

The only way to do random access is by using REL files (as Oliver already stated).



May I suggest we fork this thread off to a new topic under "Storage" ?

Edit: This thread has now been split into a new topic.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 27, 2008 2:44 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 80
Location: Duesseldorf, Germany
RaveGuru wrote:
Only to clarify: CBM hardware is incapable of fseek(), fset() and ftell(). Period. :D

The only way to do random access is by using REL files (as Oliver already stated).


And since cc65 also doesn't support REL files, one should stick to CFS for file accesss, which now seems to work. Once again "thank you", Oliver, for fixing the CFS code.

_________________
LOAD ":*",8,1
READY.
RUN


Top
 Profile  
Reply with quote  
 Post subject: Re: Contiki 2.1 released
PostPosted: Fri Jun 27, 2008 4:21 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 77
RaveGuru wrote:
Edit: This thread has now been split into a new topic.

Thanks :)
RaveGuru wrote:
Only to clarify: CBM hardware is incapable of fseek(), fset() and ftell(). Period. :D

The only way to do random access is by using REL files (as Oliver already stated).

Hm, if the cc65 C-Library would implement (), fset() and ftell() with REL files then it would work, wouldn't it? So I don't understand why you say the CBM hardware is incapable of doing so. :roll:

Is there an "obvious" reason for not using REL files?

Best, Oliver


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 28, 2008 4:40 pm 
Offline
Site Admin

Joined: Wed Jan 11, 2006 12:22 pm
Posts: 860
I'm not sure since I've never worked with REL files, but I think that REL files are more like a structured array, i.e. when you create the REL file you declare the records and their lengths. When accessing the file you tell what record you want to read or write. Hence an application must know the structure of the file. I guess a REL file with 1 byte records could serve more or less like a very slow random access binary file :)


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 29, 2008 1:34 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 80
Location: Duesseldorf, Germany
Oliver wrote:
Hm, if the cc65 C-Library would implement (), fset() and ftell() with REL files then it would work, wouldn't it? So I don't understand why you say the CBM hardware is incapable of doing so. :roll:


Well, I rely on this posting on the cc65 mailing list -> http://www.cc65.org/mailarchive/2003-11/3779.html

Oliver wrote:
Is there an "obvious" reason for not using REL files?

No, not if it works. Maybe I just misunderstand something here - honestly, I don't know how to implement that kind of file type. But I'm still new to this so maybe I just get something wrong ...

_________________
LOAD ":*",8,1
READY.
RUN


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 29, 2008 3:18 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 77
lodger wrote:
Well, I rely on this posting on the cc65 mailing list -> http://www.cc65.org/mailarchive/2003-11/3779.html
That posting refers implicitly to PRG files...

Best, Oliver


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 30, 2008 10:38 am 
Offline
Site Admin

Joined: Wed Jan 11, 2006 12:22 pm
Posts: 860
I actually did some RTFM. More precisely Chapter 7 of the 1541 Diskdrive User's Guide.

REL files are actually a 2 dimensional array of maximum 720*254 bytes, which means that it should be possible to implement random access files with fseek(),etc fairly easy, although it will be very slow.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 30, 2008 11:00 am 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 77
@RaveGuru:

Thanks for clarifying - looking at the specs it seems more than obvious to me why cc65 doesn't support them :wink:

Best, Oliver


Top
 Profile  
Reply with quote  
PostPosted: Tue Jul 01, 2008 11:50 am 
Offline
Site Admin

Joined: Wed Jan 11, 2006 12:22 pm
Posts: 860
Oliver wrote:
@RaveGuru:

Thanks for clarifying - looking at the specs it seems more than obvious to me why cc65 doesn't support them :wink:

Best, Oliver


LOL, well it's not exactly POSIX :lol:


Top
 Profile  
Reply with quote  
PostPosted: Wed Jul 02, 2008 2:12 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 80
Location: Duesseldorf, Germany
Well, I feel a bit like a dummy here ... ;) because I have totally misinterpreted how to use the cbm.h based file I/O commands and then I got completely confused between stdio.h, cbm.h, cfs.h ... and the limitations of each of these methods. So I feel I have to apologize for causing such a hassle and talking technical nonsense :oops: . To sum things up: Contiki File I/O works and there is nothing wrong with it.

As for cbm.h based functionality, as soon as one knows how to handle those functions, it is indeed possible to read/write any of the Commodore filetypes, including REL files.

@RaveGuru: you were right, the C1541 manual provides a lot of information - I had to google and download an ASCII version of it, since I don't have my original manual anymore. But it really helps understanding how things work in the Commodore world.

Anyway, thank you for your help and inspiration!

_________________
LOAD ":*",8,1
READY.
RUN


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group