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

Hi,

well no, its not that trivial.... you have to use cbm_open/write/read/close
> for sending the respective dos commands and recieving the data.
>

I see :-(


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

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?

But I agree with you in that there might me usecases where the user
actually wants to know the track/sector he's dealing with: I imagine an
interactive sector editor. Here you want to edit a certain track/sector
because i.e. all documentation refers to that notation.

Therefore the DIO API has dio_phys_to_log() and dio_log_to_phys() which
allow you to support that kind of usecase. In case the underlying "API"
requires track/sector notation than you can of course use those two
function internally to implement dio_read() and dio_write().

So from my perspective the DIO API is in fact very well designed :-)


> not even thinking
> about how different drives have different physical layouts and how you'd
> have
> to support a good portion of them. that seems to be the biggest problem in
> the
> current approach.... there should be a way to provide a mapping for the
> application.


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


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

Regards,
Oliver

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