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

From: Oliver Schmidt <>
Date: 2013-02-22 18:17:15

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.


To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri Feb 22 18:17:25 2013

This archive was generated by hypermail 2.1.8 : 2013-02-22 18:17:29 CET