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

From: <silverdr1wfmh.org.pl>
Date: 2013-02-22 22:37:48
On 2013-02-22, at 17:38, Groepaz wrote:

>> 1. If there are cbm_ functions for sector-level access then it should be
>> pretty easy to implement DIO based on them allowing for uniform
>> cross-target programming.
> 
> 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 am not sure how much easier it might be on non-cbm targets but what's so difficult about using some cbm typical calls below in order to expose a uniform interface at the top? Trivial maybe not, but too difficult? I don't think so.

>> 2. If there are cbm_ functions for sector-level access I presume they have
>> track and sector as parameter. Given that the number for sectors per track
>> is variable on CBM drives/DOS/<whatever is the right term here> it's not
>> trivial to convert that from/to the linear sector stream in .D64 files.
>> That's exactly the type of "business logic" I'd like to see encapsulated in
>> the C library instead of having to deal with it as an application
>> programmer.
> 
> 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.

If those are really needed (which I don't really see a reason why they would be necessary here) functions calculating both ways are quite easy to implement, aren't they?

> not even thinking 
> about how different drives have different physical layouts and how you'd have 
> to support a good portion of them.

Why not start with d64 format and have 80% of use cases covered? Followed with d71 some time later and maybe more rare formats too.

> that seems to be the biggest problem in the 
> current approach.... there should be a way to provide a mapping for the 
> application. 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 would start with 35 tracks d64 and see where it can get us. If needed other formats could possibly be added later.

All in all - I like Oliver's idea due to the fact that it pursuits what I like so much in cc65: crosstarget source-level compatibility.

-- 
SD!

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri Feb 22 22:38:02 2013

This archive was generated by hypermail 2.1.8 : 2013-02-22 22:38:06 CET