Re: [cc65] Filenames for POSIX functins on CBM targets

On 2012-08-10, at 13:43, Oliver Schmidt wrote:

>>  * Everybody has his pet syntax for this purpose.
> 
> A missing standard is from my perspective no excuse to not support it at all.

Good point.

> Hm, I personally can't judge on that. But I remember well that I got
> quite a lot negative feedback on Contiki in several forums for not
> supporting other unit numbers than #8. That negative feedback was the
> reason why we changed _curunit from being initialized to #8 to being
> initialized from ZP location $BA (?). So I have at least an indication
> that there's a real world need for other unit numbers.

Definitely there is. And I find it not really true that if one uses something else than #8 then it is already a device like IDE64. True - IDE64 or SD2IEC, etc. have their place in the more sophisticated setups but two regular drives are still not so rare. The problem is as Uz noted that those who don't have would have to pay the price in memory usage..

>>  * CBM people are used to specify the device number separately.
> 
> Surely. But they are as well used to C64 specific programs written in
> asm. Here we're about C programs - that at least I like to be
> cross-target. And from that cross-target perspective it is obligatory
> that a single string can represent all potential file locations.

Reiterating my thinking aloud - how about making it this syntax cross-target and always numbering the devices/drives starting from 0. On various targets that would always mean first available storage device. This way nobody would have to think (or ifdef) whether this is to be run on CBM or Apple or..

> If we want to go cross-target we sometimes need to move away from what
> people are used to.

Another good point.

> An example: On the Apple II drives are specified
> by a slot (1-7) and a drive (0-1). But the cc65 dio API identifies a
> drive by a single number. So I "invented" a mapping and documented it:
> http://www.cc65.org/snapshot-doc/apple2-9.html#ss9.3

And if we used the scheme I suggested (not that I insist ;-) one could use the same code on various targets. I mean there is always first storage device. Whether it is #8 or slot1 or A: does not really matter as target specific implementation would have to take care of it. The same applies for additional devices. The only thing I don't like is the potential memory price to be paid

>> A special,
>>    cc65 only syntax will confuse most users more than it helps.

I don't think so. We talk about programmers here, not the end users, right? They should be able to read how to pass arguments properly when writing code. And if we make it somehow unified across targets - the best result.

-- 
SD!

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.