On Wed, 16 Oct 2002, Patrick Finnegan wrote: NO. For example, In "Interesting Formats", (as quoted in the next paragraph) they seem to be implying that the original PC diskettes are FM (not MFM), which is FALSE. Then they list "CP/M, Apple II, TRS-80, etc." Then they explicitly mention hard sectored, with the wrong guess that they would be readable on standard FDCs. Then they say that the 160K/180K formats were double sided; which is WRONG. There are numerous such errors on that page, although overall the content is good. Fully automatic determination is NOT possible. But you CAN eliminate most other possibilities, and reduce it to something that can probably handle all of the different formats that you have. SOME parameters, such as sector sequence (aka interleave) are trivial to determine manually, but hell to do automatically. Likewise, but actually a little easier, "which track has the DIRectory?" In XenoCopy, I put in a partially documented "feature" that would look at a disk, and then gray-out formats from the menu (of 400 machines) that had different physical characteristics. If you are willing to program the FDC directly, you can try to read the sector headers. If you are NOT willing to go down to that level, then: 1) try to read, oh say, 512 byte sector #1 Track #4, from track 4, side A, if you get an error code 2 ("Address mark not found") from the BIOS, then you have the wrong density, or recording method If you get error code 4 ("sector not found"), then you have the right density, but wrong sector size, wrong track density, or weird numbering (not that uncommon) If you can read sector #1 Track #8 from track 4, then you are trying to read a 96TPI disk in a 48TPI drive or mode Try 256 and 1024 bytes per sector. (128 has some bizarre problems of its own) Once you finally get a sector to read, increm,ent the numbers to find how many sectors per track. 2) Once you know the bytes per sector, and sectors per track, then try reading from side B. Since side A and side B are normally the same density (except on track 0 and occasionally a few more), an error code of 2 would mean that the disk is single sided. some formats, such as Kaypro DS use an incorrect value in the side number field of the sector headers on the second side. It isn't that hard to program around, but watch out for it. 3) confirm the maximum track (usually 40 and 80, but sometimes 35 and 77! 4) once you have determined the physical format, you can duplicate disks, but not retrieve data from them in a reliable way until you determine the logical parameters: a) side pattern: some formats go up one side and then up the second side (common when expanding a SS format to DS). some go up the first side and then DOWN the second side (performance improvement in "expanded formats") Some (including MS-DOS) use both heads of a cylinder before incrementing the cylinder b) DIRectory location: MS-DOS (with a few great exceptions) puts the DIR on track 0; CP/M puts it a few tracks in (after reserved tracks (which MAY be a different format!!); some formats, such as "stand-alone BASIC" (Coco, etc.) try to put it half way (track 17, 20, etc.) c) DIR structure (what OS?) d) DIR parameters (how many blocks for the DIR, block size, number of bytes used to represent a block number (such as if the number of blocks is > 255) e) sector interleave (what sequence are the sectors in? BUT, ... whatever you do, somebody can screw it up! For example, some formats use 8 sectors per track, but FORMAT 9! Sometimes somebody takes a previously used DS disk, and reformats, and uses a SS format on it. The extraneous stuff on side B can completely confuse an automatic selection algorithm. I estimate that there are about 2500 mutually incompatible floppy disk formats. I've analyzed about a quarter of them, and implemented about 2/3 of those. -- Fred Cisin cisin(a)xenosoft.com XenoSoft http://www.xenosoft.com

On Wed, 16 Oct 2002, Patrick Finnegan wrote: And, of course, the part that I paid most attention to was the discussion of floppy disk formats. If you're not trying to make sense of files, etc., then only the physical parameters matter. I would read the sector headers, which would give you all that you need. But you CAN check whether a format has the parameters that you expect with just a series of sector reads. It would certainly help prevent left over extraneous formatting from confusing the "recognizer". For example, some HP 3.5" formats use 77 tracks. If you take an old used PC 720K and reformat it with the HP, it won't erase the extraneous stuff on the top 3 tracks, thus fooling the recognizer into thinking that it's looking at an 80 track format. What I did in early XenoCopy was to have a list of format names, that loaded their parameters. Undocumented format #0 took you to a series of prompts to input the values. My publisher insisted on opening that for public use, which resulted in an unacceptable amount of support ("What parameters do I put in to do hard sectored and Apple disks?") Good luck, -- Fred Cisin cisin(a)xenosoft.com XenoSoft http://www.xenosoft.com

On Wed, 16 Oct 2002, Fred Cisin (XenoSoft) wrote: Ok, I've looked over Intel's datasheet for the 82077A and 82078 that they have online, and can't find any command that'll easily let me just 'read sector headers'. Is there something I'm missing? The closest command I could find was "READ ID HEADER" which would return the first sector ID that it found. Do I need to read the entire track or someting? Pat -- "This fucking university has shown time and time again that it is completely fucking incompetent when it comes to employing technology" -- Anonymous http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif

