Re: P00-format + new D-format

From: Andre Fachat (a.fachat_at_physik.tu-chemnitz.de)
Date: 1998-10-13 13:54:51

Ruud Baltissen wrote:
> 
> > I myself can produce disk dumps from 8050 disks (~500k) and
> > 8250 disks (~1M) per disk with my setup. They have up to 29 sectors and
> > up to 77*2 tracks. 
> > They also handle up to 224 directory entries.
> 
> See my D16-format as an extended 8250-disk with 156 sectors and 255 tracks.
> 
> > What actually are you planning to do? I mean, either provide standard
> > CBM formats, or simply use the filesystem directly.
> 
> ????: for me 'stanard CBM formats = use the filesystem directly'. Anyway, even 
> with this 16MB-floppy it should be possible to use the direct floppy-commands 
> like blockread etc., just like with D64-file. Commands which are not possible 
> with P00 or plain DOS/UNIX-files.

What I think you are going to do is: You make a 16M disk image and
your program writes the files like on a D64 file only more sectors and
tracks, right? 

Well, this B-R thing is the only advantage I can see of using a 16M disk 
image instead of using the filesystem directly. Actually I would not want 
to waste 16M for a single image disk that is probably halfway empty or so...

What I mean with using the filesystem directly using the hosts
filesystem, producing single .P** or whatever files for each file saved.
The VICE emulator handles this fine for example.
This way no empty space is wasted for a more or less empty disk image.
Only if full compatibility is needed one uses .d64 images. But
there is no use creating a new type of disk image, because there is 
no program compatible to it.

> I intend to support DOS, P00, T64 and all known Dxx-formats. You could do me a 
> favour by giving me the following info of all known formats if it is not to 
> much trouble:
> - tracks
> - sectors / track
> - track(s) used for directory

Only the .D** files are like disk images with tracks/sector
For a bit more on the old disks see
http://www.tu-chemnitz.de/%7efachat/8bit/petindex/disks.html
Sorry, don't have the table of which track has how many sectors.

> > Just FYI: There is a new .G64 disk image file format on the way. It is
> > basically defined and finished, only the docs have to be written up.
> > It is a (AFAIK) a vc1541 disk image in GCR format. It will be supported
> > by several emulators and can handle more than the usual 35 tracks.
> 
> What is the advantage of this format above D64? The only thing I can 
> think of is emulating disks with errors made on purpose to get a kind of 
> copy protection.

Exactly. You can use disks with different disk IDs per sector,
different GCR encoding or whatever you like :-)

> BTW, what does your 8296 show at startup?

The normal 8032 startup screen. 

> Hallo Levente,
> > What about a flexible disk image format, with variable parameters?
> > I mean, if it contained a header, from which the programs could decide
> > if the image contains X or Y tracks/sectors etc.
> 
> On itself not a bad idea at all, in this way you could define a disk which 
> could fit on a 1.44 MB floppy. But to be honest, this would be the only 
> advantage of such a disk format. The others, D64, D81 etc. have the 
> advantage that you can copy them 1-to-1 directly to an existing C= floppy. 
> My D16-format has the advantage of being big but that is the only 
> advantage.

Yes. For a flexible format I would use the Unix/PC filesystem and
then your favourite archiver (ARJ, ZIP, TAR)

Andre

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