From: Adam Dunkels (adam_at_sics.se)
Date: 2003-04-28 23:21:30
Hi! On Mon, 2003-04-28 at 19:45, Ullrich von Bassewitz wrote: > On Mon, Apr 28, 2003 at 06:39:00PM +0200, Groepaz wrote: > > as for the dual drives...well, this can not be the reason for not doing things > > like i said above :) invent something to handle cbm dual drives then, dont > > pollute the whole thing with this rather exceptional stuff :) (the same is > > true for stuff like handling subdirectories...if its machine dependend, its > > not very useful IMHO) > > As I said, my original idea was to use drive:filename, so I could live with > that. Unfortunately, the CBM drives do *require* a drive number (the internal > one), at least according to my docs. Otherwise two data channels are allocated > instead of one, which limits the number of files that can be open at once. > This is even true for single disk drives, because the ROMs are derived from > the dual disk drive versions. How about "[device:][drive:]name[;version]", i.e., with optional device and drive numbers? The test for if a drive: is present would be quite simple as well: if(name[1] == ':' && isdigit(name[0])); > It is, in one way, dangerous to have too many ideas. There must be a balance > between your ideas, and your ability to implement them. Having too many ideas, > you will run into danger, never to implement something usable, because what > you are doing is always under construction. You will also run into danger to > change your APIs so often, that no one is actually able to use them. > > Of course, not having any ideas isn't a good idea either:-) > > Since file I/O and the extended memory subsystem are brand new, and there is > not a single program I've heard of, that uses the latter, I would suggest just > to wait some time and see what people are actually doing. In my experience, > this is a good way to learn what is really needed and to have all necessary > features in an API while at the same time keep it as minimalistic as possible. Speaking of ideas and extended memory; I indend to make use of this for Contiki (some kind of generalized caching... I have a few ideas ;-). The extended memory stuff is really quite cool in any case. Speaking of IRQ-loaders: some kind of synchronous serial I/O protocol loader would definately be needed for the C64 version of Contiki, as the CBM kernal based file I/O breaks with the NMIs caused by the RS232/SwiftLink... I personally think that Uz' suggestion with a loadable module that patches the kernal vectors sounds like a nice solution. /adam -- Adam Dunkels <adam_at_sics.se> http://www.sics.se/~adam/ ---------------------------------------------------------------------- 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 23:23:18 CEST