From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2000-01-20 11:34:48
> However... maybe someone remembers that i talked about writing a filesystem some > (long) time ago, and actually it IS happening! I have already written a lot of > 'lowlevel' drive routines (basically wrapper functions to kernal routines) and > i have built a file-system on it, that is already quite comfortable as long as > you > stick with commodore limitations (only one file at a time, no seeking)... That's good news! It should even be possible to read/write more than one file at a time: Just remember the file handle used in the last kernal call. On the next write or read, check if the file handle is the same, if not, use CHKOUT to switch to the other file handle (channel). The limitation for seek seems to be real, however... > some other (already working or in-the-making) features are: > > - true iso-style path/filenames like > > 8:\myfile.txt (you can alternativly use letters instead of numbers for the > drive) Maybe you could use the forward slash or accept it as well. Forward slashes are more portable than backslashes. > oh... one other question is, that i looked at the RTL and couldnt find the point > where lseek() would kick in the i/o routines... also, would my open() have to > deal with eg stdout as a parameter?! > > talking of standard out.... your printf() should ALWAYS print to screen, no > matter > a file is open or not ;=) took me some time to figure out that some printf sent > garbage to the drive instead of printing info on the screen 8=)) (dont use > $ffd2! :P) lseek is not there, because I don't know of any drive that supports it. If you find a way to support it, adding a prototype (and the corresponding ANSI C function fseek) is no problem. The low level functions should handle three file descriptors without any further action: 0 stdin 1 stdout 2 stderr With this in mind, the current behaviour of printf() makes sense: It writes to stdout which is mapped to the file handle with the value one. It should even be possible to close or reopen the first three file descriptors, so the best way is probably to open them using the normal kernal calls at program start. While all this needs some special handling in the low level routines, it is very portable, because this is the way, it is defined by the C standard (the C standard does not define the low level functions open/close/read/ write, but the high level functions like fprintf. But it makes sense to mirror the behaviour of the high level functions in the low level ones, and it is common use). > mmmh... actually i have written a little command-line interpreter for testing my > file routines... soon i will have added some kind of 'batchfile' capability as > well and then it will only be a matter of running 2 C-programs at different > memory locations ... i need to dig a bit deeper into the RTL and the compiler > though (what about that o65 fileformat? would that be a good solution?) o65 is a good solution for a relocatable executable format. It is not a very good solution for an object file format for a crosscompiler or crossassembler. The format is quite simple. This is an advantage for the loader (which runs on a 6502 machine). On the other side, the simplicity means there is no way to do the more complex things that would be possible on the PC when using it as an object file format for a crossdevelopment tool. Examples for such an additional features would be support for more segments (you need this on machines with two non-adjacent ROMs), or debug information. So yes, o65 would be a good candidate for what you are planning to do. > oh...don't ask for the code yet,its a mess,you dont want to have it like this > ;=P > as soon as its cleaned up and all standarized, i will post it. I'm looking forward to it! Maybe you can send me the diffs so I can verify that they are working with the current development version, and we can talk about any open issues. This is only a suggestion, of course. Regards Uz -- Ullrich von Bassewitz uz_at_musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:35 CET