Re: [cc65] CBM C-Library Features and Usecases

On Friday 22 February 2013, you wrote:
> > thing is, in a typical c64 copy program for example you want to know what
> > physical track/sector you are going to read/write ... if only for
> > visualisation or error messages. an abstract linear layer would not only
> > not
> > be useful, but even be counterproductive at this point.
> 
> Maybe that's just the way you're used to see it?

ofcourse. me and everyone else who has used a copy program on the c64 =)

> The DIO API contains dio_query_sectcount(). This allows a copy program to
> display a progress indicator using percentages. And after all that's what a
> user is interested in: How much longer will it take until it's done.
> Regarding the error message: What does it actually help if I know on which
> track and which sector the error occured?

it helps you to find out if reading or writing fails due to a bad disk - or a 
bad/dirty drive (typically resulting in different problems/patterns). atleast 
if i look at my setup(s), errors are not uncommon, since both drives and disks 
are old. i'd simply not use any program not giving me this kind of info. (and 
a progress indicator is not important at all. if it takes longer than about 25 
seconds, i wont use the program either. basicaly anything direct disk access 
using kernal is mostly an academical excercise for the same reason - a program 
ment to be actually used would come with its own turbo-dos anyway =P)

> If I understand you correctly then dio_phys_to_log() and dio_log_to_phys()
> are the very mappers you're asking for.

but these are provided by the library, not the application, right? meaning the 
application must come with all possible tables (of which most would never be 
used).

> 
> > else it must not only support detecting the drive type, but also
> > deal with like 10 disc formats (counting all CBM targets and all related
> > drives).
> 
> I'm quite sure that you can extend the problem space in a way that it
> becomes close to impossible to implement it. However that doesn't mean that
> it is necessary to do so ;-)
> 
> An implementation supporting just the 1541 would already be WAY better than
> no implementation at all. From the little I understand about CBM drives I
> believe that supporting the 1541, 1571 and 1581 would both be feasable and
> cover many usecases so it might be the sweetspot.

then you have a c64 library. for cbm you'd atleast have to support 8050,8250 
as well. and maybe also sfd-1000. and dont forget the code to detect the 
drives (which is far from trivial to do reliably)

1541 only would be especially pointless - because for that drive all kinds of 
imagineable tools exist already (and better/faster than you could ever do with 
cc65's kernal stuff). i would actually ignore 1541 completely for these 
considerations and try to find out what makes sense for other drives first - 
since those could actually benefit from newly written programs.

-- 

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ftp.pokefinder.org

You do not really understand something unless you can explain it to your 
grandmother 
<Albert Einstein>

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