Re: IDE for C64

From: Levente Hársfalvi (Levente_at_terrasoft.hu)
Date: 1998-12-05 13:39:33

Hi guys!


Ruud wrote:

> So my first question to you is to give your opion about the 3 ideas and feel 
> free to add even more!

I also played with the idea of the IDE stuff.

Interfacing the drive to the C64, like the Czech guys did, may give the
best performance (when performance = speed). Disadvantages: no
fastloaders
work, even no copy-protected stuffs work; the other, but for you, maybe
it's not just a serious problem: the interface depends on the C64, you
have to build another one for your other C= machines. Also, you lose hw
compatibility with C64 cartridges (like the MK7).

I didn't play with the thought of the server, 'cos you can get an XT or
a 286 easier and use as server with no hard worx on the filesystem at
all.

I'm with the idea of using an 1541 wreck and use the digital board, the
PS and the case for the hdd. You can expand the original board with RAM,
ROM and a portchip easily (if needed), you can keep all 1541 properties.
So you can make your business about 99.99% compatible to the original
1541,
even using the HDD instead of the floppies.

Since it's just a hacked 1541, it works with all computers supporting
the serial IEC bus.

Talking about the filesystem: I'd use a FAT-like system, just to make
things easier. Maybe, I'd use a FAT-32 like stuff because of the many
and
small files.

 Or you can decide with the CBM like scheme, to allocate a big
bitmap on the first blocks of the HDD as BAM and use daisy-chain linked
file blocks. You can also create an 1541-like root directory with
similar
records. You have to use 512 byte long blocks, of course... Since it
would be quite awful to use 16M long partitions, just use block
lengths and other parameters as they're needed for a reliable and
powerful (expandable) filesystem. You also should take care about
marking
bad sectors (maybe, with using two bits per block to sign if a block is
free, allocated or bad?). This means about 4 or 8 megs when using a 2
Gig
HDD, but who cares? ...It is worth it, because of the much and small
files,
not to mention that you don't have to play with the logical addresses
and
clusters.

Try to create a standart HDD header, I mean the master boot record and
the
partitions table. Create a signbyte for the Commodore HDD partition :-)
...Maybe, CMD have done that? ...But from the other hand, if their
partitions are limited to 16M, maybe you should re-invent the wheel,
regardless to the precedessors. ...If I'm right, the Czech's created a
good filesystem, maybe better than CMD.

It's no question, the filesystem should have subdirs. I guess, a subdir
is
a regular file, which links into a rootdir like structure. ...I don't
know,
Commodore and CMD just did. You should contact the guys above (Doug
Cotton
at CMD, I don't know the other guy but you can find the contact addr on
their homepage). ...Since they're business companies I don't know if
they'll
help. But from the other hand, if they don't, it's just their problem.

Of course, any old programs supporting direct block read/write commands
would go mad when applying onto this filesystem. However, you have the
option to treat special filetypes (regular 1541 disk images) on the HDD
as
subdirs too. When being able to not just copy, but even CD to an image
file,
your DOS can emulate a normal 1541 disk (as long as you're in the
image),
all with the appropriate parameters, even low-level things like GCR
codes.
All depend on your program, and on the image files you use.

Because of the image files, it would be possible to use not just 1541
but
any type and kind of C= floppy images. This is where my idea of a
flexible
disk image format comes in. ...Heh, I won't blame you with this matter,
when
in phase of just setting up the drive. But this is an option. And it is
possible to implement later, keeping in mind that we can treat image
files
as subdirs.

The filetypes should be stored in the regular 1541 filetype sign-byte.
The subdir type may have been just defined, but all others types should
be
marked using this too.
 
Since you have the 1541 board (and the DOS 2.6), you also have the
option
to keep as many original 1541 DOS routines as you like. This not only
helps you being compatible with the 1541, but also helps you not to
implement obvious, but hard pieces of the code. You have a complete
implementation of channels, file-handling, command-parser and so on! You
just have to tie your work right, to the right places (to substitute
the original lowlevel routines).

Of course, this results in a 'worldwide spaghetti' code. Connect your
routines into the original 1541 DOS by rewiring/placing absolute jumps
and
similar things (but modifying as few bytes of the original code as
possible).
This way, all original fastloaders will find the same routines
as found in a normal 1541, and if your routines do right, they'll work
too.
The key is, to present the same functions in the same places as found in
the
original 1541 DOS.

(This also gives you a chance to tie your routines to a modified -
speeddos
like - 1541 DOS easily).

(Of course, it would be also a question of an at least 32K Eprom
replacing
the original, then all of your routines could reside in the expanded
area
(instead of scratching anything from the original DOS). There is
fortunately,
no problems with this extension, as there is fairly enough place to use
in
the memory map).

I disagree with Marko: when speaking of C= hardware hacks, and not
business, I see indeed sense in interfacing a HDD to the CBM. ...At
least,
you have to find something to die in ;-). I prefer using C= like
devices, if
the subject is C=, I hate to use old and noisy PC's for my work, be it
any
subject. 

Me too, disagree with implementing any filesystems depending on image
file formats and 16M limits. 

Good luck, and don't forget to send reports to the list! (I don't know
if
I can help you, I don't know if you need my help at all, but let me know
if
so.)


Levente


Ps. I have an OC118N drive wreck, which I guess is ideal to house a
small
HDD. So be aware... I'll be one of the first persons re-building the
stuff.

-
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.

Archive generated by hypermail 2.1.1.