Re: IDE for C64

From: Stephen Judd (judd_at_merle.acns.nwu.edu)
Date: 1998-12-06 00:11:57

Hola Ruud,

First the good news: I turned a copy of my thesis in to my committee
Thursday evening, and will be defending on Dec. 15.  So I finally
get to start thinking about C64-related matters again.

> I just finished the HW of the interface to connect a IDE-harddisk with a C64. 

Very cool, good job :).

> The next problem is: what to do with the whole thing? It sounds great to 
> have a 
> HD attached to your C64 

Oh yes, it would be nice :).  Now that I'll be making some money soon,
I'm pretty sure I'll be getting a CMD unit.

> but I'm going to ask you the same question that 
> silenced a colegue at my office: what about the needed SW???? I think I can 
> free up to 2KB in the original ROMs by removing the cassette- and 
> RS232-software but I'm sure that won't do. 

I think that's what CMD did, because I seem to recall the fastload routines 
being in the casette area.  Presumably they use some sort of ROM switching 
to load from tape.

Of course, since you are thinking of replacing 64 ROM routines I assume
you're thinking about a fastloader.  Isn't there some trick which
allows burstloading on a C64?  That might be a good option.

Another possiblity might be to make it JiffyDOS-compatible.  Or even
require JD.  On the one hand, some people might not want to buy JD.  
On the other hand, there's only a certain type of 64 user who would find
a hard drive useful, and I suggest they either already have JD or would
also find it useful.  (I have no idea what CMD would think of this, btw).

Getting rid of the tape drive routines should be no problem.  Really,
what person who wants a hard drive is still using their tape drive 
regularly?  Would it be possible to contruct a little piggyback device
with a switch attached, to go back to the stock ROMs when needed?

> 
> My third idea was to use an obselete 1541 or 1571 board as base. Add the above 
> HW and change the ROM where needed. The idea is to change the ROM there where 
> it starts to read the data from/ write to the disk. In this way (I hope) 
> speeders like EXOS V3 and even SPEEDDOS 

Hmmmm... well, what I can tell you is that the programs that work well
off a hard drive (or 3.5 floppy) are either a) designed to work with it,
or b) allow you to use kernal routines for everything.  It seems to me
that the advantage of e.g. Speeddos is that you wouldn't have to rewrite
any 64 ROMs.  But it also seems to me that as long as you're loading 
a custom fastloader off of disk, you could just write your own.

In my experience, programs that have their own fastload routines built-in
are designed to run off of floppies.

> still will run. I even hope GEOS won't 
> notice the difference. 

I think GEOS would definitely notice.  GEOS uses a custom disk format.
Even the mighty CMD devices don't truly work with GEOS.  That is, I'm 
99% sure that GEOS only recognizes 15x1 devices, so that GEOS users 
create lots of 1581 partitions on their hard drives or high density 
floppies.  The new GEOS replacements, like Wheels, change all of that.  
If you are thinking about GEOS compatibility, I _strongly_ suggest 
focusing on Wheels (or the other one, whose name escapes me) instead, 
especially since you can talk with the author and actually get genuine 
support for your drive.  Wheels is very friendly towards external devices.

> If there is a first question, there should be at least a second. What about the 
> format of the disk itself? One idea is to create a lot of D64-images but that 
> would mean that a 3.5 MB HD would be sufficient to give you 20 1541-floppies. 
> But before inventing the wheel again, who has some ideas? (BTW, does anybody 
> know how CMD solved this?)

CMD uses different partition types: Native mode, 1541 mode, 1581 mode, etc.
The 16MB partition size limit really isn't too bad, because how many
16MB files are there for the 64?  Not many (although Nate Dannenberg
had lots of MODs which spilled over into different partitions).
I think the only reason to keep the stock DOS around is for the odd
program which needs B-W and commands like that.  

But again, the programs which I use off the larger devices all use
stock routines, and I don't see any reason why they would care what
the disk format or disk DOS was like.  I don't know about programs like
Wheels, though.

One thing you haven't brought up, but which I'd suggest thinking hard
about, is what type of user you are aiming this project at.  If it's
at hackers and such, then most of the above concerns are moot -- custom
routines for everything would be fine.

On the other hand, at the Chicago Expo I realized that there is an
enormous number of "users" -- I mean real users, who do lots of cool
stuff with their machines but aren't hard-core techie-types.  These 
people totally outnumber the hackers and actually use things like
a hard drive regularly -- for GEOS, for word processing, for MIDI, 
for simple programming, etc.  I could see an IDE drive with custom
DOS complementing a CMD drive very nicely -- for general use, for large 
files, for backups, etc.

-Steve
-
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.