From: groepaz (groepaz_at_gmx.net)
Date: 2002-11-19 02:55:03
Hello Ullrich, UvB> While I wouldn't say it is really complex, it is definitely more work than UvB> just adding a wrapper. Possible problems are: UvB> * You cannot use the handles of the CBM kernal, so you have to use an UvB> additional translation between kernal handles and C handles. not really a problem... UvB> * The behaviour specified by the C standard and the implementation of file UvB> I/O in the commodore drives are sometimes highly incompatible. For UvB> example, it is impossible to open a file for reading and writing. that's one of the MAJOR problems ;=P also lotta care has to be taken when working with more than one open file.... odd bugs trigger here :=P UvB> * You need to talk to the device over the command channel to find out about UvB> disk errors. no problem either (and thank god, the kernal "ST" variable is sufficient for a bunch of checks) >> Also, there were 1571 drives, and even hard drives released for the c64. Is >> there a strategy to program this so it would not close the door on people >> using other types of drives? UvB> When using standard kernal calls, supporting the 1571 or even CMD hardware UvB> should not be a problem. true.... i have actually made the thing in a way so you can have modules that define the actual lowlevel drive stuff (and wrote one module that uses kernal calls so far)... so supporting what ever one could hook up to a filesystem (doesnt have to be a drive, like in *nix this could well be any other device) is a matter of writing the support module. (i am planning to write a serial driver for the silversurfer here ;)) -- Best regards, groepaz mailto:groepaz_at_gmx.net ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-11-19 02:55:09 CET