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