Date: 2007-12-28 11:09:17
Hallo allemaal, I'm very sorry but I have to spoil the fun a bit for the C64/C128 owners who want to use Jim's X-IDE card in combination with their computer. Some minutes ago I decide to combine various pages dedicated to IDE interfaces to one single page. And I started with using the one for the C64 interface as base: http://www.baltissen.org/newhtm/ide.htm . Beside that I noticed that there is something wrong with the page (even worse, it is the wrong page and an outdated schematic), seeing the schematic I noticed something I completely forgot to mention: as you all probably know the VIC ships sometimes accesses the buss a bit longer then it should. No problem for the 6510 and other peripheral IC's but it will be a problem for the IDE interface. In fact it is about the same problem when connecting a 6522 or 6551 to the expansion port. And therefore the solution for connecting these ICs to the C64/128 can be used for the IDE interface as well: a 74LS74 has to placed between the CLK2 of the C64 and the CLK2-input of the 6522/6551. In this case it can be done (IMHO) by glueing a 74LS74 at the spot of the 6502, not needed with a C64/128 anyway, and connect it to the PCB using wires. The CLK input has to be connected to the DOT-clock, CLK2 to the D- and CLR-input. The idea is that the DOT-clock clocks the state of CLK2 to the Q-output. But the moment CLK2 becomes (L), the CLR-input makes sure Q becomes (L) as well. Hallo Patryk, Regarding the subject Power Cartridge: >> 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. > 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. But OTOH, yesterday I tried a copy program and ran in trouble again. The moment I ask it to show the directory, it shows the directory on the harddisk. But the moment I ask it to give a list with files I can copy (which is IMHO nothing more then the directory), it shows rubbish. So it seems that this copy program also reads directly from the 6522. Just like FC3. The question is, how many speedloaders and fast copy programs behave so nice as PC? The only one I know of this moment is PC itself. Just a reminder for myself: check if Star Commander digs IDE3. > 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. 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? Or does your harddisk have its own speed tools? 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. > 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 :) Regarding File Systems: I would love support any existing C= FS like D64, D81, D82 etc. but a) see the remark above and b) we'll certainly need more ROM. I have good hopes that the amount of RAM will be sufficient for the 8-bits version. For the 16-bits version I advise to add at least another 1 KB because I'm not a fan of this idea to use the disk as temporary buffer; it will just slow things down. @ Jim: > I think FAT should be supported as well, for folks who want to > mount their CF and then pick it up and pop it into their PC. I completely forgot about that; you just convinced me. But again, we first need a stable Kernal. > Still, if we treat the initial T&S of the file as a pointer to > the VP, and the VP has a small BAM ..... I thought I mentioned the idea about using clusters. Your idea is better because a 'my' cluster has a fixed size and IMHO your idea creates a variable cluster (don't know of another name). > Obviously, this would not work for truly random access, where > the CBM client asks for an arbitrary T&S. But, routines that > use the file-based DOS routines would work, and a lot of the > existing CBM layout should continue to work. If this won't work anyway for truly random access, why do you want to use a, IMHO, complicated FS instead of FAT. Regarding the IDE64 FS, what is the significant advantage of using it that you want to go through quite some trouble to find its layout? Just curiousity :) > Of course, the idea may be totally offbase, but I thought I > would throw it out in case it helps. It sure helps, I rather prefer discussing things now then discovering at the end of the line that we picked the wrong FS. @ Graig: > Split up the hard drive into a series of 16mb partitions. Accessing the harddisk as a 16 MB partition is the last step before going to LBA mode. From this point you can make a fork that supports your own idea. FYI, CBM-HD supports a 16 MB FS called D16. It is based on D64 (directory and disk name are found on track 18) and partly D82. D16 supports subdirectories. @ 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? 00 = DEL 01 = SEQ 02 = PRG 03 = USR 04 = REL 05 = DIR 1581, but we can use it as well My ideas: BIN for ROMs or other type of binaries TXT for pure text EXE for executables that start at the place they are loaded Dxx for the various images I hope you think of better ones :) -- ___ / __|__ / / |_/ Groetjes, Ruud \ \__|_\ \___| URL: Ruud.C64.org De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. Stichting Pensioenfonds ABP is gevestigd te Heerlen en ingeschreven bij de Kamer van Koophandel Zuid Limburg onder nummer: 41074000 The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. Stichting Pensioenfonds ABP, having its registered office at Heerlen, is registered in the Traderegister of the Chamber of Commerce Zuid Limburg (Maastricht), the Netherlands, registration number: 41074000 Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.