Re: IDE for C64 (Levente)

From: Andre Fachat (a.fachat_at_physik.tu-chemnitz.de)
Date: 1998-12-07 12:59:29

Ruud Baltissen wrote:
> > Since it's just a hacked 1541, it works with all computers supporting
> > the serial IEC bus.
> 
> > I'm thinking about using the now obselete gates of the onboard 6522's for
> > an IEEE-interface. Only problem is (again) the SW. But When I'm ready to 
> > realise this idea I hope to get some help from Andre :-)

Hm. No problem, schematics etc are on my homepage. But beware: I found
an incompatibility between the 64er IEEE488 ROM for the VC1541. 
My 8296 sometimes reads extra bytes from the VC1541. That does not
happen with the CBM IEEE488 interface fro the C64 :-(

When I have finished the FAT16 for my SCSI harddisk, am going
to overhaul my own IEEE implementation for my selfbuilt computer
(that seems to have the same bug, only a bit worse) and see what 
I can do about the VC1541.

> I've thougt about it. But I also want to support disk-images and they all use 
> 256 bytes per sector. There go two 256-bytes sector in one 512-bytes sector 
> (correct me if I'm wrong). If I'm going to use link-bytes then this is not 
> possible anymore. That would mean either one 356-bytes sector in every 
> 512-bytes sector or using a weird algorithm to hack the 256-b sectors in 
> pieces. The first costs a lot of space and the last one is too tricky IMHO: one 
> mistake and you maybe loose everything. It also costs more processor time to 
> reconstruct everything.

Most harddisks nowadays use 512 byte sectors. To use 256 byte sectors
you have to either reformat them or, what I think you meant, use
one harddisk sector as two logical 256 byte sectors. 

Oh, you mean: a disk image with 256 byte sectors, in a file on 
the harddisk that uses link-bytes like the CBM DOS? Then you would
only have 510 bytes in each HD-sector, which would result in 
a skew of the block start within the file....
> 
> > Try to create a standart HDD header, I mean the master boot record and
> > the partitions table.
> 
> Why do I need a partition table???
> 
> My ideas (worked out a litlle further in more details):
> - The  "bootblock":
>   - identifier, like "CBM-HD"
>   - version
>   - HD-parameters:
>     - number of tracks,  2 bytes
>     - number of heads,   2 bytes
>     - number of sectors, 2 bytes

Sh*tty IDE. Use SCSI and have a logical (i.e. linear!) block address!
(sorry, had to say that ;-)

>   - 4 bytes pointing to the first directory-sector
>   - 4 bytes pointing to the boot-PRG, all 0 when none
>      This a PRG anyone can use to make patches to the original onboard
>      ROM SW or to change it to its own taste like implementing a speeder.
>      By changing these (4?) bytes you can let them point to other PRGs 
>      and in this way simply change your patch. Only a reset of the drive 
>      is needed.

How do you start the drive with the original "patch" as backup?
I'd suggest a jumper, because if one patch fails, you're 
in trouble.

> - directory structure, 64 bytes per entry:

>   - number of bytes in last sector, 2 bytes

Ah, another 256 byte/sector problem....

>   - FAT-entry side-sector-block relative file, 4 bytes
>   - recordlengte relitve file, 2 bytes

<cite>I don't think we will never need more 640k in any computer</cite>
No, don't hit me.... ;-)

> > keeping in mind that we can treat image files as subdirs.
> 
> I was thinking of connecting a image to a devicenumber like I do with 
> PC-Disk3. I can connect up to 28 images to a devicenumber. Even then I can
> change the file on the fly. 

Hm, what was PC-Disk again? A PC printerport connection to the
C64 serial bus? 

André

-- 
Email address may be invalid. Use "fachat AT physik DOT tu-chemnitz DOT de"
------Fight SPAM - join CAUCE http://www.cauce.org------Thanks, spammers...
Andre Fachat, Institute of physics, Technische Universität Chemnitz, FRG
		http://www.tu-chemnitz.de/~fachat
-
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.