Re: [cc65] Lynx target

Date view Thread view Subject view

From: Groepaz (
Date: 2003-04-28 18:39:00

On Monday 28 April 2003 16:05, Ullrich von Bassewitz wrote:
> 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.

well "find" ? why not take some existing standard such as the ISO naming 
sheme? thats what i was going to suggest... the ISO style 
"drive:filename;version" (we can omit the version, its even allowed by ISO). 
i've seen this used more than once actually (the psx and the dc for example 
use it, also some hackery released for gb/gba). its simple enough to be 
supported in any environment, and it also allows for most complex setups (ie 
many drives and subdirectories)

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)

> 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. 

mmmh yes, it would work.... mmmh... would this also work with more than one of 
these special drivers. (in the far future, i will need irq-loader for the 
1541 and extended memory filesystem at once)) mmmmh

it sounds like a good intermediate solution for the question is how to 
design those two drivers so IF someone in the far distant future rewrites the 
posix stuff, you dont have to rewrite all those drivers aswell :=)

> 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:-)

:o) i can understand ofcoz :=P 

> 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.

mmmh yeah would limit the thing somewhat though. (not for newly 
written code, but for porting existing code that uses write() it would 
eventually add lotta extra work)

could this be made somewhat universal then ? (ie, have irq-loader for 1541, 
ram-disc and maybe a /dev/ttyS0 ? :o))

> The question is if we want to implement anything that is implementable:-)

eh :) honest :=P

infact i like the minimalistic lib and api of cc65 so much, that i am already 
(not really on just happens :=)) copy it for working on the gba, 
gp32, psx etc :o). IMHO such an api must do two things 1) be small and tiny 
and dont do things that arent needed and b) make any possible operation 
available in a portable fashion. (this doesnt mean it has to offer comfort or 
lots of redundant utility code). cc65 is actually pretty good with the first, 
but with the second point it sometimes lacks the one or other little 
detail.... the conio lib is a good example here, its pretty complete and fast 
and tiny at the same time, but some things just cant be done. (for example 
reading a character from screen is not possible, thats why my cpeekchar stuff 
:=)). that problem with file i/o would be another thing like it 
is, its just not possible to for example use an irq or fastloader (which you 
really want to do when writing a serious game for example)... thats the only 
reason for suggesting all this, preventing future hackery :)

> 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:-)

well noone is is expecting YOU to do the work i guess :=) (however, i know 
that even with other peoples stuff there is still work for you left...)

> 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.

i like this one too :o) btw if you'd just define the api and implement one of 
the drivers i am sure other people could convert other existing drivers 

>   * Complete existing C64 TGI driver (OUTTEXT is missing).

he :) i could add that, think i've even such a routine laying around 
(optimized for size and not for speed though i think, so it'll be rather 
slow). is the api defined in detail for that? i have to admit i didnt really 
look at that yet :=)

>   * 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).

as for that, since i am always working on/debugging/testing on real thing/etc 
the actual nes library stuff.... if you could just add the crt0 (and some 
solution for the heap thing :/) so i can continue working with that, then i 
could clean up one of the other files after the other and just send it 

>   * Maybe: Allow .ALIGN to work for arbitrary program base addresses.

i like that idea :o)

> 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).

guess i'll make a proper (nmi driven) driver for the silversurfer then too, 
should be easy enough :)

however... i wouldnt mind if such a (maybe more detailed) todo list would be 
available somewhere...maybe seperatily on the snapshot ftp or sth... some of 
the tasks really look like other ppl could also do them, if they only knew 
what to do :=)

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 18:42:50 CEST