Date: 2007-12-28 12:04:55
On 2007-12-28, at 11:09, <firstname.lastname@example.org> 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.