Re: [cc65] Back on Track

Date view Thread view Subject view

From: Ullrich von Bassewitz (
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

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.



Ullrich von Bassewitz                        
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 : 2001-12-14 22:05:35 CET