Re: [cc65] Re: some patches

Hi,

> [...]
>        _write  := _ide64_write
>        _read   := _ide64_read
> [...]
> Having such an additional translation level would allow for all sorts of
> things: Have 65C02 or 65816 versions of the library functions available, or
> versions using self modifying code, use debug versions of some functions by
> just relinking, or do simple replacements to support different hardware on low
> level.

Cool!

> The drawback is, that as with all good ideas, it needs someone to implement
> it. And as usual I have more good ideas than time to make them real :-)

I certainly know what you're talking about ;-)

>> ... disk I/O clearly is a usecase for loadable drivers ...

> The overhead is not as large for programs that do already use loadable drivers
> (like Contiki), but there are definitely others, which would be much larger
> than before.

Certainly, but I think I learned in the meanwhile that by far not all
programs suffer from size problems (as Contiki always does). And
regarding large programs: With really fast disk I/O overlays become
much more usable - allowing for really large programs...

> The ide64 routines posted here are not necessary to make read/write
> work. They are just making it faster. Which is nothing to sniff at, but it's
> definitely different to mouse or joystick drivers. Without the latter the
> hardware is completely unusable.

That's certainly true. Although - coming from the Apple2 with REALLY
FAST disk I/O - I sometimes question if the CBM "default" disk I/O
speed might be classified as "completely unusable" too ;-))

> And, having several KB of additional code (in
> ALL programs) just to make reads and writes for ide64 faster is not a good
> idea.

In all programs was never an option from my perspective! I was only
arguing for two libraries instead of many: One library without and one
with loadable disk I/O driver support.

The reasoning behind that was just another perspective on the same
issue you brought up: How many users are out there for a certain
speedup solution? Probably few. Therefore a program author won't
create n variants of his application. But if he doesn't hit the RAM
barrier he might just link against the library with loadable disk I/O
driver support. Then the users could grab the driver for their
solution from somewhere or implement it on their own.

Or to put it in other words. If every single speedup solution doesn't
create enough momentum to be support by cc65 then maybe the sum of all
of them does. I'm not trying to convince at any price - I just want to
make my point clear...

> I do really think that having separate read and write functions is the way to
> go. The only question is, how (and by whom) they're maintained, and how using
> them is made as easy as possible.

The maintainance question seems in fact the most important one - quite
some posts in this thread presumed that it would become part of cc65
one or the other way. However I guess this is rather unlikely. And
from that point of view many options discussed so far regarding easy
usage aren't valid.

This was the very reason I tried to focus on improving the usage of
library-extension/ -replacement code not delivered as part of cc65.

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