Re: IDE for C64

From: Larry Anderson (
Date: 1998-12-06 05:00:21

Ruud Baltissen wrote:
> Hallo Marko,
> > > The next problem is: what to do with the whole thing?
> >
> > The German proverb "Good question. Next question?" applies here.  I think
> > that the programming effort is too big.  Interfacing the thing to the IEC
> > bus  la CMD's hard disks would be a waste of resources (both design
> > effort and computer resources;

I agree, the IEC is quite a bottleneck, and old technology, you need to think
a next generation interface/protocol to make the drive popular.

> The only thing I know is that CMD uses a SCSI-HD and you can connect it to a
> standard C64.

The Disk controller/host adapter does a great job of IEC usage.  You can
emulate 1541s and 1581 partitions as well as up to about 16mb 'native'
partitions (256 sectors by 254 tracks).  There is a parallel interfacing
option available if you have a RAMLink ands does speed it up considerably. 
But without JiffyDOS (a ROM upgrade on the 64) or a RAMLink (which also adds
JiffyDOS via-it's cartridge type connection) CMD-HD is just as slow as a 1541 (yuck!).

> I only have one good argument: GEOS. I myself are not a GEOS user but a lot of
> people turned down my PC-DISK2 because it was not able to cope with GEOS. And I
> cannot blame them. I don't mind connecting a HD directly to a C64 but then some
> one must tell me how I can fool GEOS to use it. I think my best chance is to
> let it think it is at least a 1541 or better. I haven't found anyone yet who
> knows how to program a driver for GEOS, then it would be possible to attach the
> D16 format as well.

I'm sure once you got the interfacing and programming specs out there people
will start working on a way to get it in GEOS (especially if it runs REAL fast
or has features not found in CMD units)...  Fortunately there is the new
'power-user' version of GEOS, Wheels, which probably is better designed to
handle new devices.  I myself don't use GEOS but would like to see it deveoped
for other purposes such as databases, BBSs, and such.

> I give you the ideas I'm thinking of (for the moment):
> - 32-bits FAT, a cluster = 1 sector. This means you lose 4 bytes on every
>   sector of 512 byte (= < 1%).
> - It should be able to handle disk-images as well as normal files.

I think you fall into a trap on both points (inages and 'normal' files) you
would not want to be tied down to, maybe leave oan opening for an expansion
option - so you can keep the thing lean and mean, that is unless you want the
backward compatibility.  It would also let the deveopment time of a decent
emulator surpass the development of the core technology and probably return a
better 15xx, 8x50 emulator in the long run.

> - The OS of the drive should be able look for a "boot program". In this way you
>   can patch the original OS. But then extra RAM is needed.

Booting would be nice.  You would have to have a ROM patch or a cartridge.

My thooughts:

I dream of seeing something (not this exclusively) externally accessible by
other computers (and fast), if possible.  So you can load it up from a Mac or
IBM, or even share via other 64/128s (like the multi-plexing of the Lt.
Kernal)  I'm not sure what could be done, it's just that cross-computer
accessibility is a big problem for those who have several platforms around.

A CD ROM access would be nice too.

To sum it up, make it really fast, don;'t hold yourself back with
compatibility, but don't make it too hard to program.  And if you could make
it (drive or format) cross/multi-accessible with other computers using IDE
controllers, even better!
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail

Archive generated by hypermail 2.1.1.