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

Best, Oliver

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?



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!



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

Your presumption is correct


No offense meant, no offense taken


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.


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


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

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



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.

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

Sorry for not being more precise 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

Since I've seen this floating around...

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

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.

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

Thanks

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.

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

Best, Oliver

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

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


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

That posting refers implicitly to PRG files...

Best, Oliver

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.

@RaveGuru:

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

Best, Oliver

LOL, well it's not exactly POSIX

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