[The fundamental components would be the disk drive (either stock or modified), the controller (possibly heavily modified), and the software] Hard versus soft sectoring, FM / MFM (single/double denbsity) / GCR are primarily an issue of controller, although drive hardware can play a part. For example, Apple ][ used different circuitry on the drive (that was otherwise basically a Shugart SA400); BUT, Apple ][ diskettes CAN be read with most "normal" 360K drives using special controllers. Directory structures (CP/M, TRS-DOS, etc.) are almost entirely a software issue. Although hardware issues must be resolved first, and controller can be an issue [how many remember the Data Address Mark issues with double density on TRS-DOS and derivatives?] The common sizes of disk drives are: 8" 5.25" 3.5" There have also been a few others, including: 3" (Amstrad, Canon, earliest Gavilans,Amdek add-on for Aplle and Coco) 3.25" (Dysan bet the copany and lost. Seequa Chameleon 325) 3.9" (IBM. never produced??) 2.5" (Zenith?) On 5.25" drives, there were a few different intertrack spacings, most common being 48TPI (tracks per inch) 96TPI (""Quad"" density, and 1.2M "high" density) There was also a short-lived 100TPI (Micropolis series 2 and Tandon TM100-4M (M designating 100TPI v the more common 96TPI of 100-4)) Anybody remember the AMLYN drive? capable of variable track spacing, and had a crude jukebox for swapping 600 Oerstedt (1.2M) diskettes. 3.5" drives are normally 135 TPI, although there were some early 40 track (Epson Geneva) at 67.5 TPI 8" drives normally ran at 360 RPM. 5.25" drives normally ran at 300 RPM, except for 1.2M, which thought that it was an 8". That doesn't REALLY matter, since it can be compensated for by changing the data transfer rate at the controller. -- Fred Cisin cisin(a)xenosoft.com XenoSoft http://www.xenosoft.com 2210 Sixth St. (510) 644-9366 Berkeley, CA 94710-2219

On 2 Oct 1998, Eric Smith wrote: Theoretically you could simply scan half-tracks and quarter tracks and just look for strong signals (something above a certain threshold). I suppose it depends on what the problem is. I don't know how similar the Twiggy encoding was to the Disk ][ encoding, but on the Apple ][, if I had bad sectors on a disk, one way to attempt a repair would be to try to read the sector over and over with the checksum disabled until the data looked "right" and then writing it back to disk. This works a good percentage of the time, but not always. Sometimes the disk is physically damaged, and any bytes after the damaged portion of the sector get skewed and will never translate correctly. I know there's some way to correct this but I never sat down to analyze the problem and come up with a solution. Sam Alternate e-mail: dastar(a)siconic.com ------------------------------------------------------------------------------- Ever onward. Coming in 1999: Vintage Computer Festival 3.0 See http://www.vintage.org/vcf for details! [Last web site update: 09/21/98]

On 2 Oct 1998, Eric Smith wrote: Ah! I always assumed "spiral tracks" were simply quarter tracks written every step of the stepper arm, and not while the stepper arm was moving. In fact, I don't know how you could write bytes to the disk while the arm was moving since the step had to be controlled by the program. Its been a while since I messed with that level of detail on the disk drive but was there any time to actually write bytes while the arm was being stepped? I thought you simply poked the right locations and the head moved instantly to the next step, no waiting required? Come to think of it, I believe there was some pausing involved. Yep, synchronized tracks. Wizardry used this technique and it was one of the most impossible disks to copy. I remember only ever being able to make one bit-copy of it that worked. Sam Alternate e-mail: dastar(a)siconic.com ------------------------------------------------------------------------------- Ever onward. Coming in 1999: Vintage Computer Festival 3.0 See http://www.vintage.org/vcf for details! [Last web site update: 09/21/98]

Tony Duell wrote: No, if you oversample at a sufficient rate, writing disks is no problem either. My suggested 8x the channel code rate should work fine; 16x or more would obviously work fine but would be overkill. Software PLLs are much easier to muck about with even than DPLLs in FPGAs. If you're going to use a clock synthesizer (even though it is unnecessary), you might as well simply use it for the sample clock at a multiple of the channel code rate, and still do the data decode (or encode) in software. Eric

On Fri, 2 Oct 1998, Zane H. Healy wrote: How many formats do you have software for? I'm interested because I was thinking of getting a Catweasel board for my Amiga. But early in the summer, I decided instead to try to make the best of my A1020. Unfortunately (?), I found a job only one day after I wrote my first line of code, which only managed to turn the drive motor on and off. :) I probably wouldn't have got very far, but my first test would have been a raw read of every track, dumped to a file. An attempt at a Teledisk-type thing. Figuring out the disk formats themselves would have been a lot of work. I wanted eventually to have something that would be a combination of Teledisk and 22disk, but able to do GCR formats as well. At any rate, Paula can access a lot of formats. There was software that came with the Apple2000 emulator which can read Apple ][ disks into .dsk images, and according to the one of the old Amiga manuals, software exists that will write to that format as well (I just haven't located a copy). With a tweak to the drive's RPM, the file misc/emu/1541.lha on Aminet will read 1541 disks into .d64 images. I've tried it and it works well. It also comes with source code! There was a commercial product called either DOS-2-DOS or DISK-2-DISK (I forget which) which was able to access 1541 disks on a filesystem level, for reading AND writing. But it would only format a disk with less tracks (only tracks within certain speed zones were formatted), and it was probably careful about where it was writing, too. That variable-speed data clock is not something Paula can deal with very well. For Atari 8-bit disks, there is misc/emu/551conv.lha on Aminet. This reads and writes several Atari formats. I've used it to read AND write disks for use with on my Atari 810 and XF551 drives. Of course, I can also read/write 360K and lower MS-DOS formats with CrossDOS and my A1020 as well. I see no reason why more formats couldn't be accessed with this hardware configuration. Not Macintosh DD formats, not _writing_ reliably to 1541 disks, not accessing hard-sectored disks, but anything that doesn't vary the data or rotation speed and is soft sectored should be doable. Low level information on as many disk formats as possible would help a lot, as would filesystem information. Too bad I don't have the time now for this project, or I'd reawaken it. BTW, there's an excellent article by Betty Clay entitled "Amiga Disk Encoding Schemes" in Volume 3, Issue 1 of Amiga Transactor magazine. That article, plus the Amiga Hardware Reference Manual and RKM: Libraries & Devices were my starting points for the project. Doug Spence ds_spenc(a)alcor.concordia.ca http://alcor.concordia.ca/~ds_spenc/