silverdr_at_inet.com.pl
Date: 2007-12-28 12:04:55
On 2007-12-28, at 11:09, <ruud.baltissen@abp.nl> 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.