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.