Re: [cc65] Lynx target

Date view Thread view Subject view

From: Adam Dunkels (
Date: 2003-04-28 23:21:30


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

Adam Dunkels <>

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 : 2003-04-28 23:23:18 CEST