From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-04-28 16:05:51
On Mon, Apr 28, 2003 at 02:02:51PM +0200, Groepaz wrote:
> > It can. Just change _curunit before opening a file.
>
> uhmz well... not very portable :=P (i'm not only looking at cc65 targets) i
> wont call this more than "workaround" until we have something better.
I thought about using "drive:filename", but this syntax is already used by the
CBM dual drives. So I came up with the current solution. I think it will be
difficult to find a syntax that works and feels "natural" on every platform.
> > Hmmm. How about implementing a RAM disk via a driver, and add another
> > (platform dependent) module that links the first one into the CBM kernal
> > calls?
>
> ? explain :=)
First, write a loadable module that uses an extended memory driver to
implement something filesystem like, but with different names than the
existing ones (maybe ramdisk_write(), or rd_write() or similar). Then add
another loadable module that hooks into the kernal jump vector somehow and
redirects OPEN/BSOUT/CLOSE calls for a drive with a spcific number.
I don't say that this is a very elegant solution, but it avoids having to
rewrite all existing POSIX file I/O routines. After a lot of complaints I had
decided to do them myself, despite the fact that this was exactly what I was
trying to avoid for years, and therefore I'm not going to rewrite them just a
few month later:-)
Maybe we can link the ram disk driver into the high level interface instead?
This would probably be easier, because it's platform dependent, and the FILE
type is already a structure that could easily take function vectors for the
low level functions. This means that you cannot use write() for such a ram
disk, but having fwrite() and friends should also be ok.
> however, i would still like the more generic approach... in the future it
> would allow to have special drivers for each drive, use "irq loaders", have
> dedicated 1541 code with seeking and all...etc pp. maybe needs more effort to
> create at first, but IMHO its a lot more useful in the end.
The question is if we want to implement anything that is implementable:-) If I
look at my TODO list, I have enough work for at least half a year. And this
doesn't include all the new features suggested in the list:-)
My current "short list" for the next release contains this:
* Serial drivers as loadable modules, maybe drivers for some other machines
that have a 6551, because these can be easily derived from the existing
C64 driver.
* Complete existing C64 TGI driver (OUTTEXT is missing).
* Simulator working with a few basic chip modules but without frontend.
* Consolidate debugging output into one file (linker).
* NES and (if possible) pcengine support (your stuff with some cleanup).
* Maybe: Allow .ALIGN to work for arbitrary program base addresses.
This stuff plus the usual bugfixes and minor improvement will give me work for
quite some time. The switch to serial driver modules will also need work from
other people (the Atari driver code has to be adapted).
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 : 2003-04-28 16:06:16 CEST