>>>>> "Ruud" == Ruud Baltissen <g.j.p.a.a.baltissen@kader.hobby.nl> writes:
Ruud> Hallo allemaal, I just finished the HW of the interface to
Ruud> connect a IDE-harddisk with a C64. Now the testing phase starts.
Oh cool :)
Ruud> The next problem is: what to do with the whole thing? It sounds
Ruud> great to have a HD attached to your C64 but I'm going to ask you
Ruud> the same question that silenced a colegue at my office: what
Ruud> about the needed SW????
Well that's the $1000 question, isn't it?
Ruud> I think I can free up to 2KB in the original ROMs by removing
Ruud> the cassette- and RS232-software but I'm sure that won't do.
I'm not sure... Interfacing the IDE drive to read/write blocks is less
than a hundred lines of source (judging from the 6809 IDE driver
source I have). Implementing a file system takes more of course. It
might be possible :)
Ruud> You could add extra ROM using some HW-tricks but I wonder what
Ruud> happens with the compatibility towards an original system.
If you don't mind sacrificing $DE00 or $DF00 you could make it pretty
solid. As good as any cartridge anyway. Actually, using my IO expander
(two 74LS ICs) you could map it in $D100-$D3FF and $D700-$D7FF.
Ruud> My third idea was to use an obselete 1541 or 1571 board as base.
And it's a good one.
Ruud> Add the above HW and change the ROM where needed. The idea is to
Ruud> change the ROM there where it starts to read the data from/
Ruud> write to the disk. In this way (I hope) speeders like EXOS V3
Ruud> and even SPEEDDOS still will run. I even hope GEOS won't notice
Ruud> the difference. The Big Idea that popped up writing the
Ruud> description of the C64-Server is to add some RAM to the board
Ruud> and to use this for the actual HD-software. In this way you can
Ruud> change the SW without the need to burn EPROMs every time.
But then you need to load the SW instead, but I guess it could be
loaded off of the HD bootblock on startup. A flash ROM might be a good
option though.
Ruud> If there is a first question, there should be at least a second.
Ruud> What about the format of the disk itself? One idea is to create
Ruud> a lot of D64-images but that would mean that a 3.5 MB HD would
Ruud> be sufficient to give you 20 1541-floppies. But before inventing
Ruud> the wheel again, who has some ideas?
How about support for multiple partition types? One older format that
is backwards compatible with the 15x1, using max 256 tracks and
sectors (ie max 16MB), and one format that uses a 16-bit sector
pointer for <4GB partitions.
--
___ . . . . . + . . o
_|___|_ + . + . + . . Per Olofsson, konstnär
o-o . . . o + MagerValp@Goth.Org
- + + . http://www.cling.gu.se/~cl3polof/
-
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.