ruud.baltissen_at_abp.nl
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.