Patrick Finnegan wrote: Fred Cisin wrote: The READ ID HEADER command doesn't give you a choice as to what header you're going to read; it just grabs the next one that comes around. So if you want to know the exact sequence of headers on the track, you have to be able to process them in real time. You also don't inherently get any information on the positioning of the IDs with regard to the index pulse. If you want that information, you should do a read track, and then start reading IDs as soon as the read track completes. Since this seems to be a subject of interest to various people here, I have decided to release dmklib even though it is not really ready for prime time: http://sf.net/projects/dmklib/ Here's the README: dmklib README $Id$ Copyright 2002 Eric Smith <eric(a)brouhaha.com> dmklib is a library to read and write DMK format floppy disk images. DMK format was developed by David Keil to represent floppy disk images for use in TRS-80 simulators, and has since been adopted by other software such as xtrs by Tim Mann and M.E.S.S. The specifications for the DMK image file format are available on the web: http://discover-net.net/~dmkeil/trs80/trstech.htm#Technical-DMK-disks dmklib is supplied with several utility/demo programs for Linux: rfloppy: read an actual floppy diskette and produce a DMK image dmkformat: produce a blank formatted DMK image dmk2raw: extract the data from a DMK image into a raw file dumpids: read and display the sector IDs from an actual floppy diskette dmklib and the utility/demo programs are in an *extremely* crude state, however, they have been used successfully to read 8-inch single and double sided, single and double density floppies. Although some versions have been used in the past to read 5.25-inch floppies, it is not known whether this release will do so. Since there has been quite a bit of interest recently on the CCTalk mailing list in Linux software to read floppy diskettes, I have decided to make this prerelease available now rather than wait until I've cleaned everything up. Further development of dmklib will be hosted on SourceForge: http://sf.net/projects/dmklib/ Eric Smith 19-Oct-2002 This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation. Note that permission is not granted to redistribute this program under the terms of any other version of the General Public License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111 USA

Writing your own tools is the only way that you can get something that will do evcerything that you want, and do it the way that you want it. (Sorry, XenoXap is NOT available outside of my office) But, if you don't want top write your own tools: For determining physical format/sector headers: TE program with Central Point Option Board Trakcess on TRS-80 model 3 (needs a few mods for side,etc.) For looking at physical sector contents: MS-DOS disks: DEBUG Norton fUtilities NON-MS-DOS with 512 bytes per sector: Morgan Computing Disk Toolkit NON-MS-DOS with 256 bytes per sector: Superzap (NewDos-80 on TRS-80 Model 3) Others: TE program with Central Point Option Board Trakcess on TRS-80 model 3 What else is available?

On Wed, 16 Oct 2002, J.C. Wren wrote: Treacherous unfinished user interface using our own non-standard terminology mostly. We never got around to making a public version of it, and our in-house one is likely to cause some damage if used by anybody not familiar with the way we were doing things. (things like using "INIT" to mean "to format") If I released it, I'd have to take responsibility for it (and FINISH IT!) Some parts (like "WORM") need major further work - to determine sector sequence/interleave, we tried to have it find every sector that ended in an ASCII letter, and every sector on the same cylinder and adjacent cylinder that starts with an ASCII letter, then see which combinations created words on a list (English and .ASM), to help find which were the most probable sequences, followed by manual checking. ("What's worse tha finding a worm in an Apple? Finding HALF a worm.") If I can find the source code, then I'd release THAT. (it's in one of the totes from clearing out my office) And SOMEDAY, ... maybe I can get around to putting an acceptable user interface on Xap.

Anyone messed with a Cat Weasel? http://www.jschoenfeld.de/products/cwmk3_e.htm

On Fri, 18 Oct 2002, Jason McBrien wrote: Depends. Are you asking in terms of building an FDC board from scratch, etc., or just which clone board to use? The brand of drive doesn't matter much, with a few exceptions. If you are going to use a "modern" drive (half height 5.25" v full height), then you might want to put a switch in the cable to interrupt the index pulse signal (on older drives, you can cover the hole and have it still work for read) Teac 55 series will not accept that it is ready if the index hole is covered. Tandon TM100 is the standard. For floppy disk controllers, the Western Digital 1791 series is a lot handier, due to the presence of a raw track read (NEC 765 series does a "track read" a a multiple sector read) But the WDC 1791 series is not compatible with PC software (all of which assumes a NEC 765 or equivalent.) Of the NEC 765 equivalents, the 37c65 based boards are handy, in that most of them can be used for FM (single density) without having to modify the board.