Date: 2007-12-28 12:04:55

On 2007-12-28, at 11:09, <> wrote:

>>> The next question is, can I drop the one drive system?
>> What do you exactly mean here?
> That is was late and I was sleepy :(


> What I meant to say is: "Can I drop the TWO-drives system?". At this
> moment you can address two drives although you get an error when
> addressing drive 1. Dropping drive 1 will free up some memory and ROM
> space.

IMHO - yes. I am sure we don't go far without some trade-offs. This  
one should be rather easy to swallow for 1541 user.

>> Generally - IMHO - JD compatibility is much more important
>> than PC compatibility.
> What was in my head but forgot to mention, there will be other
> speedloaders as well relying on these original routines. So moving  
> them
> will not only have consequences for PC but other speedloaders as well.

Hm, yes - most probably even "for sure".

>> If you run into a situation either-or than JD should
>> have higher priority.
> That is clear.
> But what about people not using JD? I already found out that  
> Commodores
> own UNI-COPY worked fine with IDE3.ASM, but at the normal, slow  
> speed. I
> really would like to have a speedloader or speedcopier that comes with
> the harddisk because such a feature will make the harddisk much more
> atractive.

Certainly - IDE64's second major appeal is its speed. It is the most  
comfortable storage I've used on a 64 also for that reason. OTOH -  
you can't get even close to this speed when using SERIAL port.

> Question for those people with a CMD (or other) hardisk: how  
> compatible
> is this harddisk regarding well speedloaders/copiers line EXOS,  
> FC3, PC,
> and RR?

I can say about IDE64. It is not compatible - speedloader routines  
have to be removed/disabled in order to make multiload software work  
properly. Not much of a surprise or new thing though. I was doing it  
already years ago when I was fed up with speedloaders slowing down my  
load times on DolphinDOS equipped drive..

> Or does your harddisk have its own speed tools?

IDE64 doesn't require such. I am not sure but aren't other harddisk  
solutions also connected differently than floppies? I meant aren't  
those bypassing SERIAL port for the communication?

> I know there are people amongst you who know how to program a
> speedloader/copier. Are there any volunteers to create a program that
> enables to copy files from a normal drive to an harddisk and vica  
> versa?
> Just a basic program so others can expand it with features like  
> choosing
> the device numbers will do. But the sources must be available (at  
> least
> to me) so they can be adapted in case the Kernal of the harddisk  
> system
> has to change. OTOH if I know to what routines this speedloader must
> have access to, I can create a vector table with JMP instructions  
> at the
> begin of the ROM.

Basically it needs access to routines that allow locating/opening  
files, reading-in sectors of the files on read as well as opening  
files for write plus writing the data packets (sectors). Closing  
files in both cases. Transferring to/from buffer using some well  
established fasttransfer routines is secondary.

>> P.S. A different subject - I don't know why but it seems to me
>> that nobody likes the idea of (re)using IDE64 partition scheme
>> and filesystem.. I wonder why..?
> You can only build a house on a stable surface. At this moment the
> surface is a swamp. The moment I have a stable Kernal, you may all  
> jump
> on it it and implement any FS you like :)

Surely - you're right! I was just wondering because there's a some  
discussion on the filesystem going on currently while this (the first  
that comes to my mind) comment went without any reply.

> @ allemaal:
> Commodore support some file formats like PRG, USR, REL etc.
> Theoretically it can support up to 16 formats and my question is:  
> shall
> we use the still free formats for our own purposes?

You mean filetypes - I think - yes, but look first how the others did  
it. I think a lot of this work has been done by CMD/IDE64 people -  
and IMHO we don't really need to invent those things again and have  
different, incompatible scheme.

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.